@schue Thank you for this post.
I’ve been thinking about this in a bit more depth and I’d like to share what I’ve thought about here.
I’m not set on having Moqui run completely in the browser and about this web3 technology ideals, but it certain is interesting.
JavaScript Browser Logic
Running some javascript logic in the browser would be very interesting.
One of the first steps could be using grooscript to have xml screens’ <action> element logic to be implemented to run in either javascript (on the browser client side) or groovy (on the server side). One potential downside to this is code sent to the client can’t really be trusted.
Moqui already has it’s domain specific language for running groovy scripts. In theory, some if not all of these script logic could be implemented in javascript. This would have to be something like a library for getting data from the entity facade, execution facade, resource facade etc.
Using something like grooscript there could be a javascript library that moqui uses for running some <action> tag scripts inside of the broswer. This library could be used in 3rd party node / javascript applications also.
In addition, some services could be used as we browser webworkers whether they’re meant to run on node or the browser and would use a similar library to the one mentioned above.
Browser Database
The concept of a browser database is interesting for client side caching in my opinion.
I haven’t looked into this a ton, but some tools that could be used for this are PouchDb for handling the browser’s IndexedDb and using RxDb for automatically updating fields.
The idea is that using a browser database client side would allow some of the logic work to be done on the client side rather than server side helping Moqui servers to scale better by using less resources per client. In addition, using rxdb could be interesting for a more reactive application like: having fields conditional on whether data is there, updating data changes (probably from a websocket or similar) from the database, etc.