Using the mocked data during unit tests

[nemonemi]

I have a graphql-mesh as a gateway and as a mocks provider during development.
I'd like to use this data also for tests and to do that I would like to set it up in such a manner that the mocked data is served with each test being run.

The problem I see is the start time of the graphql-mesh server, which is about 30 seconds.

I've had the same setup couple of years back with the Apollo server, and now I'm trying to use mesh in a similar fashion.

Is there a way to make this workflow viable?
Can the start time of the gateway be sped up?

[santino]

Hi @nemonemi ,

graphql-mesh goes through the data sources when you start the server.
It needs to introspect them and translate their specs into GraphQL language, then it also needs to stitch all the sources together.
These are most likely the parts that affect the start time.

There are a couple of ways to improve on this.
One is to implement introspection cache, which is described in the documentation at this page.

Another way could be to change the merge process.
I believe by default graphql-mesh uses merger-stiching to stitch all schemas together.
If you know your data sources don't have conflicts you can opt into merger-bare.
You can do so by installing @graphql-mesh/merger-bare and then addingmerger: bare to the root level of your meshrc.yaml

If you do have conflicts in your sources, you might still want to take advantage of merger-bare by solving them on your own, before the merging process.
In this case, you can use transforms such as rename and filter-schema to transform your data sources at "the source", so that when they arrive at the combination step, they won't have any conflict that needs to be managed with a stitching process, and they can simply be merged all together.

Hope this helps.
Have a play and let us know if you'd like more info on the above.

[nemonemi]

Hmm,
currently, my setup is only accessing a local mocked schema. One schema file.
So, no need for any stitching.

What are the expected start times in both situations?

[santino]

Have you looked at mesh build artifacts?

I advise you to do this, here is the relevant documentation:
https://www.graphql-mesh.com/docs/recipes/build-mesh-artifacts

This is the bit I was mentioning earlier.
If you build the artifacts as part of your CI build step, then they will be used at start and run time.

This should reduce the time to boot up.

[nemonemi]

I have it set up so that these artifacts are committed and available when the graphql--mesh is being run.
The times are based on this setup.

Any suggestions for improvements?

[santino]

Ok, so you commit the .mesh folder and then in the code, you use getBuiltMesh that will read from that folder.

If you have the build artifacts, plus a single and static schema; it feels odd that mesh takes this long to boot.

One thing I do that helps with boot time is using merger bare.
I don't think it would really apply to your use case if you have a single data source only; but maybe you can still give it a go.

You need to install @graphql-mesh/merger-bare and then in meshrc add merger: bare to the root (I have it as the first line literally).

[nemonemi]

The idea is to run the server, and assert data in the features by letting the client obtain data through the means of the original implementation.

By the way, the getBuiltMesh is throwing me some pathing error. Cannot find module....

[nemonemi]

I've decided to use the getMeshSDK, and with that, it works.

I'm consuming the data on the client with gqless (gqty) and there I've extended the implementation that in case of the test environment it returns the SDK data.