3 ms·
Pushing read model updates back to the client using a two way communication channel is one technical solution. I want to experiment with using Phoenix channels[
by slashdotdash 10y ago
Pushing read model updates back to the client using a two way communication channel is one technical solution. I want to experiment with using Phoenix channels[1] to solve this. I think that has potential for easing the UI/UX concerns. You post a command from the web front-end and subscribe to receive updates for the read model you're looking at. Domain events can drive the client notification.
[1] http://www.phoenixframework.org/docs/channels http://www.phoenixframework.org/docs/channels
- btown 10y agoIf you can write your read model into Mongo, then you can use Meteor to build a real time interface extremely quickly; it tails the database log and dispatches updated records to subscribers practically instantly over websockets, no need for the event processing code to know about how to map to frontend queries. We use this for our production CRM, albeit for internal users. No doubt Phoenix would be more performant and support more databases, but it's nontrivial to build the record-to-subscriber reverse mapping that Meteor brings out of the box. RethinkDB was going to be the Chosen One for this use case, alas...
- slobdell 10y agoalas