SDK usage during server-side rendering

[mbrowne]

Hi,
I have a question about general usage of this library...it's very cool that it can be used as either a server or an SDK, and I want to explore the SDK option to see if it fits our use case. We would like to keep the browser bundle small, so we don't want to run Mesh in the browser, but I am thinking about running it on the server side of the Remix app we are building. Remix can be deployed anywhere, and is especially nicely designed to run at the edge, e.g. in Cloudflare Workers.

So I am thinking about loading the Mesh SDK whenever we do server-side rendering of pages that require data from GraphQL (or potentially other external sources), rather than running an actual Mesh server. Would using it in this way make sense? We would of course run mesh build at build time, but the Mesh SDK would still need to be initialized from scratch every time a page needs to be rendered that isn't already available from the CDN cache. So startup time is an important consideration here. If it's feasible, I think it could be a pretty cool and performant solution to run the Remix app and Mesh all at the edge.

I tried isolating a demo Mesh SDK from all other application code to see how big it is, and it's quite large...625K minified and gzipped for a pretty small schema (built for node.js 16). I wanted to compare that with one of the official examples, but unfortunately the openapi-react-weatherbit example fails to build (Failed to resolve 'process' from './node_modules/readable-stream/lib/_stream_readable.js'). It also seems that the current version of Mesh has some dependencies on node.js (process is not the only example).

As for my demo app, the only Mesh packages used are @graphql-mesh/graphql and @graphql-mesh/transform-filter-schema. Most of the startup time is just loading and evaluating all of that JS code...around 215ms to load the scripts and about 5ms to run getMeshSDK(). I'm hoping there is a way to reduce the amount of code here even though it would be running in the server (so not nearly as bad as if we had to ship that to the browser).

[mbrowne]

@Urigo if you have a moment at some point, I would definitely be curious to hear any thoughts you have on this - thanks! As the creator, I thought you might have the best sense of intended use cases and roadmap.