Hacker News Reader

Comment by jfaucett | Hacker News Reader

I've just started working on a graphql project now and from the frontend perspective its phenomenally better than a rest api. The backend side of things is also pretty simple so I'm really enjoying it.

With Rest APIs there's always the problem (with numerous solutions) of how you select the particular fields and how you nest and or do not nest the resources in the api. With GraphQL this is more or less a non-issue - the client just requests want he wants and gets it back if he's allowed access to it.

I know GraphQL has been around for a while but this has been my first full go with it and I could easily forsee it doing to REST what REST did to SOAP - at least for the use case of building frontend clients that consume some api.

View on HN

I'm kind of hoping that nesting resources becomes a non-issue in the future once HTTP/2 is widespread. Ideally you don't ever nest resources. With HTTP/2 the overhead of additional requests can be significantly lower, and you get the benefit of using client cache.

This becomes pretty powerful once cache digests land, so a HTTP/2 REST service can just proactively push only the resources to the client that it has an (up-to-date) copy of.

Nesting resources is a bit of an anti-pattern imho, and the solution looks bad because it's a poor fit in the protocol.

Of course, all of this is a bit of a moot point if you don't believe in addressable/linkable resources as a good solution. If you're not doing/believing in hypermedia in REST, you're much better off with something like GraphQL because it provides a very complete solution. You just need a ton of domain knowledge to be successful at proper REST.

But you're still going to make lots of requests which result in inefficient data access on the server unless you batch them up. So you just end up moving batching from the client where it is easy, to the server where it is hard.

It's hard but solvable. If the data comes mainly from one database (although you can do some cools stuff with FDW in Postgres) then each graphql query can be translated to a single SQL query and it works quite efficiently, only one trip to the db (https://subzero.cloud/)

HTTP/2 doesn't fix the problem of loading data dependencies over a connection with a noticeable round trip latency. Even with server push, you need some way of defining what is to be pushed.

As a very contrived example, one page might show users who have access to servers in availability zones in aws regions. With an unnested rest api doing nothing intelligent with server push over a 250ms round trip, you're looking at a second of overhead just for sending ids back and forth.

Of course, there are ways of defining inclusion that are closer to restful than graphql is.

Falcor sort of solves this by allowing you to communicate "references" in the graph. For example, it might inform you that users.52.friends.1 is actually users.45, so the client will cache it at that location instead.

This is less complicated than GraphQL's solution of using the Relay Node interface.

That solves the problem of data normalization, not of determining what to fetch. Falcor solves the second problem with paths, but that's still a custom abstraction that the API has to understand.

Relay and GraphQL aren't the same beast. One of the reasons to choose Apollo is to avoid the extra complications which Relay adds.

GraphQL has a lot more to offer than just batching requests. I think that's one of the less important features actually. A common way to declare exactly what objects and attributes you want is more important, you can invent something like that for REST but you'd be reinventing the wheel for every endpoint.

Exactly. For the first time you have a common language to talk to your RDBS, NoSQL db, cache system and API, or a mix of all of them transparently, from anywhere in your architecture, including remote microservices and the browser.

HTTP/2 won't save you round-trips as you follow REST hypermedia links.

sure it will. client requests a resource, server sends back the response with some links to further requests. it can also send the results of those requests with zero intervention from the client. when the client requests them, they're already en route or cached locally

this assumes you have high confidence the client will actually request those links (or you can afford to send them even with low confidence) but you can use media types or query parameters to mitigate that

Let's look at an analogy: Amazon Prime delivers in a day by now. With the customer info, Amazon can also send stuff directly/monthly. That's HTTP2.

The user chooses several products in one order. When you add the product in the basket, Amazon suggests some products that are often ordered at the same time, like extra supply or accessories. That's GraphQL.

GraphQL assumes shipping something cost money, and forces the client to declare what it wants explicitely and in detail. Like SQL without SELECT *. Hope that helps!

Reply on news.ycombinator.com