Спасибо за разбор, тоже недавно в это всё погружался. В заголовке "без сторонних сервисов" немного сбивает т.к. все равно присутствует зависимость от FCM, Mozilla Push Service. Полностью независимые пуши это что то типа ntfy.
Отвечу за свои проекты. Тоже на Vue пишу в основном, модалки используем самописные, через portal(vue2) или teleport(vue3) для глобализации. Конкретно пример с модалками "форма записи в таблице", - в слотах передаем компоненты, которые уже содержат нужные пропсы типизированные, например "id продукта", сама форма уже работает с сервисом для загрузки и сохранения. Т.е. подход для форм немного другой, всё по тому, что от бизнеса была задача сделать "выбор" - открываем в модалке или новом окне, и очевидно компонент переиспользется во вьюхе и пропсы идут из компонента обертки в роутере. Поэтому у нас модалки это просто вариант отрисовки, не более. Ну и реально довольном частый кейс это модалка в модалке, например в форме "продукт" поле-лукап содержащий сложный грид с фильтрацией и прочем, и в этот гридьмолно добавить новую запись прямо из грида через форму, итого уже 3 модалки. Пока не было проблем с логикой и перекрытием отрисовки т.к. работает простой принцип first on first out.
Приведение к целому конечно необходимо, я про то что именно выражение лучше писать a + (b-a)/2, в js оно как раз без последствий. Статья то образовательная, и не хочется чтобы у кого то, кто перепишет на более близких к железу языках как (a+b)/2, была головная боль с overflow)
Что забавно, почти в каждой статье или заметке по бинарному поиску пишут именно так) Что бы не ломать потом голову лучше писать a + (b-a)/2 , и не будет никакого переполнения.
Node-schedule такой же простой и минималистичный, но хотя бы есть graceful shutdown из коробки. Мне кажется очень важно для подобных сервисов иметь graceful restart, иначе могут быть сайд эффекты в виде пропусков при деплое или тех. работах, для большей надежности лучше конечно шедулер выносить отдельно с общей БД на задачи, например agenda та же самая.
Конечно правы, я скорее описал где мне было удобно "пощупать руками" и посмотреть профайлером, как происходит сборка и какие параметры можно подкрутить, как это повлияет на потребление памяти и т.д. так сказать как реализовать песочницу) Так то и статья не раскрывает и половины того что там сейчас творится, насколько сложнее стала сборка, насколько сильно поменялся подход к сусурити, из-за чего там уже под 20 разных пространств со своими подходами к дефрагментации. Ещё интересный вопрос работы тредов с общей памятью и её очистка, это вообще мне кажется на отдельную огромную статью тянет)
Спасибо! Легко читалось! Мне, для лучшего понимания, но без желания копаться в исходниках на плюсах, как полезное развлечение, помогли эксперименты с флагами GC на ноде, ну и в продакте очень помогает, особенно если есть жесткие ограничения по ресурсам (node --v8-options)
В продуктовом решении используем пинью и в большом легаси на vue2 - vuex. Но для себя в пет проекте чисто ради эксперимента попробовал юзать композаблы с глобальным стейтом и соглашусь с автором, это бесшовно (refs сразу без приведения) и удобно, можно растащить такие глобальные сторы по функц. модулям, и инициализировать когда чанк первого использующего композабл компонента запустился у клиента(это антипатерн, но как по мне удобно в модульной архитектуре хранить стор внутри модуля). Сразу вспомнилось чем в своё время зацепил, ныне почивший, knockout, там по сути так и реализовывался глобальный стейт ;) Спасибо, тема интересная!
Тоже делали свой костылек для автоскалирования и рестарта по лимиту памяти (от стандартного был сайд эффект пакета для драйвера оракла, который принимая sigint от pm2 рвал всё коннекты без graceful отключения, хотя pm2 был настроен на messages, а не сигналы), но как подсистема в приложении, ваш сторонний вотчер выглядит правильнее, спасибо поковыряем.
Спасибо за разбор, тоже недавно в это всё погружался. В заголовке "без сторонних сервисов" немного сбивает т.к. все равно присутствует зависимость от FCM, Mozilla Push Service. Полностью независимые пуши это что то типа ntfy.
Кластеризация из коробки, и zerodowntime restart. Из того что первое в голову приходит.
Отвечу за свои проекты. Тоже на Vue пишу в основном, модалки используем самописные, через portal(vue2) или teleport(vue3) для глобализации. Конкретно пример с модалками "форма записи в таблице", - в слотах передаем компоненты, которые уже содержат нужные пропсы типизированные, например "id продукта", сама форма уже работает с сервисом для загрузки и сохранения. Т.е. подход для форм немного другой, всё по тому, что от бизнеса была задача сделать "выбор" - открываем в модалке или новом окне, и очевидно компонент переиспользется во вьюхе и пропсы идут из компонента обертки в роутере. Поэтому у нас модалки это просто вариант отрисовки, не более. Ну и реально довольном частый кейс это модалка в модалке, например в форме "продукт" поле-лукап содержащий сложный грид с фильтрацией и прочем, и в этот гридьмолно добавить новую запись прямо из грида через форму, итого уже 3 модалки. Пока не было проблем с логикой и перекрытием отрисовки т.к. работает простой принцип first on first out.
Приведение к целому конечно необходимо, я про то что именно выражение лучше писать a + (b-a)/2, в js оно как раз без последствий. Статья то образовательная, и не хочется чтобы у кого то, кто перепишет на более близких к железу языках как (a+b)/2, была головная боль с overflow)
Что забавно, почти в каждой статье или заметке по бинарному поиску пишут именно так) Что бы не ломать потом голову лучше писать a + (b-a)/2 , и не будет никакого переполнения.
Node-schedule такой же простой и минималистичный, но хотя бы есть graceful shutdown из коробки. Мне кажется очень важно для подобных сервисов иметь graceful restart, иначе могут быть сайд эффекты в виде пропусков при деплое или тех. работах, для большей надежности лучше конечно шедулер выносить отдельно с общей БД на задачи, например agenda та же самая.
Конечно правы, я скорее описал где мне было удобно "пощупать руками" и посмотреть профайлером, как происходит сборка и какие параметры можно подкрутить, как это повлияет на потребление памяти и т.д. так сказать как реализовать песочницу) Так то и статья не раскрывает и половины того что там сейчас творится, насколько сложнее стала сборка, насколько сильно поменялся подход к сусурити, из-за чего там уже под 20 разных пространств со своими подходами к дефрагментации. Ещё интересный вопрос работы тредов с общей памятью и её очистка, это вообще мне кажется на отдельную огромную статью тянет)
Спасибо! Легко читалось! Мне, для лучшего понимания, но без желания копаться в исходниках на плюсах, как полезное развлечение, помогли эксперименты с флагами GC на ноде, ну и в продакте очень помогает, особенно если есть жесткие ограничения по ресурсам (
node --v8-options)В продуктовом решении используем пинью и в большом легаси на vue2 - vuex. Но для себя в пет проекте чисто ради эксперимента попробовал юзать композаблы с глобальным стейтом и соглашусь с автором, это бесшовно (refs сразу без приведения) и удобно, можно растащить такие глобальные сторы по функц. модулям, и инициализировать когда чанк первого использующего композабл компонента запустился у клиента(это антипатерн, но как по мне удобно в модульной архитектуре хранить стор внутри модуля). Сразу вспомнилось чем в своё время зацепил, ныне почивший, knockout, там по сути так и реализовывался глобальный стейт ;) Спасибо, тема интересная!
Тоже делали свой костылек для автоскалирования и рестарта по лимиту памяти (от стандартного был сайд эффект пакета для драйвера оракла, который принимая sigint от pm2 рвал всё коннекты без graceful отключения, хотя pm2 был настроен на messages, а не сигналы), но как подсистема в приложении, ваш сторонний вотчер выглядит правильнее, спасибо поковыряем.