Comments 10
Если вы пишете серверные приложения в среде Node.js, взгляните на wolkenkit. Этот фреймворк, среди того, что удалось обнаружить в данной сфере предоставляет разработчику один из самых простых интерфейсов для реализации шаблонов CQRS и Event Sourcing

Только при этом wolkenkit, к сожалению, требователен к инструментам — как минимум, придется docker устанавливать, что к примеру под windows — сомнительное занятие


Существуют более легковесные CQRS+ES фреймворки на Node.js, не требующие дополнительных инструментов, к примеру, Resolve.JS. Еще и поддержка React Native из коробки

Были такие проблемы в предыдущих версиях докера. Обновления зависели от билд-версии Windows и часто новые версии выходили с существенной задержкой. Да и само приложение работало не стабильно. Стояло тебе создать новый nat-интерфейс в гипервизоре или забыть выключить прокси/впн и докер отваливался намертво. Даже переустановка не помогала. Плюс целая череда проблем совместимости с самой ОС, как неумение работать с путями windows, drive sharing и т.д.

Начиная с версии 2 докер стал работать на windows более-менее стабильно. Он и до этого работал отлично, если поставить на чистую систему, все настроить и больше не трогать. Теперь же даже можно ставить обновления, как системы, так и приложения, без боязни потерять работоспособность последнего.
Как вы организуете управление состоянием клиентских и серверных приложений?

На бэкенде нет состояния.
На фронтенд-сервере по старинке — сессии. Прямо сейчас — koajs/session
На фронте подойдет любой flux/redux или еще какой x — не принципиально. Прямо сейчас vuex.

После прочтения статьи ощущение было, будто ты открываеь киндер, а там нет игрушки.
Ожидал от заголовка увидеть какую-нибудь чудо-реализацию редукса на сервере с сериализацией в монгу или постгрес.

Эх, разочарование…
У меня это ожидание появилось ближе ко второй половине статьи. Стали мелькать идеи о чудо-реализации, вернее сначала нарисовалось что-то вроде основного редакс стора с персиситентностью в монге или редисе, а на клиенте его реплика (по вебсокету), но это годится для однопользовательских приложений и стало интересно как разрулят в статье разделяемое состояние не реплицируя на клиент полный стор с данными всех пользователей.

Вот тут разбирается реализация этих идей, приводящая к event sourcing.


Грубо говоря, на сервере поток евентов разделяетя по DDD агрегатам, персистятся евенты, а стейт вычисляется.


В реализации вышеупомянутого Resolve, есть View Model — разновидность read model, которая обновляется redux редьюсерами, в том числи и на клиенте (в реальном времени по вебсокету).

На удивление, при применении event sourcing как-то отпадает необходимость в GraphQL.
GraphQL хорош, когда у тебя есть N наборов данных, которые ты не можешь легко менять, и с помощью GraphQL ты можешь заставить сервер вернуть точно такой ответ как тебе нужно.


А в CQRS/ES приложении ты просто меняешь функцию проекции для того, чтобы ридмодель содержала ровно то, что тебе нужно.


Мы в конце концов выпилили GraphQL из системы просто потому что не пользовались им.

Redux в моем виденьи это такая бесконечная машина состояний. В которой каждая нода это состояние приложения, действия — переходы в другие состояния, редьюсеры описатели мутаций, только сами функции перехода это по сути сама программа. Ну конечно вообшем то любая программа конечный автомат… Но от этого мне кажется эта концепция не хуже.
Only those users with full accounts are able to leave comments. Log in, please.