Principled GraphQL
principledgraphql.com
Principled GraphQL
1–10 of 88 posts
Re: Principled GraphQL
#2I disagree with the notion of `One Graph`.
We have multiple "gateways" for multiple backend services.
We have our main application that has one graph and we have multiple internal applications each owns its own graph.
I don't think the main application needs to know about the other internal graphs, nor should it have access to it (it should not even discover it).
Re: Principled GraphQL
#3I disagree with the notion of `One Graph`. We have multiple "gateways" for multiple backend services. We have our main application that has one graph and we have multiple internal applications each owns its own graph. I don't think the main application needs to know about the other internal graphs, nor should it have access to it (it should not even discover it).
Just out of curiosity, do you have multiple independent teams working on your app? Do you use a monorepo, and if so, do you feel like it makes refactoring and bug fixes more difficult?
Re: Principled GraphQL
#4I disagree with the notion of `One Graph`. We have multiple "gateways" for multiple backend services. We have our main application that has one graph and we have multiple internal applications each owns its own graph. I don't think the main application needs to know about the other internal graphs, nor should it have access to it (it should not even discover it).
Likewise. Sometimes it doesn't make sense to stitch graphs together. We have a gateway that proxies different services and exposes their graphs individually.
Re: Principled GraphQL
#5I disagree with the notion of `One Graph`. We have multiple "gateways" for multiple backend services. We have our main application that has one graph and we have multiple internal applications each owns its own graph. I don't think the main application needs to know about the other internal graphs, nor should it have access to it (it should not even discover it).
Just out of curiosity, do you have multiple independent teams working on your app? Do you use a monorepo, and if so, do you feel like it makes refactoring and bug fixes more difficult?
Multiple independent teams might work on each of the graphs.
We don't use a mono-repo, we use a repo per service.
We have shared libraries like https://github.com/globality-corp/nodule-graphql that make generating gateways easy and straight forward.
Re: Principled GraphQL
#6One question I have is with the "One Graph" idea. I get the principle, and it does seem like it would be nice. However, it's hard for me to imagine what this looks like in practice.
I haven't done anything with GraphQL in a few years. But when I did, we basically had several teams in a part of our organization (one of many in a huge giant megacorp) which built an API with GraphQL. We shared that code base and did the changes in it we needed for different parts of the graph. Sometimes it was fine, and sometimes it didn't go so well (unexpected issues, unexpected deployments when a team didn't prepare properly, etc). So it was an OK idea, but it caused some friction.
A decent of the problems were communication between teams of course. But even if communication was as good as one could imagine, it seems like this model would cumbersome at some point. And I can't imagine it spanning our entire organization, much less our entire megacorp across the board.
So assuming what we did wasn't good, what is a way you might make this work? Do you have a single code base like we did and just be more disciplined? Do you have a project whose job is to stitch together other schemas and pull in submodules? A monorepo for the entire company? Do you actually limit what the idea of the company is at some point to limit what the scope is that this should cover?
This turned out to be more of a ramble than anything. Oops.
Re: Principled GraphQL
#7I disagree with the notion of `One Graph`. We have multiple "gateways" for multiple backend services. We have our main application that has one graph and we have multiple internal applications each owns its own graph. I don't think the main application needs to know about the other internal graphs, nor should it have access to it (it should not even discover it).
They advocate one graph, because it's too hard to merge graphs in parent-child (many-to-one, many-to-many) relationships (recursively) in a flexible way.
This is purely because of technical limitation of GraphQL IMO.
Re: Principled GraphQL
#8I disagree with the notion of `One Graph`. We have multiple "gateways" for multiple backend services. We have our main application that has one graph and we have multiple internal applications each owns its own graph. I don't think the main application needs to know about the other internal graphs, nor should it have access to it (it should not even discover it).
They advocate one graph, because it's too hard to merge graphs in parent-child (many-to-one, many-to-many) relationships (recursively) in a flexible way. This is purely because of technical limitation of GraphQL IMO.
Don't know if this is related, but after initially being excited to hear about GraphQL, I was very disappointed to find that it doesn't seem to offer any way to (in effect) express joins.
Am I missing something here? Has this been addressed?
Thanks.
Re: Principled GraphQL
#9I disagree with the notion of `One Graph`. We have multiple "gateways" for multiple backend services. We have our main application that has one graph and we have multiple internal applications each owns its own graph. I don't think the main application needs to know about the other internal graphs, nor should it have access to it (it should not even discover it).
I would concur. The BFF pattern works really well with GraphQL.
I think 'One Graph' makes sense if that's how you model your data under the covers (e.g. Facebook's graph store)—but if you're in a service-laden world, it makes far less sense.
Re: Principled GraphQL
#10I disagree with the notion of `One Graph`. We have multiple "gateways" for multiple backend services. We have our main application that has one graph and we have multiple internal applications each owns its own graph. I don't think the main application needs to know about the other internal graphs, nor should it have access to it (it should not even discover it).
They advocate one graph, because it's too hard to merge graphs in parent-child (many-to-one, many-to-many) relationships (recursively) in a flexible way. This is purely because of technical limitation of GraphQL IMO.
An alternative architecture (following the BFF idea):
* Non-GraphQL services (speaking REST, gRPC, whatever) * GraphQL gateways, owned by frontend teams/applications.
E.g. each frontend team/application owns its own schema owned by these teams. They can compose the backend services however they wish—and whatever is the most natural representation for their domain.