Trying to adopt Hasura from Apollo Server

reply-0-unsent.md

Unsent reply to hasura/graphql-engine#3812, on Apollo Server users adoptiong Hasura:

Anyways, my point being is that from a data standpoint you could swap Apollo out for any other spec-compliant server in theory with zero effects (minus whatever vendor-specific tooling you may be using around it).

I'll try to explore this further, but it seems like there's a lot of Apollo systems that we still depend on. There are mutation systems, there are operational concerns.

In terms of getting Hasura into production, ripping out all of our Apollo Server work & replacing it all with Hasura & throwing a big switch over is a very very very intimidating proposal. I appreciate & think you are so very correct technically on so many fronts @GavinRay97, but I would really appreciate a more meet-in-middle path to migration onto Hasura.

GraphQL does not exist. It is not a technology, framework, or library you can download & install. GraphQL is a specification -- an idea.

Agreed. You're very right, & I've somewhat mis-stated my case. I was not fully thinking of this distinction! But you are right.

Yet, there exists a public specification that lets a one GraphQL server expose additional meta-data about itself to permit another GraphQL server to consume that subservient server. This isn't part of official GraphQL query language, but it is a basis for interoperation, and there is existing & widespread support in the GraphQL world for this capability.

Implementing this not-official GraphQL specification within Hasura would permit a very wide range of non-Hasura GraphQL users to begin to use Hasura, and that, to me, & I hope you, would be great & awesome.

Anyhow, I just want to re-state what I'm facing: there's currently too many mutation & operational concerns for us to drop our Apollo Server usage & re-build our infrastructure atop Hasura. Trying to do a hard swap-over like this would be organizationally terrifying for us. It seems like there are some means to avoid having to do a hard swap- via Apollo Federation, which is a way that GraphQL servers can expose additional data describing their data & services- and my feel is that we would be in a much better spot to add in Hasura if Hasura supported this additional meta-data.

If AF is not to be, are there any other options than @GavinRay97's proposal to try a hard switchover to Hasura?

reply-1-sent.md

Sent reply to hasura/graphql-engine#3812, on Apollo Server users adoptiong Hasura:

It would be easier to stitch Apollo's schema into Hasura, and expose your graph to the client through there because of Hasura's ability to handle permissions & authorization. But you totally could also stitch Hasura's schema into Apollo, and either expose the Hasura methods to your client or keep them on the server and use them as a replacement for the regular DB calls you would be making in your resolvers. This way is backwards and incredibly inefficient though.

At this point I think the only safe thing for us to do with our production traffic is to start with the latter option, "stitch Hasura's schema into Apollo."

We are OK with the inefficiency, given that we already live with it regularly. Hopefully we can change latter!

For now though, how do we start? Are there any docs or resources that might be suggested to help us begin to adopt Hasura by,

schema-stitching ("remote schemas"? "federated graphs?" whatever they call them these days),

I also don't know what they are calling it. I'm just looking for help & guidance getting started in adopting Hasura, via whatever means short of replacing all our current work.