Как будет выглядеть workflow (и git flow) в такой ситуации:
В монорепе есть несколько пакетов (библиотеки компонентов, утилиты и т.д.) и несколько приложений (приложения между собой не связаны, но зависят от одних и тех же пакетов).
Допустим, мы сделали критическое изменение в одном из пакетов, поднимаем версию, в одном из приложение обновляем версию до последней, второго приложения наши действия никак не коснутся?
Несмотря на чрезвычайно широкое распространение связки HTTP/2+SSE
Такое ли оно широкое?
Использовали и используем WebSockets на нескольких проектах. Два из них представляют из себя игры — карточная игра Ligretto и некий турнир с голосованием. Еще один — билетная система, похожая на те, что используются в кинотеатрах. Где пользователи, находящиеся в одном зале, видят действия других.
Проект с билетной системой был написан на Django, а Django, являясь синхронным фреймворком, WS из коробки не умеет. Поэтому использовали Channels, было довольно удобно работать с ws, но возникли проблемы на продакшене в связи с утечками памяти.
Проект с турниром был написан aiohttp (python), там работа с ws устроенно несколько более «низкоуровнево», но в целом было довольно удобно, и проект выиграл в рамках двухдневного хакатона.
Остальные проекты написаны в связке express.js + react.js/vue.js + redux. Очень удобным оказалось «кидать экшены» прямо с сервера.
Забудьте об этом
https://react.dev/blog/2022/06/15/react-labs-what-we-have-been-working-on-june-2022#react-compiler
В монорепе есть несколько пакетов (библиотеки компонентов, утилиты и т.д.) и несколько приложений (приложения между собой не связаны, но зависят от одних и тех же пакетов).
Допустим, мы сделали критическое изменение в одном из пакетов, поднимаем версию, в одном из приложение обновляем версию до последней, второго приложения наши действия никак не коснутся?
Использовали и используем WebSockets на нескольких проектах. Два из них представляют из себя игры — карточная игра Ligretto и некий турнир с голосованием. Еще один — билетная система, похожая на те, что используются в кинотеатрах. Где пользователи, находящиеся в одном зале, видят действия других.
Проект с билетной системой был написан на Django, а Django, являясь синхронным фреймворком, WS из коробки не умеет. Поэтому использовали Channels, было довольно удобно работать с ws, но возникли проблемы на продакшене в связи с утечками памяти.
Проект с турниром был написан aiohttp (python), там работа с ws устроенно несколько более «низкоуровнево», но в целом было довольно удобно, и проект выиграл в рамках двухдневного хакатона.
Остальные проекты написаны в связке express.js + react.js/vue.js + redux. Очень удобным оказалось «кидать экшены» прямо с сервера.