Supporting both Server and Browser in mesg-js
Please read first: https://github.com/mesg-foundation/mesg-js/issues/35
That comment on the issue explains how we can provide our gRPC APIs to consumers to consumers by both supporting Browsers and Nodejs.
This is related with require(‘mesg-js’).application().api API. This object exposes the gRPC core APIs. It currently only supports node.js but should also support browsers as well.
We first thought about sperating the packages for browser and server, that way we don’t include extra code that generated for node while mesg-js is being used in a browser environment.
But after a second thought, I think seperating them wouldn’t be good because that way it’s not possible to support universal SPAs natively. And if we seperate them, consumers have to do some magic in their webpack confings to switch between the browser and nodejs version of mesg-js. This is not needed. It’s always nice to be able to provide a simple mesg.js that can run in browsers and nodejs without any effort. It should support UMD and that way it can be used with scripts tags in browsers or by getting imported as a package both in browser and node environments easily.
In future we can think of some kind of optimizations for removing node related code when mesg-js is running on browser but it’s too much for now to think about that. And the extra code is just a few 100s of lines. So it’s OK to have them.
We can make the extra code can be removed when webpack target is web or detecting browsers via ENV vars by checking for procces.env.NODE_ENV. This way we can give an option to our consumers to reduce their mesg.js file size when on browser.
Or we can make it possible to node related code to be removed with some webpack plugins and put this info into the docs. Also see.
Or we can provide separate builds, one (mesg-js) can support both client and server and other (mesg-js-web.js) can only support only web etc…
I propose to make require(‘mesg-js’).application().api to support both browsers and node.js for now without thinking any optimizations in mind. And let’s not touch to require(‘mesg-js’).service().api because service api is only planned to be run in a server env for now, not browsers. But we can change this in future.
Note that, his is a breaking change because we’re also going to use plugins to generate clients and types. Which introduces setters/getters for XRequest, XReply types. We used to directly set the values to mutable fields but this is no longer an option.
- Update current APIs to support both browsers and node.js without thinking any file size optimizations and generate client code automatically.
- Think about file size optimizations, avoid any breaking change that setter/getters will introduce and manually create client code(only types).