1. Лоадбалансинг: нужно использовать Sticky Sessions, чтобы пользователь всегда ходил на один и тот же сервер.
2. Если этот сервер ляжет – все пользователи потеряют свой стейт или вообще потеряют возможность работать.
Если я правильно понимаю Ваши опасения, то они связаны с использованием in-memory хранилища. Сделано это лишь в целях простоты. Я упоминал в статье, что в дальнейшем я думаю использовать DynamoDB в качестве базы данных. При этом ничего не мешает при необходимости иметь еще и in-memory кэш в каждом из запущенных node-процессов.
3. Под возрастающей нагрузкой ответ от сервера будет дольше, а значит и отклик на действия пользователя будут дольше.
4. Мобильный интернет 3g/4g с плохим покрытием на низкой скорости даст ощутимую просадку в реакции на действия пользователя.
Комментарием выше я согласился, что хорошей идеей будет синхронизация с сервером и другими клиентами через саги, что, в общем, не трудно сделать в текущей реализации.
Что говорить о достоинствах/недостатках, то в конкретной реализации основным достоинством является простота и наглядность: мы синхронизируем состояния различных узлов, обмениваясь только действиями.
Недостатки же Вы и сами хорошо перечислили. :) Еще можно отметить, что, в случае интернета с плохим покрытием, состояние разных клиентов может оказаться в целом неконсистентным. Как вариант решения — в случае возникновения конфликтов, обмениваться целиком состоянием (естественно, предупреждая пользователя и давая возможность сохранить куда-либо изменения).
Спасибо за комментарии, они абсолютно справедливы.
Проблема такой отметки emitterExternal — в том, что другие мидлвари, идущие в цепочке перед EmitterMiddleware, будут обрабатывать все action два раза — и в них тоже нужно будет дублировать эту проверку.
Полностью с Вами согласен. Здесь это таким образом реализовано лишь в целях упрощения. При возникновении потребности в развитии данного проекта, я сделал бы этот рефакторинг одним из первых.
Также важный недостаток предложенного решения я вижу в том, что любые действия в интерфейсе пользователя должны сначала пройти через сервер. В итоге приложение получается насквозь реактивным — но отзывчивость интерфейса будет страдать.
Тоже согласен. Выглядит хорошей идеей делать общение с сервером через саги и на клиенте тоже.
Выглядит любопытно. Не раскрыта тема менеджмента библиотек — она перекладывается на плечи NuGet? Если да — то это плохо, как по мне. Все же менеджмент зависимостей иногда бывает связан с процессом сборки.
В .NET мире NuGet широко распространен, так что не стоит его бояться. Cake не накладывает никаких ограничений на менеджмент зависимостей — можно реализовать хоть инъекции dll, просто в качестве примера было удобно привести NuGet, поскольку над ним в Cake из коробки есть удобная обертка.
Например, Teamcity, если не ошибаюсь, только с версии 9.0 научился синхронизировать настройки с конфигурационным файлом из репозитория. Да и сами проекты/конфигурации сборки все равно придется заводить через интерфейс.
Не могу себе представить CI сервер, не позволяющий собрать тем же инструментом, которым собирают без него.
Использование того же Cake или любой альтернативы ни в коем случае не отменяет использование CI сервера, но у них немного разные задачи. Иногда на CI сервер накладывают слишком много обязанностей и он выполняет именно шаги сборки, которые в таком случае становится трудно повторить локально.
Опять же, процесс сборки может быть нетривиальным — например, c инъекцией dll проектам в разных солюшенах с проверкой консистентности. В этом случае, чтобы описать легкочитаемый билд, нужно обладать довольно хорошими навыками скриптовых языков, а этим, как показывает практика, не всегда легко овладеть.
Если я правильно понимаю Ваши опасения, то они связаны с использованием in-memory хранилища. Сделано это лишь в целях простоты. Я упоминал в статье, что в дальнейшем я думаю использовать DynamoDB в качестве базы данных. При этом ничего не мешает при необходимости иметь еще и in-memory кэш в каждом из запущенных node-процессов.
Комментарием выше я согласился, что хорошей идеей будет синхронизация с сервером и другими клиентами через саги, что, в общем, не трудно сделать в текущей реализации.
Что говорить о достоинствах/недостатках, то в конкретной реализации основным достоинством является простота и наглядность: мы синхронизируем состояния различных узлов, обмениваясь только действиями.
Недостатки же Вы и сами хорошо перечислили. :) Еще можно отметить, что, в случае интернета с плохим покрытием, состояние разных клиентов может оказаться в целом неконсистентным. Как вариант решения — в случае возникновения конфликтов, обмениваться целиком состоянием (естественно, предупреждая пользователя и давая возможность сохранить куда-либо изменения).
Полностью с Вами согласен. Здесь это таким образом реализовано лишь в целях упрощения. При возникновении потребности в развитии данного проекта, я сделал бы этот рефакторинг одним из первых.
Тоже согласен. Выглядит хорошей идеей делать общение с сервером через саги и на клиенте тоже.
Да, что-то очень похожее.
В .NET мире NuGet широко распространен, так что не стоит его бояться. Cake не накладывает никаких ограничений на менеджмент зависимостей — можно реализовать хоть инъекции dll, просто в качестве примера было удобно привести NuGet, поскольку над ним в Cake из коробки есть удобная обертка.
Например, Teamcity, если не ошибаюсь, только с версии 9.0 научился синхронизировать настройки с конфигурационным файлом из репозитория. Да и сами проекты/конфигурации сборки все равно придется заводить через интерфейс.
Использование того же Cake или любой альтернативы ни в коем случае не отменяет использование CI сервера, но у них немного разные задачи. Иногда на CI сервер накладывают слишком много обязанностей и он выполняет именно шаги сборки, которые в таком случае становится трудно повторить локально.
Опять же, процесс сборки может быть нетривиальным — например, c инъекцией dll проектам в разных солюшенах с проверкой консистентности. В этом случае, чтобы описать легкочитаемый билд, нужно обладать довольно хорошими навыками скриптовых языков, а этим, как показывает практика, не всегда легко овладеть.