The Tweet
Early last week while scrolling through Twitter, I had noticed a new tool announced to the world, it was GraphQL Mesh. Normall...
For further actions, you may consider blocking this person and/or reporting abuse
I think that is a common misconception about Hasura. They mention throughout much of their documentation that running their engine at the edge is the best way to leverage their product as a platform. Many of their proposed benefits are lost once it is stuffed behind another federated endpoint. In fact, their first 3 bullets of their feature callout is in direct conflict with your concerns.
While we may be able to argue whether or not they are successfully performing those exact functions as we might generally expect, it is clear they intend this product to be your primary entrypoint for client-based graphs.
Here is a link to their role-based authorization documentation: hasura.io/docs/1.0/graphql/manual/...
Additionally, GraphQL Mesh does not need to be run as it's own gateway. It can be used to purely generate a comprehensive SDK which is then used in whatever fashion is best for your business. One example, which I hope to showcase in the coming days, is how it could be used to quickly create data sources for your federated graph. This is extremely powerful if you have a dispersed set of endpoints with varying communication paradigms (openapi, protobuf, soap, etc...)
What would be the architecture using GraphQL Mesh as it's own gateway? Would be awesome to use it as a remote schema as described here instead of OneGraph: hasura.io/blog/remote-joins-a-grap...
The example included is exactly that. GraphQL Mesh builds the schema which is then made available to your GraphQL server implementation. In this case, I'm using Apollo Server and deploying it to Zeit Now. This endpoint is a bonafide Graph based on GraphQL Mesh. Later in the article, I use it as a remote schema in Hasura. I'm hoping for that article to come to fruition because it is the precise architecture that I'd like to work with.
@stephenfriend ... very interesting post! I am looking at the combining the same tech at the moment. So, in your design, for this post, Hasura would be the interface to the client apps, right? Then using Hasura remote schemas, you glue all the schemas together? It would be interesting to see the differences if one used graphql-mesh as the client interface, and the Hasura API as one of the back-end apps? Your thoughts?
Correct, in my example, the Hasura instance is the primary endpoint for the client app. The main reason I chose Hasura for the ingress was that their docs specifically mention clients connecting directly to it as a feature and the GraphQL Mesh docs specifically mentioned that it would be better if it was proxied. I had actually considered putting Hasura behind Mesh, after I did this.
Hasura includes authorization and real-time subscriptions that I don't think are possible to capitalize on when it's not the client endpoint. If you're just looking for Postgres-as-a-Graph, I think the
@graphql-mesh/postgraphilehandler might be the better option.great read, is it possible to include/combine a local schema as well as the remote schema ?