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.
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.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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.