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

21–30 of 116 posts

Re: The GraphQL stack: How everything fits together

#21

Post by JackuB »

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.

It got more approachable for me when I started to think about it as a specific "backend for frontend" pattern. I don't see it as a _real_ competitor to REST, even though it's trying to market itself this way.

I think recent "@rest" addition from Apollo ( https://dev-blog.apollodata.com/apollo-client-2-0-5c8d0affce... ) shows they can easily live together - backend uses REST and frontend can rely on GraphQL.

Re: The GraphQL stack: How everything fits together

#22

Post by andrewingram »

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…

Model access control into the schema. Create a BaseUser type and an UnauthorizedAccess type, then a union of the two, refer to the union in nearly all scenarios where you want to create a relationship to a User.

GraphQL gives you access to a relatively powerful (but sadly incomplete) type system, you have a much better time if you take full advantage of it.

Re: The GraphQL stack: How everything fits together

#23

Post by andrewingram »

d3ckard wrote: post #20
sorenbs wrote: post #19

Earlier quoted context omitted.

Moving the responsibility of combining data to the server is a huge advantage for many organisations. It allows application developers to move much quicker and provides a common data access layer for all applications. It sounds to me like you are over-indexing on the burden placed on the backend developer in your evaluation and not considering the whole picture. From my experience, the biggest advantage of GraphQL is…

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…

Think of a GraphQL server as client code that happens to live on the server.

Re: The GraphQL stack: How everything fits together

#25

Post by dmitriid »

> GraphQL knows all of the data requirements for a UI component up front, enabling new types of server functionality. For example, batching and caching underlying API calls within a single query becomes easy with GraphQL.

And immediately after that the article spends two pages of text explaining how insanely complex the "becomes easy with GraphQL" really is, and offers no actual details on the "easy" part.

Oh, your client has to be cache aware. Oh, and there has to be a gateway that's cache aware, and schema aware, and has to cache all responses... And invalidate them... But there are no tools yet. And then the graphql server should be cache aware. Oh, and your database layer should also cache all responses.

Caching is a hard problem, and there's nothing in GraphQL to make it easier. Heck, exclusively relying on POST requests they deliberately remove the most obvious and the easiest part of the equation.

I love how the every next part, starts ,with a sentence that shows how complex caching with GraphQL is (emphasis mine):

> With GraphQL, frontend developers have the capability to work with data in a much more fine-grained way than with endpoint-based systems. They can ask for exactly what they need, and skip fields they aren’t going to use.

I would love to see an explanation how GraphQL makes caching for this easy.

> Schema stitching is a simple concept: GraphQL makes it easy to combine multiple APIs into one, so you can implement different parts of your schema as independent services. These services can be deployed separately, written in different languages, or maybe even owned by different organizations.

It's called REST APIs and we've known how to do them since 2001.

Re: The GraphQL stack: How everything fits together

#26

Post by schickling »

andrewingram wrote: post #22
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…

Model access control into the schema. Create a BaseUser type and an UnauthorizedAccess type, then a union of the two, refer to the union in nearly all scenarios where you want to create a relationship to a User. GraphQL gives you access to a relatively powerful (but sadly incomplete) type system, you have a much better time if you take full advantage of it.

Which features are you missing in GraphQL's type system?

Re: The GraphQL stack: How everything fits together

#28

Post by andrewingram »

schickling wrote: post #26
andrewingram wrote: post #22

Earlier quoted context omitted.

Model access control into the schema. Create a BaseUser type and an UnauthorizedAccess type, then a union of the two, refer to the union in nearly all scenarios where you want to create a relationship to a User. GraphQL gives you access to a relatively powerful (but sadly incomplete) type system, you have a much better time if you take full advantage of it.

Which features are you missing in GraphQL's type system?

Unions on scalars, unions on input types, intersection types, and generics. Arrays are already a generic type, but we're unable to create new ones.

Re: The GraphQL stack: How everything fits together

#29

Post by Cthulhu_ »

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.

It solves problems if you are an organization with many endpoints and data models (think hundreds if not thousands), and you can't predict how that data will be used because you have dozens or hundreds of clients, each with specific data needs - more or less fields, joins and mixes of data from various sources, etc.

It ties in to the microservices architecture, I'd say.

Re: The GraphQL stack: How everything fits together

#30

Post by Cthulhu_ »

stuartaxelowen wrote: post #24

Why graphql instead of SQL with proper access control?

Two completely different things. Would you have clients type in raw SQL? I mean I guess they're comparable in that they're both query languages, but the application is quite different. You probably could come up with a safe way to send SQL queries to an api, or and SQL-to-GraphQL if you prefer SQL.
Post reply on HN