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

111–116 of 116 posts

Re: The GraphQL stack: How everything fits together

#111

Post by jrs95 »

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…

You could do pretty much any of the things you describe, actually. Auth is really not straightforward at all though, they could definitely do a better job at making it easier to get started with GraphQL.

Re: The GraphQL stack: How everything fits together

#112

Post by jrs95 »

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…

It really isn't just an optimization, though. I actually work at a relatively small team (At the same time, I agree that it's overly hyped. It's not some magic bullet, and there's definitely a learning curve. It's a really powerful tool though, much more than just an optimization.

Re: The GraphQL stack: How everything fits together

#113

Post by jrs95 »

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…

The query syntax isn't just pretty. It's simple enough non-technical users can actually use it with very little training.

Re: The GraphQL stack: How everything fits together

#114

Post by stuartaxelowen »

exogen wrote: post #110
guelo wrote: post #31

Earlier quoted context omitted.

Of course it makes sense. They're both query languages, right? Why is { project(name: "GraphQL") { tagline } } Better than select tagline from project where name = "GraphQL" Especially if the GraphQL server is just an intermediary later that ends up being translated to SQL anyway. That real answer to the parent's question is that most people don't have confidence in SQL servers's access controls.

One immediate improvement: SQL queries return rows of scalars. It's very tedious to reconstruct nested objects from the resulting column aliases that are ultimately necessary (and in this case, the client would even need to do it all themselves!). Your example is simplistic in that it requests one top-level scalar, but any real API will not be like that. Try: { project(name: "GraphQL") { tagline authors { name friend…

Modern SQL databases like PostgreSQL offer full JSON capabilities to serve this need.

Re: The GraphQL stack: How everything fits together

#115

Post by exogen »

stuartaxelowen wrote: post #114
exogen wrote: post #110

Earlier quoted context omitted.

One immediate improvement: SQL queries return rows of scalars. It's very tedious to reconstruct nested objects from the resulting column aliases that are ultimately necessary (and in this case, the client would even need to do it all themselves!). Your example is simplistic in that it requests one top-level scalar, but any real API will not be like that. Try: { project(name: "GraphQL") { tagline authors { name friend…

Modern SQL databases like PostgreSQL offer full JSON capabilities to serve this need.

I've used its JSON support extensively and no, it's not really the same at all. What you're saying is that you're OK with (1) planning to not use columns to store your individual data fields in the first place, forgoing the primary SQL features of column-based lookup, joins, etc., or (2) having the client write complicated Postgres-specific SQL queries that dynamically construct JSON strings built from the fields that are stored in the real row structure.

Re: The GraphQL stack: How everything fits together

#116

Post by brycesteinhoff »

jacobr wrote: post #44
dmitriid wrote: post #43

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

I don't think APIs in general should have anything to do with authorization, other than passing along a token.
Post reply on HN