gateway
gateway copied to clipboard
nautilus
Request: gqlgen and gqlparser updates and collaboration ideas
👋 Hi, I have been maintaining both gqlgen and gqlparser for a few years now, and I wondered if there was anything I could do to encourage you to update both to newer versions.
The June 2018 GraphQL spec itself has been superseded by the October 2021 and the longer this gets put off, the bigger the issues I worry it will cause.
I also wondered if there's anything I can do as a maintainer to collaborate better with your project on an ongoing basis, as I find Nautilus to be an interesting and valuable one.
Hey @StevenACoffman! Nice to hear from you, I'm a big user of your libraries so I appreciate you reaching out. I'm actually in the process of rewriting another one of my projects (https://github.com/HoudiniGraphql/houdini) to use your parser 😄
At the moment, this project is sort of in a maintenance mode, I don't have a lot of time to devote to it so @JohnStarich has taken the reins. That being said, there is a new spec coming out soon so it might be best to wait until then to update everything. Also, it's very likely that Nautilus comes out of this maintenance mode soon as part of a suite of offerings that I am putting together (more on that soon) so I would love to discuss any ideas you have
It seems like most of the GraphQL federation gateways have found that there is an irreconcilable tension between the frontend and the backend.
The client by nature always wants to see a monolithic supergraph schema to support a client-driven query process.
Meanwhile, each backend service equally naturally wants to be continuously deployed, evolving independently and non-linearly (occasional rollback).
Any federation gateway that composes backend services as constituent subgraph parts needs to figure out how to reconcile this tension. I don't particularly care for the Apollo Gateway's solution, nor for the Composite spec clarification.
I'm curious what your vision is along these lines.
Yea I think that tension is a major constraint on everyone in this space. I'm definitely a bit biased since I think the client should dictate which slice of a company's API is most meaningful - it owns the contracts and assumptions for how things should be but it's hard to know what that actually means in practice. This is something that I am exploring a lot with Houdini where we deploy a client and server-part as a single unit which gives us a really neat perspective and opportunity for building a true BFF that's composed of everything needed and deployed alongside the client as a single unit (either with server-side rendering on initial view or as a traditional SPA). At the moment, Nautilus hasn't been integrated with Houdini in a meaningful way but it's definitely been sitting at the back of my mind.
Specifically with nautilus, i'm not totally sure how well its approach to federation will work with some of the more complicated datagraphs out there. Our approach to federation is so simple and presumably wundergraph and the rest have the additional complexity for good reason 🤷 Once I get over this big rewrite of houdini's core compiler i want to take a step back and evaluate this. hopefully i'll have a better answer after that
I wonder if the solution is likely to be (compiled or codegen) client-driven de-federation. Most GraphQL APIs require SafeLists to operate publically and avoid complexity attacks. These SafeLists can be Query Planned to segment out which queries correspond to which subgraphs. A Client that codegens a Federated Query into several isolated requests such that each subgraph request can be independently retried in case of transient network failures, and more easily report partial success. With HTTP/2 Multiplexing, Batching isn't really a performance boon anymore.
Yes! This is exactly where my head is at right now. We'll see how this manifests in a few months but the overall approach "shouldn't" affect the underlying federation mechanism. At the very least its nice to hear that you don't think i'm crazy for taking this approach - its quite against the current direction of the community.