AN
rabbit, kafka, consul, keycloak, prometheus
Ну это да. Но это уже не "просто REST"
Size: a a a
2020 December 11
SB
Ну это да. Но это уже не "просто REST"
чего это не просто рест, в консуле конфиг, кролик/кафка обычная шина, прометей - мониторинг, кейклоак авторизация
SB
я бы сказал это не "Hello World" - REST
SB
но вполне себе "просто" REST
AP
Вопрос по корутинам и флоу.
Вот у меня есть флоу которое я создаю с помощью билдера
flow {
emit(getValueByIndex(1))
emit(getValueByIndex(2))
emit(getValueByIndex(3))
}
И тут конечно же getValueByIndex будут последовательно выполнятся и имитити результат. А как сделать чтобы getValueByIndex внутри flow выполнялись асинхронно и имитился результат сразу как только будет получен? getValueByIndex это suspend fun
Вот у меня есть флоу которое я создаю с помощью билдера
flow {
emit(getValueByIndex(1))
emit(getValueByIndex(2))
emit(getValueByIndex(3))
}
И тут конечно же getValueByIndex будут последовательно выполнятся и имитити результат. А как сделать чтобы getValueByIndex внутри flow выполнялись асинхронно и имитился результат сразу как только будет получен? getValueByIndex это suspend fun
господа спасите. Пока вижу для решения только использовать channelFlow но что-то не хотелось бы экспериментальные функции использовать
с#
Вопрос по корутинам и флоу.
Вот у меня есть флоу которое я создаю с помощью билдера
flow {
emit(getValueByIndex(1))
emit(getValueByIndex(2))
emit(getValueByIndex(3))
}
И тут конечно же getValueByIndex будут последовательно выполнятся и имитити результат. А как сделать чтобы getValueByIndex внутри flow выполнялись асинхронно и имитился результат сразу как только будет получен? getValueByIndex это suspend fun
Вот у меня есть флоу которое я создаю с помощью билдера
flow {
emit(getValueByIndex(1))
emit(getValueByIndex(2))
emit(getValueByIndex(3))
}
И тут конечно же getValueByIndex будут последовательно выполнятся и имитити результат. А как сделать чтобы getValueByIndex внутри flow выполнялись асинхронно и имитился результат сразу как только будет получен? getValueByIndex это suspend fun
flow {
for(i in ...) launch {
emit(getValueByIndex(i))
}
}
for(i in ...) launch {
emit(getValueByIndex(i))
}
}
AN
масса возможностей отстрелить себе ноги вручную, там где тебе надо простое взаимодействие сервисов и уже опытные люди решили эту проблему в спринге - вот в этом и прелесть в общем-то
Хорошо, убедил.
с#
Вопрос по корутинам и флоу.
Вот у меня есть флоу которое я создаю с помощью билдера
flow {
emit(getValueByIndex(1))
emit(getValueByIndex(2))
emit(getValueByIndex(3))
}
И тут конечно же getValueByIndex будут последовательно выполнятся и имитити результат. А как сделать чтобы getValueByIndex внутри flow выполнялись асинхронно и имитился результат сразу как только будет получен? getValueByIndex это suspend fun
Вот у меня есть флоу которое я создаю с помощью билдера
flow {
emit(getValueByIndex(1))
emit(getValueByIndex(2))
emit(getValueByIndex(3))
}
И тут конечно же getValueByIndex будут последовательно выполнятся и имитити результат. А как сделать чтобы getValueByIndex внутри flow выполнялись асинхронно и имитился результат сразу как только будет получен? getValueByIndex это suspend fun
ну или если надо порядок сохранить, то flow не нужен
val foos = mutableListOf<Defferred<T>>()
foos += async { getValueByIndex(1) }
foos += async { getValueByIndex(2) }
foos += async { getValueByIndex(3) }
foos.awaitAll()
и оно асинхронно выполнится и когда всё загрузится отдаст лист
val foos = mutableListOf<Defferred<T>>()
foos += async { getValueByIndex(1) }
foos += async { getValueByIndex(2) }
foos += async { getValueByIndex(3) }
foos.awaitAll()
и оно асинхронно выполнится и когда всё загрузится отдаст лист
OY
flow {
for(i in ...) launch {
emit(getValueByIndex(i))
}
}
for(i in ...) launch {
emit(getValueByIndex(i))
}
}
так нельзя ж вроде
во первых, надо в coroutineScope это закинуть
во вторых, emit можно вызывать только из одного контекста, иначе будет ошибка FlowInvariant, или типа того
поэтому как раз channelFlow это то, что нужно
и не надо боятся эксперемтального :)
во первых, надо в coroutineScope это закинуть
во вторых, emit можно вызывать только из одного контекста, иначе будет ошибка FlowInvariant, или типа того
поэтому как раз channelFlow это то, что нужно
и не надо боятся эксперемтального :)
AP
ну или если надо порядок сохранить, то flow не нужен
val foos = mutableListOf<Defferred<T>>()
foos += async { getValueByIndex(1) }
foos += async { getValueByIndex(2) }
foos += async { getValueByIndex(3) }
foos.awaitAll()
и оно асинхронно выполнится и когда всё загрузится отдаст лист
val foos = mutableListOf<Defferred<T>>()
foos += async { getValueByIndex(1) }
foos += async { getValueByIndex(2) }
foos += async { getValueByIndex(3) }
foos.awaitAll()
и оно асинхронно выполнится и когда всё загрузится отдаст лист
мне как раз нужно чтобы не по порядку
AP
flow {
for(i in ...) launch {
emit(getValueByIndex(i))
}
}
for(i in ...) launch {
emit(getValueByIndex(i))
}
}
как написал @why_oleg так не получится . В это я и сам уперся
AP
так что channelFlow только?
с#
так нельзя ж вроде
во первых, надо в coroutineScope это закинуть
во вторых, emit можно вызывать только из одного контекста, иначе будет ошибка FlowInvariant, или типа того
поэтому как раз channelFlow это то, что нужно
и не надо боятся эксперемтального :)
во первых, надо в coroutineScope это закинуть
во вторых, emit можно вызывать только из одного контекста, иначе будет ошибка FlowInvariant, или типа того
поэтому как раз channelFlow это то, что нужно
и не надо боятся эксперемтального :)
а почему тогда просто channel не использовать?
OY
а почему тогда просто channel не использовать?
а смысл, если channelFlow как раз и использует канал внутри, только что чуть лучше, чем ты сам напишешь через канал )
SB
is there any docs or tuts that I can learn by reading or watching? It would be very helpful
I don't think they're exist as it's kind of 'early adopters' technology nowadays. In case you'll find some useful examples, please share links here.
OY
так что channelFlow только?
https://pl.kotl.in/gS6ugBYrU
вот пример с каналом и с channelFlow
обратите внимание на take(3) в первом варианте, он нужен, чтобы канал закрыть, может как-то иначе можно сделать, но я не догнал :(
с channelFlow оно автоматически закрывает канал когда скоуп заканчивается
вот пример с каналом и с channelFlow
обратите внимание на take(3) в первом варианте, он нужен, чтобы канал закрыть, может как-то иначе можно сделать, но я не догнал :(
с channelFlow оно автоматически закрывает канал когда скоуп заканчивается
AP
https://pl.kotl.in/gS6ugBYrU
вот пример с каналом и с channelFlow
обратите внимание на take(3) в первом варианте, он нужен, чтобы канал закрыть, может как-то иначе можно сделать, но я не догнал :(
с channelFlow оно автоматически закрывает канал когда скоуп заканчивается
вот пример с каналом и с channelFlow
обратите внимание на take(3) в первом варианте, он нужен, чтобы канал закрыть, может как-то иначе можно сделать, но я не догнал :(
с channelFlow оно автоматически закрывает канал когда скоуп заканчивается
спасибо. channelFlow действительно удобней.
с#
https://pl.kotl.in/gS6ugBYrU
вот пример с каналом и с channelFlow
обратите внимание на take(3) в первом варианте, он нужен, чтобы канал закрыть, может как-то иначе можно сделать, но я не догнал :(
с channelFlow оно автоматически закрывает канал когда скоуп заканчивается
вот пример с каналом и с channelFlow
обратите внимание на take(3) в первом варианте, он нужен, чтобы канал закрыть, может как-то иначе можно сделать, но я не догнал :(
с channelFlow оно автоматически закрывает канал когда скоуп заканчивается
в первом варианте можно сделать BroadcastChannel.asFlow
OY
в первом варианте можно сделать BroadcastChannel.asFlow
зачем?
и это плохой совет, учитывая, что broadcastChannel скоро наверно выпилят вообще, потому что для них есть замена - StateFlow и SharedFlow
и это плохой совет, учитывая, что broadcastChannel скоро наверно выпилят вообще, потому что для них есть замена - StateFlow и SharedFlow
с#
зачем?
и это плохой совет, учитывая, что broadcastChannel скоро наверно выпилят вообще, потому что для них есть замена - StateFlow и SharedFlow
и это плохой совет, учитывая, что broadcastChannel скоро наверно выпилят вообще, потому что для них есть замена - StateFlow и SharedFlow
спасибо, не знал