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

31–40 of 116 posts

Re: The GraphQL stack: How everything fits together

#31

Post by guelo »

elnygren wrote: post #27
stuartaxelowen wrote: post #24

Why graphql instead of SQL with proper access control?

This question does not make much sense: a GraphQL API can an often is implemented with SQL ! You could ask: why graphql instead of RESTful?

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.

Re: The GraphQL stack: How everything fits together

#32

Post by Cthulhu_ »

dmitriid wrote: post #25

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

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

The aim of GraphQL insofar as I understand it is that instead of having to develop two things (a front-end and a back-end REST API that talks to your database or other services), you need just one (a front-end that talks to GraphQL). Mind you, graphQL becomes the back-end-for-front-end then, and will still need a lot of work. The main point is that with GraphQL you'll only need one for all of your apps, while traditionally you'd write one REST API for each client.

Re: The GraphQL stack: How everything fits together

#33

Post by dmitriid »

Cthulhu_ wrote: post #32
dmitriid wrote: post #25

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

> It's called REST APIs and we've known how to do them since 2001. The aim of GraphQL insofar as I understand it is that instead of having to develop two things (a front-end and a back-end REST API that talks to your database or other services), you need just one (a front-end that talks to GraphQL). Mind you, graphQL becomes the back-end-for-front-end then, and will still need a lot of work. The main point is that wi…

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

Re: The GraphQL stack: How everything fits together

#34

Post by jacobr »

JackuB wrote: post #21
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.

I would say Backend For Frontend solves the same problems for most people, and the tooling around REST is available everywhere.

http://samnewman.io/patterns/architectural/bff/

We have data repositories living behind very simple REST controllers, an endpoint probably doesn't take that much longer to write than a GraphQL query.

Re: The GraphQL stack: How everything fits together

#35

Post by jacobr »

dmitriid wrote: post #33
Cthulhu_ wrote: post #32

Earlier quoted context omitted.

> It's called REST APIs and we've known how to do them since 2001. The aim of GraphQL insofar as I understand it is that instead of having to develop two things (a front-end and a back-end REST API that talks to your database or other services), you need just one (a front-end that talks to GraphQL). Mind you, graphQL becomes the back-end-for-front-end then, and will still need a lot of work. The main point is that wi…

> 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 to these endpoints as well since they are so trivial.

Re: The GraphQL stack: How everything fits together

#36

Post by jasode »

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 and zipcode and you only wanted it for region of New York. (Unfortunately, "SELECT ∗" returned 30 columns which is 28 more than you need. The REST endpoint also didn't have a SQL WHERE clause which returned all 1000 rows where you only needed 20 rows.) You actually only needed 10k out of that 100k so you threw away 90k of data. Downloading data you throw away is especially wasteful with smartphones on slow mobile connections.

To address the finer grained slices of data, you either create more REST endpoints ("xyz.com/customerlist_name_zipcode") or add query parameters at the end of that 1 REST endpoint. It's doable but multiple endpoints will lead to a combinatorial explosion and the maintenance of them is not ideal for fast iteration.

With GraphQL, the client can request the "shape" of the data without having a pre-defined static REST endpoint that matches that shape. You can thin-slice the data without wasted bytes. The clients can get unforseen shapes of data that the developers of REST endpoints didn't envision.

I actually think the GraphQL landing page explains the rationale and motivation very clearly: http://graphql.org/

Re: The GraphQL stack: How everything fits together

#37

Post by boubiyeah »

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 with REST; you have to code against all the possible variations (primary resources, filters, sorts, etc) and optimize the DB/remote reads. So no, the users have no more freedom, the server remains the limiting factor.

The way it lets you compose queries is nice for developers, but you can very easily do that with a single aggregation REST endpoint too, provided you have resource links in your responses (which also makes it nice to use with human tools like POSTman) and you can still cache the individual REST responses with Varnish, etc.

Doing Subscriptions or mutations over GrapQL brings very little benefits. In fact, it's even dangerous as most system shouldn't allow multiple mutations per request.

The whole "just cache it on the client" is a big joke and many people seem to underestimate getting caching right. The default in Relay used to be "cache forever", this can't be serious. You could only do that if the current user was the only person able to modify the data or if you could guarantee a perfect synchronization with the server via continuous events and that's actually pretty hard to get right and generally a big investment. In practise, most apps/sites don't work like that.

I'm not sure what that leaves? "Free" barebone documentation? You can have that too with a good type system (e.g scala's) albeit with a lot more work but with a much nicer type system / expressivity.

I mean, I get why it's popular, but the thing's totally blown out of proportion.

Re: The GraphQL stack: How everything fits together

#38

Post by Touche »

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 without that sort of problem, I have no idea. Because the query syntax is pretty?

Re: The GraphQL stack: How everything fits together

#39

Post by yen223 »

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…

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, which is the only reason they're still around at all - it's so hard to make changes if you have little idea which client-side code depends on which field.

Re: The GraphQL stack: How everything fits together

#40

Post by cvburgess »

Svenstaro wrote: post #3

Has anybody found a way to combine GraphQL and REST in a common API? I've searched but so far found no idiomatic ways to accomplish that. The reason I need REST in addition to GraphQL is that there are sometimes oddball cases where only GraphQL is a poor fit or where compatibility with older clients that I can't modify has to be ensured. Also, is there a good way to do file upload of big files with GraphQL nowadays?

During a Q&A at GraphQL Summit, GitHub said that they are accomplishing this by making their REST endpoints use the GraphQL API instead of querying the data directly. They’ve been releasing the talks online slowly so that should be available soon.
Post reply on HN