Live data from Hacker News

Principled GraphQL

principledgraphql.com

41–50 of 88 posts

Re: Principled GraphQL

#41

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)

[deleted]

Re: Principled GraphQL

#42

Earlier quoted context omitted.

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.

How about having N base graphs and the ability to make unions of the graphs, as well as other kinds of algebra. It is relatively easy to do this in the RDF world since the graph is composed of individual facts which may or may not be in a particular graph.

Which triplestore are you using that gives great front-end performance at load?

Re: Principled GraphQL

#43
post #38

I'm experiencing some frustration with this. Click on this principledgraphql.com site and you find it's 'Apollo.' Nearly everywhere you look on the Internet regarding GraphQL you find 'Apollo' being injected. I'm using GraphQL in production systems. One is Node (graphql-js) and another is Java (graphql-java.) I read the GraphQL specification and adopted the reference implementation and it works great. Am I missing so…

It's called marketing and they're pretty good at it. They do provide some useful tools however if you want to use them and don't just blindly follow the docs (which are selling you on things you may/may not need).

Re: Principled GraphQL

#44

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…

I agree. I think their recommendation is a bit overzealous.

I can see the argument if you have a web frontend that consumes data from multiple backend services – have one GraphQL service that manages them all instead of a GraphQL layer on each service.

But this breaks down greatly when you have different "Viewers". In a web app, the "Viewer" can be a logged in user. In an admin dashboard, the "Viewer" is very different – an employee acting on behalf of users. Service to service communication likely doesn't have a concept of a "Viewer".

I would propose that you have different schemas when you have these different views of the world or different permission boundaries. The business logic can be shared – you may just enforce different authorization checks at the GraphQL layer. You could also share GraphQL types that are common between schemas.

Re: Principled GraphQL

#45

Earlier quoted context omitted.

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.

Many GraphQL libraries take some sort of schema definition and then serve it at a route (eg. /graphql). To support multiple schemas, you'd just write a different definition and serve it at a different route. How you resolve the fields is up to you, but both can use shared underlying business logic in these resolvers.

In terms of maintainability, you have to take care that your changes to the underlying business logic don't break assumptions of each schema. And if you want to evolve one schema (eg. say, deprecate a mutation argument, rename a field and deprecate the old naming), you have to ensure that your underlying business logic is backwards compatible for any other schemas (and their clients) relying on it.

Re: Principled GraphQL

#46
post #38

I'm experiencing some frustration with this. Click on this principledgraphql.com site and you find it's 'Apollo.' Nearly everywhere you look on the Internet regarding GraphQL you find 'Apollo' being injected. I'm using GraphQL in production systems. One is Node (graphql-js) and another is Java (graphql-java.) I read the GraphQL specification and adopted the reference implementation and it works great. Am I missing so…

Back in the Relay Classic days, the Apollo client library was a lot easier to use and a lot less heavyweight than Relay. My team ripped out Relay and replaced it with Apollo early in development because we felt Relay was too confusing. Relay Modern may be better; I haven't used it.

They're also intending to make most of their money by promoting GraphQL as a tool, so low rates of adoption are an existential risk for their company, while Facebook only needs GraphQL as a PR and recruitment tool.

Re: Principled GraphQL

#47
post #38

I'm experiencing some frustration with this. Click on this principledgraphql.com site and you find it's 'Apollo.' Nearly everywhere you look on the Internet regarding GraphQL you find 'Apollo' being injected. I'm using GraphQL in production systems. One is Node (graphql-js) and another is Java (graphql-java.) I read the GraphQL specification and adopted the reference implementation and it works great. Am I missing so…

They're one of the few companies who are building GraphQL developer tools, so they have a financial incentive to have their name associated w/ GraphQL.

This piece, while somewhat valuable, is largely content marketing. First they sell you on the idea of "best practices." Then they'll follow up w/ a tool that, surprise, does all those "best practices" for you. "The modern marketer creates their own demand." Prisma is another GraphQL company that produces content like this.

Re: Principled GraphQL

#48

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.

key/value storage

Re: Principled GraphQL

#49
Why does HN pretend it's posting your comment and show you that it's posted, when this is BULLSHIT and no one else can see it?

I posted a simple question about GraphQL and then came back to see if anyone had insights, only to find that no one else could see it.

So... the solution is to create a new user ID before every question?

Where do these guys get off deliberately wasting users' time?

Post reply on HN