[avitzurel]

I 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).

[bartq]

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.

[nevir]

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.

[debergalis]

[author here]

Yup, we see this pattern a lot. You get the benefits of fewer bytes on the wire, typed APIs, elimination of data fetching code, etc.

But it leaves a lot on the table. The bigger wins come when new features can draw from all your data (in unanticipated combinations) without new API or services development, when you can make new data available for every team's use just by plugging it into the central graph, and when you have a birds-eye view of exactly how all your data is being used so you know where to make further investments.

[nevir]

Yeah, I'd also add that it is a huge help in ramping up new devs when understanding your schema.

[PostThisTooFast]

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.

[nevir]

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.

[OutsmartDan]

Likewise. Sometimes it doesn't make sense to stitch graphs together. We have a gateway that proxies different services and exposes their graphs individually.

[dfischer]

Access could be limited by authorization. Role in JWT for instance.

You can't control malicious clients so I don't think the access part holds much water.

I think they are advocating a monolith deployment to maintain contracts across ownership and client expectations as a best practice vs the version management of multiple graphs requiring different cross sections of data for each client. It helps keep it consistent.

my 2 cents

[AlecAivazis]

One graph does not mean that the different parts have to know about each other. The different parts can be merged together without them knowing and form a single endpoint that the user can query without knowing where that data is coming from.

[munk-a]

I agree, if your data spans multiple logical core domains you could potentially have one entry per core domain, auxiliary data that spans domains can be supplied by each core domains issuer in a manner that is logical for that domain.

[pault]

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?

[avitzurel]

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.