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

21–30 of 88 posts

Re: Principled GraphQL

#21

Post by debergalis »

pseudoramble wrote: post #6

One 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…

[author here]

> 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?

I think these are great questions. One approach that looks promising is the idea of modular schemas that can be stitched together into a larger graph. Quite a few large organizations are doing this now. I recommend watching a recent talk by Martijn Walraven for more on this idea: https://www.youtube.com/watch?v=OFT9bSv3aYA

Re: Principled GraphQL

#22

Post by PaulHoule »

andrewingram wrote: post #16
PaulHoule wrote: post #15

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.

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.

Re: Principled GraphQL

#23

Post by seanwilson »

avitzurel wrote: post #19
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.

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

I like GraphQL outside of these points as well because it's more opinionated than REST. It means you can get on with things instead of having long disagreements about what is and isn't RESTful.

Re: Principled GraphQL

#24

Post by sheeshkebab »

lopatin wrote: post #18
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.

I don’t think it is - mutations (and state management) are the biggest issue. It’s ok for reads though, although even there tooling for rest is better.

Re: Principled GraphQL

#25

Post by RussianCow »

sheeshkebab wrote: post #24
lopatin wrote: post #18

Earlier quoted context omitted.

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.

I don’t think it is - mutations (and state management) are the biggest issue. It’s ok for reads though, although even there tooling for rest is better.

> I don’t think it is - mutations (and state management) are the biggest issue.

How so? I don't think GraphQL mutations are any worse than their REST equivalents, especially once you get more complex than "update these fields on this entity".

Re: Principled GraphQL

#26

Post by tlrobinson »

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…

Is there any reason you couldn't have multiple graphs essentially overlaid on top of each other? With proper tooling you could expose different subsets of the same schema in different scenarios, and still have one unified graph underneath.

Re: Principled GraphQL

#27

Post by jcroll »

lopatin wrote: post #18
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.

Have you had to maintain the graphql server

Re: Principled GraphQL

#28

Post by debergalis »

tlrobinson wrote: post #26
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…

Is there any reason you couldn't have multiple graphs essentially overlaid on top of each other? With proper tooling you could expose different subsets of the same schema in different scenarios, and still have one unified graph underneath.

Agree. And congrats on the round.

Re: Principled GraphQL

#29

Post by andrewingram »

tlrobinson wrote: post #26
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…

Is there any reason you couldn't have multiple graphs essentially overlaid on top of each other? With proper tooling you could expose different subsets of the same schema in different scenarios, and still have one unified graph underneath.

See my reply to another comment. But yeah, there’s no fundamental reason. But it’s conceivable that the difference goes beyond simple subsets of fields, but entire relationships being hidden.

Let’s say in your internal model there’s a relationship A - B - C. But for client apps it makes no sense to expose B, so instead you choose to represent the model as A - C. This is more than just a simple subset. Someone who understands graph theory better than I may be able to explain if there are elegant approaches to this.

Re: Principled GraphQL

#30

Post by mst »

There's nothing that says "we're really good at making front end development easier" like a website where even after I click into the main frame it completely fails to respond to up/down/pgup/pgdown ... I understand the whole "should work on mobile" thing but it should also bloody well work on a desktop too :(
Post reply on HN