Application of Seneca for client side composition

[flowt-au]

Hi.
So... I have read the Tao of Microservices. I have watched the various presentations. I have implemented some of the examples from the Seneca Getting Started page in the browser using this seneca-browser component. So far, so good.

Now...
While completely getting the value of Seneca server side, my immediate interest is in composing the client side app using Seneca.

The reason is that I have an existing old monolith client app written using a mixture of MVC and MVVM patterns. Some of the code is 5 years old. It uses REST to a server (currently using ColdFusion). The server side can remain as is - it is maintainable for now.

The client side is quite complex and, while manageable at present, will quickly become a mess if I add more functionality. The app has a number of "functional modules" the user can interface with. Apart from browser versions it is also wrapped in NW,js (Chrome plus Node) to make a desktop app for OSX, Windows and Linux because the desktop version needs access to the user's local resources (eg file system, clipboard, etc).

My idea is to migrate to a MS architecture on the client side (then later the server side). I really like the idea of designing by messages and the loose coupling / strong boundaries Seneca provides. Some of my proposed client side plugins will talk to the server via REST, some will use local storage (eg PouchDb), some will use memory only, and all will have a test interface (Cucumber), etc etc.

I am also attracted to the idea of sending messages via the server (websockets) to other connected users so each active client can get real-time changes - like a chat system but passing entity data instead of simple message text.

My question...
At an architectural level, is there some reason this client-side composition is not a good idea? It seems hardly anyone has done it. Lots of client-side "microservice" offerings are tightly bound event based patterns which is fine but is not the same as the Seneca pattern. Some of them (eg https://micro-frontends.org/ store the state in the dom which seems like an anti-pattern to me. One "state" can be represented in a view, a log, a time-travel list, a test, etc etc and in my understanding each of those would be a separate service that responds to a message.

Any thoughts on the advisability of this approach would be greatly appreciated!

Thanks so much,
Murray

[rjrodger]

We are building https://voxgig.com using this client-side approach! It's working pretty well :)

[flowt-au]

Thanks Richard. I have been playing and it looks like a way to go for me. Any suggestions or blog posts to support this approach would be most welcome. From my research it seems not many people are thinking about client-side composition using microservices. Mostly it is about the server side.

My current thinking is to use Gherkin => Cucumber.js => Seneca Browser ms => xState to manage the MS state (ie the xState machine is completely internal to the MS) => whatever UI if the MS needs one (currently thinking Vue.js but I like the idea that with this architecture I could have 2 "identical" microservices using 2 different UI to test and evaluate, or for a migration path, or whatever). The app will be wrapped in NW.js (which I am currently using) or perhaps Electron.

One thing that is also appealing is my app will have users within the same organisation online simultaneously and I like the idea of having a WebSocket based MS listening for messages from other users and updating the content (not just chat) as they happen. All exciting.

Thanks for your reply and your work.
Best wishes,
Murray