Moqui in the browser? I mean, *really* in the browser

Technical Discussion
1

I have been kicking a funny idea around for a while which is, could Moqui run entirely in the browser as a web3 application? That may not make any sense so let me elaborate. One of the things that set me thinking in this direction is the IndexedDB facility that is in all modern browsers. IndexedDB is a transactional database with an API not unlike Moqui’s EntityFacade. This storage is persistent between page loads and is allowed to use large amounts of the system’s storage. It was not lost on me how much more of Moqui is defined in its native XML structures with only a little additional Groovy. Luckily, there is a project that translates Groovy into Javascript called GrooScript (grooscript.org). If the ServiceFacade was implemented on WebWorkers then it seems possible that you could create an environment that was able to run many Moqui business processes using nothing but a stand-alone browser.

Ok, why? Well, the browser environment is absolutely everywhere. If Moqui could run in this configuration then literally anyone with a browser (desktop or phone) would have everything they need to run a business. I don’t think it particularly makes sense for a server configuration (though Node.js + LightningDB* on server hardware probably wouldn’t slouch) but I’m mainly thinking about this as a play for the consumer accounting space, like Quickbooks.

What do you think folks?

1 Like
2

@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.

1 Like
3

I think there are some very interesting possibilities for conducting business in situations where you don’t have access to a connection. Including conducting transactions that have to be resolved when you later get access.