Best practices for deployment of mesh with endpoints

[barbolani]

Hi, all.

Our team is using Netflix's DGS to generate all grapqhl machinery and bind Java methods to graphql for us, so we just have a set of graphql schema files for each service from where everything else is derived and we use graphql-mesh as a means of doing a few type extensions and to present a single schema to all front end services. Works well so far.

We're discussing the best way of deploying our mesh implementation, which is completely specified in term of endpoints defined as source.handler.endpoint URLs in the meshrc.yaml configuration . The graphql-mesh documentation suggests the mesh build/mesh start sequence as best deployment practice, as it allows you to create a container that can be started without concerns about the state of other services. However we found that in our case the mesh build command requires the remote endpoints to be up and running in order to generate the .mesh folder, which makes sense since it needs to read the schema from these endpoints.

So it is a kind of chicken-and-egg problem: mesh build requires the remote endpoint to be up, so in order to reach the point where you can do a mesh start you need the .mesh folder that is created by the mesh build command and that can only work when your endpoints are up and running.

But, if you reach the point where the endpoints are up and running, you'd be fine just by issuing then a mesh dev command to start your graphql-mesh and in fact you'll save yourself the complexity of bring up the dependent endpoints just to be able to run of the mesh build command, then shut them down and then start them up again to run the "real" mesh start thing.

So what's your advice for best practices deployment in the case where all endpoints are remote? Seems that simply making sure all dependencies are running and then doing a mesh dev is going to be simpler and of equal resilience (you'd need the services to be up in order to execute the mesh build anyway) ...

Thanks in advance.

[ardatan]

mesh start doesn’t need to have your endpoints up and running. It can start the gateway up even if some of your services are down.
mesh build creates artifacts for you to avoid the need of them running in order to start the gateway up.

If you send a query that needs those endpoints at some point, you will get a runtime error that won’t put the gateway down.
However, mesh dev is exactly like you said, it does the introspection via HTTP which needs your endpoints up and running.

Not sure if this is confusing but we also have introspection field that you can provide your own source of introspection if you don't want to use the endpoint itself for the introspection.

[barbolani]

Thanks @ardatan , seems that your introspection parameter is what we actually need, but what is mesh expecting to find in the introspection parameter? I can't find any documentation on that. The name of a folder containing a set of schema files?

[ardatan]

Sorry for the missing documentation. I am creating an issue for that.
introspection parameter expects a file that contains the SDL representation of the schema. It can be URL or local file path.

introspection: ./my-schema.graphql