Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Principled GraphQL

principledgraphql.com

Post reply on HN
Print view View original

11–20 of 88 posts

Re: Principled GraphQL

#11

Post by munk-a »

avitzurel wrote: post #2

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

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.

Re: Principled GraphQL

#12

Post by gnat »

Summary: have one company graph, implemented as federated implementations from different teams, with a registry for tracking the (iteratively evolving) schema. Use per-client access permissions and structured logging, incrementally improving performance as usage grows. Data graph functionality should be a separate tier rather than baked into every service.

Re: Principled GraphQL

#13

Post by andrewingram »

The main argument I have against "One Graph", is that it's not that uncommon to have two (or more) quite distinct views of the world.

At my last job, we were building a social shopping app. Behind the scenes, products were versioned so that we could deal with disputes related to attempts to defraud customers. This (along with several other things) meant that the logical internal abstraction of the data model for things like dispute dashboards was considerably more complicated compared to an abstraction that made sense for the clients (apps and website).

If we only had one graph, all the clients developers would have to develop around a data model that was far more unwieldy than they needed. But with two graphs, the world was a lot simpler (at the cost of having to maintain two graphs).

Re: Principled GraphQL

#15

Post by PaulHoule »

andrewingram wrote: post #13

The main argument I have against "One Graph", is that it's not that uncommon to have two (or more) quite distinct views of the world. At my last job, we were building a social shopping app. Behind the scenes, products were versioned so that we could deal with disputes related to attempts to defraud customers. This (along with several other things) meant that the logical internal abstraction of the data model for thin…

The RDF world has conclusively proven that there is more than "One Graph". (e.g. people try to make "One Graph" and their projects die; try to make as many graphs as there are points of view and the sailing is smooth)

Re: Principled GraphQL

#16

Post by andrewingram »

PaulHoule wrote: post #15
andrewingram wrote: post #13

The main argument I have against "One Graph", is that it's not that uncommon to have two (or more) quite distinct views of the world. At my last job, we were building a social shopping app. Behind the scenes, products were versioned so that we could deal with disputes related to attempts to defraud customers. This (along with several other things) meant that the logical internal abstraction of the data model for thin…

The RDF world has conclusively proven that there is more than "One Graph". (e.g. people try to make "One Graph" and their projects die; try to make as many graphs as there are points of view and the sailing is smooth)

In the case of GraphQL, I'd be interested in seeing strategies for multiple graphs within a single codebase. Essentially being able to produce different schemas based on config. I know that superficially it's as simple as some "if" statements, but I'm curious about the maintenance/scalability side of it.

Re: Principled GraphQL

#17

Post by thanatropism »

andrewingram wrote: post #13

The main argument I have against "One Graph", is that it's not that uncommon to have two (or more) quite distinct views of the world. At my last job, we were building a social shopping app. Behind the scenes, products were versioned so that we could deal with disputes related to attempts to defraud customers. This (along with several other things) meant that the logical internal abstraction of the data model for thin…

That's the general argument for key value storage versus normalized relational databases as well.

Re: Principled GraphQL

#18

Post by lopatin »

jcroll wrote: post #14

is graphql something anyone really needs unless they're facebook

While using GraphQL does have some benefits when dealing with a massive amount of users, that's not the reason most people choose to use it. GraphQL is simply a drastically different (and IMO better than REST) model for clients to talk to servers.

Re: Principled GraphQL

#19

Post by avitzurel »

jcroll wrote: post #14

is graphql something anyone really needs unless they're facebook

You are being downvoted but I think it's a pretty legitimate question and the answer to it is: Yes.

If you want to have a united interface to multiple services behind the scenes and incorporate ACL or any kind of top-level resource management, GraphQL is a great way to go about doing that.

Re: Principled GraphQL

#20

Post by debergalis »

nevir wrote: post #10
bartq wrote: post #7

Earlier quoted context omitted.

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.

[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.

Post reply on HN