IP
Не знаю, говорят нужен TS и срочно.
+ 1 за возможность использовать ts
Size: a a a
2020 March 08
IF
Чего мелочится. Сразу на дарте давайте
A
Вот-вот...
A
Или Swift / Kotlin
DK
Тут дело ещё в том, что в отличии от всего остального - у ts обратная совместимость с js, ваш капитан очевидность
AB
Тестирование асинхронных изменений состояния в Svelte
https://dev.to/d_ir/testing-svelte-async-state-changes-3mip
https://dev.to/d_ir/testing-svelte-async-state-changes-3mip
ИК
Привет, а где почитать что-то свежее про eventStream? Почему он в Sapper используется, например чем он лучше вэбсокетов, и как поднять сервер с его поддержкой отдельно от polka, почему то все старое и скорее всего неактуальное в плане информации..
ИК
похоже на обычный long-poll, не понимаю в чем профит, можете объяснить?
AS
longpoll - клиент ждет чего-то и когда получает, соединение закрывается. В SSE поток постоянно открыт - клиент что-то получает и в нем же получает события и дальше. В этом смысле SSE среднее между лонгполом и вебсокетами.
ИК
longpoll - клиент ждет чего-то и когда получает, соединение закрывается. В SSE поток постоянно открыт - клиент что-то получает и в нем же получает события и дальше. В этом смысле SSE среднее между лонгполом и вебсокетами.
а то, что он периодически аукает null это специфика данной реализации или это некий health-check?
AS
а то, что он периодически аукает null это специфика данной реализации или это некий health-check?
а я не в курсе - не использовал SSE еще
AS
но очень хочется
AS
там может поток рваться, но потом восстанавливается по ID - может это оно?
ИК
но очень хочется
вот я не могу понять чем же WS не угодил) хотя если через http/2 работать, то наверное оправдано и по умолчанию секьюрно
ИК
там может поток рваться, но потом восстанавливается по ID - может это оно?
возможно) я не могу найти инфу новее 2х лет давности, может не там ищу конечно
AS
если поток предполагается односторонний, то я бы выбирал SSE - если у нас и так уже есть http-сервер, то зачем еще вебсокетный протокол прикручивать. Да и на реверс-прокси проблем меньше когда только http гоняется.
ИК
если поток предполагается односторонний, то я бы выбирал SSE - если у нас и так уже есть http-сервер, то зачем еще вебсокетный протокол прикручивать. Да и на реверс-прокси проблем меньше когда только http гоняется.
и надо полагать, что сессия хранится проще и вязать пользователя легче, а вообще да, если мне просто надо сигналить что пора перезагрузить что-то, то конечно это предпочтительнее, а веб-сокет ест больше памяти и держит свой контекст, это еще оверхед
ИК
но где почитать, как правильно его запустить то) я бы хотел с moleculer.services на нем попробовать поработать, я наверное просто не понимаю пока куда смотреть и все проще =)
AS
теоретически могу рассуждать только - на клиенте проблем нет - там API ясный и понятный - на сервере нам нужен обычный http-сервер, который держит сокет открытым максимально длительное время, послать в этот сокет ответ с определённым заголовком, и затем в сокет же посылать уже события.
AS
уверен что на NPM есть миллион мидлвар под express-like сервер на эту тему