Comparison with Nautilus gateway? about graphql-gateway HOT 7 CLOSED

I've added a paragraph to the readme trying to address your question. Is this helpful?
If you have any more questions please let me know.

from graphql-gateway.

Very interesting and helpful! We are currently using the Apollo Gateway in front of our Golang gqlgen and Python Graphene microservices. We also have a variety of less production critical REST endpoints that tend to linger. We would love to have a golang graphql gateway at some point.

Do you think it would be appropriate to put our REST services behind graphql-gateway on a trial basis and put the Apollo Gateway in front of that? Sort of a Federation of Federation?

from graphql-gateway.

You'd like to have a zoom call and discuss options? Should be easier than writing. I've contacted you via linkedin.

from graphql-gateway.

Would you mind also writing up your differences of opinion/approach on the Apollo Federation spec?

1. With federation, microservices all expose a proper part of the overall graph and can refer directly to types that live in other services, without the need to add foreign keys or superfluous relationship root fields to your schema.
2. Federation is fully declarative and doesn't require any user code to be running in the gateway.
3. Execution is efficient and predictable, because it relies on a query plan generated ahead of time with full knowledge of the overall query, instead of on runtime schema delegation that gets invoked as part of normal resolver-based execution.

from graphql-gateway.

This, by the way, is the patched version of the gqlgen we are using for apollo federation spec compliance: https://github.com/marwan-at-work/gqlgen/tree/federation

from graphql-gateway.

@jensneuse I solicited some feedback from another engineer:

I think our goals for a federation gateway are almost exclusively to allow us to have as much of the brokering of requests between services to go through the gateway. We want to minimize application logic in the gateway, and minimize the extent to which services have to request data from other services in an unstructured way -- especially if such data is only needed to return to the client, rather than an input to business logic. So that's #1 and #2 of the apollo spec's stated goals.
In practice right now I don't know of any spec that gets anywhere near apollo in this respect. Nautilus may be the next closest -- they certainly have vaguely related aims -- but their approach is limited by not wanting anything beyond "normal GraphQL" which makes it harder to provide equivalents to Apollo's @requires or the way it does extension fields. Its benefits, on the other hand, don't matter to us as much (we control all our backends and it's not a big deal to implement a magic endpoint beyond basic GraphQL). Similarly supporting REST doesn't really matter to us because we don't want to do in the long term that anyway. (With nautilus specifically, I have a personal distaste for relay, but I don't think it's an impossible approach, just one they haven't figured out how to extend to all the things I care about.)
Generally, the reason I really like apollo is that I think their design goals are almost identical to ours; so whether or not they have a particular feature yet, they're most likely to support it. That's less clear to me for Nautilus and jensneuse's goals appear more actively divergent.

from graphql-gateway.

Would you mind also writing up your differences of opinion/approach on the Apollo Federation spec?

1. With federation, microservices all expose a proper part of the overall graph and can refer directly to types that live in other services, without the need to add foreign keys or superfluous relationship root fields to your schema.
2. Federation is fully declarative and doesn't require any user code to be running in the gateway.
3. Execution is efficient and predictable, because it relies on a query plan generated ahead of time with full knowledge of the overall query, instead of on runtime schema delegation that gets invoked as part of normal resolver-based execution.

What I really like about Apollo is the quality of their documentation and their honesty. They give a lot of hints about the tradeoffs you'll have to accept when using federation. This document (federation errors) explains e.g. that you'll have to keep all enums, unions and custom directives in sync across all your services. This means that changes to one of the mentioned types need orchestration across all services which make use of them. That being said, I don't yet have a proper answer to all these problems so I don't feel qualified to openly criticise Apollo for their approach. All solutions have their tradeoffs. It's a bit like the CAP theorem, either your database is available or consistent. The same goes for caching, simple APIs are easier to cache than very dynamic APIs, independent of their protocol. A highly dynamic REST API with field selectors is not easier to cache than a GraphQL API.

My personal opinion is that we're not yet there when it comes to the right approach about GraphQL and distributed systems. I'm actually unsure if a distributed set of GraphQL microservices makes sense at all. Within a datacenter payload and latency is oftentimes neglectable. So why not use simple, very easy to cache, REST APIs internally and have one GraphQL at the edge? If you want to use GraphQL for server to server communication you can still use this approach and use the gateway internally too. For REST APIs there's a lot of tooling, e.g. varnish cache for easy and efficient caching relying on nothing else than the http spec. This is a perfect match for internal APIs.

Also I think you're in a very good situation that you have the luxury to be able to deprecate all non GraphQL services soon. The broad spectrum of possible users will have a very heterogenous environment and need a solution to onboard every possible protocol and service onto their data graph in order to increase its value. Federated GraphQL microservices might be the go to solution for San Francisco and other hot start-up regions but what about the other 99%?

Additionally I'd like to refer to this blogpost from Netflix: https://medium.com/netflix-techblog/our-learnings-from-adopting-graphql-f099de39ae5f
Twitter does a similar thing with their internal "virtual thrift distributed microservice database" with GraphQL and REST at the edge only as a thing layer between client and virtual db.

Regarding your co-worker it sounds like he's totally right. If you're going to be 100% GraphQL services Apollo Federation seems like a very good choice.

What I'd be interested in is how you plan to address the following topics with your approach: authentication, field level authorization, caching, input validation & complexity based rate limiting. Depending on your use case not all of them might be relevant to you. I'm just interested in learning more about how people think about securing their GraphQL environments.

from graphql-gateway.