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

The GraphQL stack: How everything fits together

dev-blog.apollodata.com

Post reply on HN
Print view View original

41–50 of 116 posts

Re: The GraphQL stack: How everything fits together

#41

Post by mej10 »

boubiyeah wrote: post #37

GraphQL is above all, just an optimization. It optimizes the amount of bytes sent over the network. I'm very happy with REST APIs (maturity level 2/3) and see no reason to change as we've never had performance issues. Most companies are not Facebook with 1 billion customers. The fact that clients can compose their own queries brings nothing new, as you still have to allow these capabilities on your server, just like…

Do you have good examples of

> easily do that with a single aggregation REST endpoint too, provided you have resource links in your responses

I work with/on a "REST" API that has about 20 types of objects, 5-100 fields on each, with many different relationships between them. We've been looking at GraphQL to solve both the querying and mutation aspect, since it is extremely cumbersome to do it efficiently.

GraphQL seems great for this case, but if there is some way just adding resource links could get us most of the benefits I'd love to hear it!

Re: The GraphQL stack: How everything fits together

#42

Post by typon »

jasode wrote: post #36
d3ckard wrote: post #18

Can anybody explain to me how it's solving any problems? The way I see it they only move the responsibility to combine data from client to server. At the same time, you now don't just expose a couple of endpoints, you need to support a query language, which seems to impose much more effort in things like authorization. I admit I don't see the benefit.

>, you now don't just expose a couple of endpoints, you need to support a query language, Here's how I think of it. (Others can correct or elaborate my understanding.) Let's say you have 1 REST endpoint such as "xyz.com/customerlist" to return a JSON response and behind the implementation is a SQL "SELECT ∗ FROM T" and you get back a 100k response with all rows and all columns. You really only wanted customer's name…

What if you had one one endpoint called xyz.com/sqlquery and you would just send it a SQL Query in the form a string, the server would validate it and authorize it and return the data or reject the request.

Is that different than GraphQL?

Re: The GraphQL stack: How everything fits together

#43

Post by dmitriid »

jacobr wrote: post #35
dmitriid wrote: post #33

Earlier quoted context omitted.

> you'd write one REST API for each client. Erm... What? Granted, web requirements are a bit different from mobile requirements, but still. Why would you write one REST API for each client?

Because requirements are different. Our admin GUI needs much more data and different access controls than our web and mobile apps. Third party consumers have even more different requirements. We never need to bikeshed with developers from all other teams to make sure things are consistent or whatever. We generate endpoints from a Swagger spec. With good abstractions it is not much work. Frontend devs do modifications…

> Because requirements are different. Our admin GUI needs much more data and different access controls than our web and mobile apps.

Indeed. And how does GraphQL solve the need for different data and different access controls to that data? :)

Re: The GraphQL stack: How everything fits together

#44

Post by jacobr »

dmitriid wrote: post #43
jacobr wrote: post #35

Earlier quoted context omitted.

Because requirements are different. Our admin GUI needs much more data and different access controls than our web and mobile apps. Third party consumers have even more different requirements. We never need to bikeshed with developers from all other teams to make sure things are consistent or whatever. We generate endpoints from a Swagger spec. With good abstractions it is not much work. Frontend devs do modifications…

> Because requirements are different. Our admin GUI needs much more data and different access controls than our web and mobile apps. Indeed. And how does GraphQL solve the need for different data and different access controls to that data? :)

Not sure, I haven't seen a good story for it. We'll stick with REST.

Re: The GraphQL stack: How everything fits together

#45

Post by nijynot »

typon wrote: post #42
jasode wrote: post #36

Earlier quoted context omitted.

>, you now don't just expose a couple of endpoints, you need to support a query language, Here's how I think of it. (Others can correct or elaborate my understanding.) Let's say you have 1 REST endpoint such as "xyz.com/customerlist" to return a JSON response and behind the implementation is a SQL "SELECT ∗ FROM T" and you get back a 100k response with all rows and all columns. You really only wanted customer's name…

What if you had one one endpoint called xyz.com/sqlquery and you would just send it a SQL Query in the form a string, the server would validate it and authorize it and return the data or reject the request. Is that different than GraphQL?

Then you need to validate, authorize, etc. queries correctly. I see no reason why anyone would want this.

Instead use GraphQL which is a thin layer, and hide all the business logic behind it. Way more manageable.

Re: The GraphQL stack: How everything fits together

#46

Post by boubiyeah »

mej10 wrote: post #41
boubiyeah wrote: post #37

GraphQL is above all, just an optimization. It optimizes the amount of bytes sent over the network. I'm very happy with REST APIs (maturity level 2/3) and see no reason to change as we've never had performance issues. Most companies are not Facebook with 1 billion customers. The fact that clients can compose their own queries brings nothing new, as you still have to allow these capabilities on your server, just like…

Do you have good examples of > easily do that with a single aggregation REST endpoint too, provided you have resource links in your responses I work with/on a "REST" API that has about 20 types of objects, 5-100 fields on each, with many different relationships between them. We've been looking at GraphQL to solve both the querying and mutation aspect, since it is extremely cumbersome to do it efficiently. GraphQL see…

This is a POC in scala I put together rather quickly:

https://github.com/AlexGalays/POC-api-aggregation

How you would write a query:

https://github.com/AlexGalays/POC-api-aggregation/blob/maste...

Unfortunately the PokeAPI is not the best at showcasing this with many level of unneeded nesting and resources with nothing but an "url" property but hopefully you get the idea :)

The fact that the query "language" is indendation based rather than GraphQL's a-string-that-looks-a-bit-like-json-but-isnt was just an arbitrary choice, it's easy to change.

Re: The GraphQL stack: How everything fits together

#47

Post by nijynot »

jondubois wrote: post #15

My main concern with GraphQL is access control. What happens if the user doesn't have access to part of the requested data (a subtree)... Will the GraphQL engine return an incomplete result, an inline error or will the whole query fail? What if you only want to allow showing specific fields of a resource; for example when a user requests for another user's account details, we need a way to block them from getting cer…

The solution for authorization/access control is to use "Dataloader" [1] which is also made by Facebook. You write a single source of truth for how authorization is handled, and make sure that graphql resolves with this source.

Dataloader is not as well known as GraphQL, but crucial for complex authorization systems imo. It also has a bunch of other features like batching and caching which makes your life easier when opting for this solution.

[1]: https://github.com/facebook/dataloader

Re: The GraphQL stack: How everything fits together

#48

Post by [deleted] »

Touche wrote: post #38
boubiyeah wrote: post #37

GraphQL is above all, just an optimization. It optimizes the amount of bytes sent over the network. I'm very happy with REST APIs (maturity level 2/3) and see no reason to change as we've never had performance issues. Most companies are not Facebook with 1 billion customers. The fact that clients can compose their own queries brings nothing new, as you still have to allow these capabilities on your server, just like…

Can't upvote this enough. From what I've read it sounds like GraphQL solves a problem at Facebook where they have so many people working on related data at the same time that they started seeing duplicate API endpoints, and duplicate requests for the same data from different parts of the team. GraphQL provides a chokepoint to prevent that from occurring. Makes total sense at that scale. Why startups are adopting this…

[deleted]

Re: The GraphQL stack: How everything fits together

#49

Post by boubiyeah »

yen223 wrote: post #39
d3ckard wrote: post #20

Earlier quoted context omitted.

That I understand. The problem is that on the way you basically reduce your server to the thin layer over DB. Exposing querying API means that you significantly lose control over what, where and how you provide from the server. We are currently considering using GraphQL in current project and I took a long look at both the standard and library (Absinthe for Elixir). It looks terrible to me. Basically you need to prov…

We've used GraphQL in production for about a year now, alongside some legacy rest APIs. It's a lot easier to maintain the GraphQL endpoint, like it's not even close. GraphQL's secret weapon is the static type definition. We can safely alter fields in the backend, and be notified at compile-time if client-side code is about to break as a result of those changes. We don't have the same guarantees with the rest api, whi…

Are you talking about a single client and its server? (a.k.a backend-for-frontend). This is not a hard problem to solve when you share a single programming language, with or without graphql.

Because you can't possibly now what your API consumers use on their side.

Re: The GraphQL stack: How everything fits together

#50

Post by mxstbr »

nijynot wrote: post #47
jondubois wrote: post #15

My main concern with GraphQL is access control. What happens if the user doesn't have access to part of the requested data (a subtree)... Will the GraphQL engine return an incomplete result, an inline error or will the whole query fail? What if you only want to allow showing specific fields of a resource; for example when a user requests for another user's account details, we need a way to block them from getting cer…

The solution for authorization/access control is to use "Dataloader" [1] which is also made by Facebook. You write a single source of truth for how authorization is handled, and make sure that graphql resolves with this source. Dataloader is not as well known as GraphQL, but crucial for complex authorization systems imo. It also has a bunch of other features like batching and caching which makes your life easier when…

I've only ever seen DataLoader used for batching database queries, how do you create a single source of truth for authorization with it? Do you have a code snippet somewhere?
Post reply on HN