
Is GraphQL Still Relevant in an HTTP2 World? - dcminter
https://medium.com/@__xuorig__/is-graphql-still-relevant-in-an-http2-world-64964f207b8
======
whack
From the linked article:

> _With all of those caveats noted, HTTP /2 should put to rest any notion of
> the need to minimise the number of requests for APIs; the protocol makes
> them cheap enough to not practically matter. Go ahead and design a highly
> granular HTTP API to meet the needs of your clients_

This seems highly misleading and missing the point. Sure, you can send a lot
of requests in parallel with http/2\. But you still incur significant latency
if these multiple requests are dependent on one another and serialized. For
instance, suppose you have 2 granular APIs that:

\- Returns all friends for the specific user

\- Returns the name, age and hometown for a specific user

Suppose your client wants to get all of a user's friends whose hometown is
NYC. Even with http/2, it has to use the first API, wait for the response
containing a list of userIDs, then use the second API to get all of their
hometowns.

Whereas with GraphQL, it facilitates building a single API call that says
"give me all friends for a specific user, along with each friend's hometown".
Now, there is only one round-trip latency cost. Not two. Even with the
overhead improvements mentioned, the cost of two back-to-back round-trips
would be much higher. It is very odd that this isn't mentioned in the article
or any of the other articles they reference.

~~~
MapleWalnut
Why wouldn’t you return more data for the REST API instead of making dependent
requests?

~~~
baddox
GraphQL can support arbitrary numbers of fields and arbitrary nesting of
relationships. You can do this:

    
    
        {
          hero {
            name
            friends {
              name 
                friends {
                  name
                }
            }
          }
        }
    

But some clients might only need this:

    
    
        {
          hero {
            name
          }
        }
    

This is a small example, but it's pretty clear that "always including all
fields and nested relationships in every REST API response" is not a viable
solution.

(GraphQL examples based on the schema used in the official documentation:
[https://graphql.org/learn/queries/](https://graphql.org/learn/queries/))

~~~
xrd
This is the most important comment in this thread. For more, read this
excellent article:

[https://brandur.org/graphql](https://brandur.org/graphql)

------
ergothus
I worked with GraphQL a bit over a year and half ago on a project. I was the
front end consumer, working with backend microservices via graphQL.

I wasn't sold on the GraphQL hype then, and I'm still not, but this article
seems to miss the point. [Edit: I mean, it agrees, but it does so poorly]

A lot of people TALK about the lack of multiple back-and-forth, and about not
wasting unnecessary data, but honestly, that wasn't a big deal. I expect there
are some situations where that comes into play, but for most people the appeal
of GraphQL lies elsewhere. If HTTP/2 means that's less of a big deal, I don't
expect much change.

The legit upside to GraphQL was that backend could change rapidly without
breaking compatibility for existing consumers. Some changes could be fixed
purely frontend by changing the query, but if we needed new data that wasn't
provided (or a variation on data that was provided) the backend could add that
AND NOT IMPACT EXISTING CONSUMERS. That's not the only benefit (and remember,
I remain a skeptic) but that was by far the biggest and was definitely real.

Even if the claims of HTTP/2 rendering the call overhead are correct (see
other comments to doubt that), that has no impact on this value of GraphQL.

~~~
MuffinFlavored
> I wasn't sold on the GraphQL hype then, and I'm still not,

Why not?

~~~
ergothus
Foremost, I'm not comfortable with abandoning the meaning of HTTP methods.
Changing everything to POST means pushing all sorts of caching decisions to
the start-and-end points and bypassing decades of work done on improving GET
caching for intermediate layers. (Caveat: this is where people start talking
about how GraphQL doesn't _require_ POST. I fully allow I don't know enough to
be sure, but on the face it seems problematic).

Secondly, it may just be something solved as the tech becomes more mature and
practiced, but there are numerous smaller issues such as versioning (the
ability to change rapidly without breaking backward compatibility is separate
from when you DO want to break that compatibility) and tooling. These are
hardly solved issues with, say REST, but they are "more solved". Most places
have some level of versioning, and requests are trivial to read with existing
tooling.

When doing an involved front end app (I was in ag tech working on app that was
tying data models with farm field overlay maps and setting values by
geographic region - which sounds way more impressive than it really is) I
found that GraphQL seemed great for straightforward CRUD apps, where the
results of a query and the display of the page mapped closely, but the value
add on the front end was pretty minimal for more complex applications. Lots of
tooling (Apollo at the time, and I hear "Relay" being discussed today)
performs magic to make this all effortless.

"magic" is great when it works - we adopt it and stop considering it magic.
The other times it is usually a flash in the pan that spawns lots of regrets.
I'd be an idiot to claim I knew which side of magic this falls on, but my
experience is currently saying to avoid anything too involved. A GraphQL API?
Sure, it's not my first pick but I'll use it. A framework that magically hides
all the complexity on the front end? I'm willing to bet I'll run afoul of some
hidden boundary.

If I'm at a company that starts talking GraphQL I'd ask about the solutions
for caching and versioning. If they have answers, I'll keep listening. If they
wave it off as something to worry about later, I'd expect headaches.

A long, rambling, and subjective answer, but that's my answer.

~~~
TurningCanadian
[https://www.apollographql.com/docs/ios/fetching-
queries/#usi...](https://www.apollographql.com/docs/ios/fetching-
queries/#using-get-instead-of-post-for-queries)

I use this in prod, and the only downside I'm aware of is the length limit on
the query string. (Haven't hit it though)

[https://stackoverflow.com/questions/2659952/maximum-
length-o...](https://stackoverflow.com/questions/2659952/maximum-length-of-
http-get-request)

------
wildermuthn
The biggest problem GraphQL solves is not a technical one. GraphQL is an
enforceable contract between clients and servers that encourages APIs to be
designed in a way that best serves the client, and in doing so, the end-user.
Clients used to spend an inordinate amount of time and thought in simply
getting the correct data from the server. So much so that entire FE frameworks
and libraries evolved to essentially pull all the server’s data, organize it
into UI-friendly chunks, and then (and only finally then) create an experience
the user would find valuable. It was a small miracle if any time or energy was
left to make the user experience enjoyable too.

A litmus test for a well designed GraphQL API is: could you tell what the
client looks like and what the client does simply by looking at the schema?
GraphQL forced everyone to think about the end-user experience, and to be on
the same page. Literally. And that is it’s greatest strength.

------
haack
It's refreshing that the author acknowledges the nuances around tradeoffs of
using, and not using, GraphQL.

Having used REST (with swagger/openAPI), gRPC and now graphQL, the most
painful thing has been the tribal militance from supporters of each, defending
their own vested interest.

It's almost like different tools are useful for different things.

~~~
jakenberg
> tribal militance from supporters of each, defending their own vested
> interest.

This is something I really wish I understood before going down the road of
graphql. I think it's a great technology, but the developers supporting it are
making it nearly impossible for a legacy codebase to ever adopt.

Ex: so many JS codebases use redux. Apollo is a popular graphql framework that
supported redux integration for some time, then suddenly ripped it out. They
cited performance concerns, but I looked through the code myself and it would
seem they just have a bias against redux. This issue thread makes that
especially evident: [https://github.com/apollographql/apollo-
client/issues/2273](https://github.com/apollographql/apollo-
client/issues/2273)

We were very lucky to have found that before breaking ground on the work.

~~~
ledauphin
Which is ironic because Apollo 2.0's caching mechanisms have some very serious
performance issues themselves, and they take almost all the power away from
the user (unless you want to implement your own cache from scratch).

~~~
Dockson
I believe one of the main selling points of the upcoming 3.0 version is indeed
to make the cache more usable with manual evictions, etc.

------
ilikehurdles
It would be irrelevant only if the sole reason to use GraphQL is to minimize
network hops and bandwidth. I'd argue that, if that's the only positive you
see in GraphQL, then you would be just as well off writing custom API
endpoints for each view of your application.

I prefer interacting with GraphQL over RESTful interfaces. From my experience,
it's less prone running into bugs inherent to client-side joins of API
responses, easier to evolve iteratively, and generally more pleasant to work
with thanks to its introspectable declarative schema and flexible query
language.

------
ClumsyPilot
This seems like a false dichotomy. In my eyes the point of GraphQL is the
query model.

HTTP2 is just a transport, you still need to put something on it, like gRPC.

Seems natural that GraphQL will evolve to use it, and benefit from the
technical improvements.

I really like the server push model, but not sure how to square it with
GraphQL way of doing things.

~~~
shusson
> In my eyes the point of GraphQL is the query model.

Yeah me too, I would compare restful to GraphQL and HTTP2 to HTTP1. It is also
annoying that the author hardly mentions restful APIs or it's shortcomings.

------
Exuma
Can someone please explain what GraphQL actually is? I've looked at it
multiple times but never got super deep... my limited understanding is that
all it is is basically defining a schema so that when issuing API requests,
the client itself can make it's own "query request", rather than talking to an
app backend which has SQL queries programmed/written in an ORM or some
database wrapper.

I feel like I'm missing something, as that seems incredibly limited,
especially with things like performance (where queries need to be tuned and
refined and custom written. Just a simple SELECT * FROM X INNER JOIN Y and
horrible N+1 isn't good enough)

Can someone please explain what is GraphQL once and for all?

~~~
nlh
Yes - (and totally reasonable question, btw - it's remarkable how hard it is
for the folks behind it to just plainly state what it is vs. coating it in
buzzwords).

BTW - I may be wrong / misunderstanding something here as I'm only in the
research phase, but here's what I got:

GraphQL is an alternative to REST as a way for clients to query servers for
information. In a REST query, you hit an endpoint and add optional query
params. But you get back results based purely on what the server has been
singularly designed to give back. For example, if I query:

GET /users/1

I'll get back a user object that the server has been programmed to return.
It's of course possible to customize this with query params, and do something
like:

GET /users/1?only_include=first_name,last_name

But that's the exception to most RESTful APIs, not the norm.

In a GraphQL query, the client specifies _exactly_ which fields it wants back,
and that's baked into the design. So the client would submit a query like
this:

{ user(id: "1") { first_name last_name } }

And the server would return exactly the object the client asked for.

There's no magic here -- that's the part that many people have trouble
explaining. When you write your GraphQL server, you still need to write the
actual queries (<\--- this is the key!). But structurally, you write more
generic queries -- you'd say "when a client requests a user, run this SQL",
"when a client requests first_name on a user, run this SQL", etc. etc.

That way on the server, you write isolated query resolvers (called, amazingly
enough, resolvers), each of which get run when a query comes in.

This is as opposed to a RESTful approach, where you'd do a more traditional
single SQL query for the /users/:id endpoint (SELECT * FROM USERS WHERE ID =
... )

Hope that makes sense (and is accurate!)

~~~
AndrewOMartin
Your understanding matches my understanding, but you missed the point which
was the "ah ha!" moment for me. Which is that the front end developer can
design their own endpoints without bothering the back end developer.

When a front end developer wants to request a specific shape of data (e.g. All
the people with age between x and y who are within a distance of z of the
logged in user and just get their name and list of interests) then with REST
they have to either compose that data from the available endpoints or bother a
back end developer for a new endpoint.

With GraphQL the front end developer can compose the query themselves without
knowledge of any back end technology beyond the GraphQL schema.

E.g. they'd write something like the following, using either a schema
reference, or introspection-powered autocomplete UI to find out which fields
are valid.

    
    
        query nearbyCandidates {
            allUsers(filters{
                isTheLoggedInUser:false,
                ageBetween:{start:x, end:y},
                closerThan:{distance: z, from: [LoggedInUserPosition]},
            }){
                interests:{
                    interestName:name,
                    description,
                }
                candidateName:name,
            }
        }
    

This actual story is a bit of a fairy tale because you'd still need the two
developers to interact if the required fields or filters did not exist.

Finally the general theme of the comments here, that there's nothing stopping
you using both, is accurate.

~~~
pier25
Unless you are using something like Hasura which in many cases negates the
need of a backend developer. Front end developers can have almost total
autonomy.

------
tannhaeuser
In a discourse where GraphQL is just an additional layer over "REST" services
to make sense in terms of network roundtrip, and similarly HTTP/2 server push
is used to bundle multiple "REST" results, it's worth noting that there's
always the option to use more unopinionated approaches to request/response
payloads such as RPC- or SOAP-like protocols merely seeking to model payload
syntax without implied semantics and restriction to "GET"/"PUT" primitives.
Locking your response semantics to network interactions such as in "REST"
never made sense from an engineering PoV IMHO.

------
hnrodey
We've been developing a GraphQL api for the past few years and I really really
really like using GraphQL. From a developer experience perspective, it's so
much easier to work with than traditional REST based API's. I could add more
but I'm pressed for time and I simply wanted to leave my +1 comment for
GraphQL. Happy to answer follow up questions (if any).

------
ex3ndr
Uh, main feature of graphql is a graph cache and graph model itself. It has
nothing to do with HTTP2.

~~~
drew-y
That's basically what the article says though. The connection to HTTP2 is that
they both try and minimize the amount of requests made to a server. The author
is just pointing out that GraphQL has more to offer than reduced requests.

~~~
Cshelton
Making a request to the server is completely different than opening a new
connection. HTTP/2 lets you use an already opened connection, if applicable.
Thus it is able to bypass making a handshake/etc. for every request made as
well. Making a request however will still have to traverse the network
irregardless. GraphQL gives you a query language to tell the server what you
want in a single request. So if it is your first request to server, and a new
connection needs to be opened, HTTP/2 is irrelevant. Basically, HTTP/2 and
GraphQL have NOTHING to do with each other.

~~~
ClumsyPilot
Even in Http 1.1 you can keep the connection open, you dont need to re-
negotiate tls and friends for every request.

[https://en.m.wikipedia.org/wiki/HTTP_persistent_connection](https://en.m.wikipedia.org/wiki/HTTP_persistent_connection)

------
why-oh-why
Ignorant here: why not just use a subset of SQL?

It needs a filter and it definitely needs to be applied to a limited, custom
view of the actual underlying data, but… that’s what you have to do anyway
with a REST or GraphQL API.

By the time you’re done making your REST/GraphQL API “really flexible”
couldn’t you just build an SQL filter?

All the APIs I used to so far are so limited. For example there’s no easy way
to query multiple posts at once on GitHub’s GQL while that could have be an
extremely simple `SELECT title FROM issues WHERE id IN (13,57)`

~~~
pier25
Or you could use a zero coding backend solution on top of a database like
Hasura or PostGraphile.

~~~
why-oh-why
Just like there’s Hasura there could be a zero-coding tool that does the same
for SQL.

I’m not arguing that the average developer should write an SQL query sanitizer
but just that what companies are investing into GQL could be invested into
something more flexible.

Sometimes we discard tools and ideas because at some point in the past they
were poor or bad practice. See PHP and IE.

------
Lapsa
Title sounds so wrong that I'm unable to click on it.

~~~
rinchik
Totally. doesn't make sense at all. Sounds like "Are burgers still relevant in
coffee-table world"? HUH? What the f did the author smoke before writing that?

------
sandstrom
This is an interesting article!

A few weeks ago I found an interesting open-source project that tries to
combine the best of GraphQL and REST, though it's more tilted towards REST.

[https://www.graphiti.dev/guides/](https://www.graphiti.dev/guides/)

We haven't switched our API over just yet, but are planning to do so.

~~~
jsjohnst
Graphiti is based on the JSONAPI standard. While Graphiti is an awesome
library (the author is one of the most supportive devs I’ve experienced with
OSS, rivaling most paid support I’ve experienced), JSONAPI has existed longer
than GraphQL, and has virtually no relationship with GraphQL or how it
functions.

------
paulddraper
1\. Depending your database technologies, queries are still going to be more
efficient with batched operations.

2\. HTTP/2 doesn't make latency/speed of light zero.

3\. Outside of performance, GraphQL is a type-safe, error-minimal way to
perform joins and searches.

~~~
11235813213455
What about HTTP/3 for your second point?

~~~
paulddraper
Same.

Query, Answer, Query, Answer

has twice the latency of

Query, Answer

~~~
darkcha0s
No it doesn't. It depends on how long the query<->answer time is, and if it's
the same. A complex GraphQL query may well take longer than 2 simple REST
requests

------
jwilliams
I'm a reluctant user of GraphQL. I can't specify any deep technical reasons, I
just prefer a lot more control over interfaces - particularly where I'm in
control of both the client and server.

But. I use GraphQL. GraphQL is a whole toolchain around client-server
interactions. (IMHO) It's a pain to get started using is, but then the
benefits of tooling start to compound.

HTTP2 won't replace GraphQL. Perhaps a set of libraries that use HTTP2
effectively. Even then I'd be surprised if it was a huge departure from
GraphQL fundamentals - but you never know.

------
he0001
One problem I see with Graphql, in general, that it seems like it amplifies a
problem which is something all OXMs inadvertently do. And it is the problem of
managing business logic. And from what I can see is that graphql now pushes
this to the client and erodes the server side’s encapsulation of business
logic. Now you have the problem of having business logic everywhere? Isn’t
this something we have learned throughout the years is a bad thing?

~~~
hootbootscoot
but facebook...

(your description appears accurate, and in-fact, that is precisely what this
enables, and it's symptomatic of team (human) interactions rather than
technological drivers.)

~~~
hootbootscoot
Apollo is a product of the Meteor Developer Group, if I'm not mistaken. FWIW.

------
galaxyLogic
It would seem to me as a casual observer that GraphQL is more an alternative
to SQL than it is to HTTP2. No?

~~~
whoisjuan
Yeah. The advantage of GraphQL is that you can bring the exact data you need
with a single API call instead of querying against multiple endpoints to
assemble whatever data you need.

That's completely independent of the protocol that you're using. I understand
that there's a performance consideration when you have to make fewer calls and
how HTTP2 basically can help with that. But I honestly have never thought
about GraphQL as something that would improve performance.

For me, the advantage of GraphQL is not that it reduces network roundtrips but
the fact that you can get the data you need in the exact structure you need
it.

------
fizx
AFAICT, the point of GraphQL to get an API that corresponds to your React
state tree, so that there's much less mental overhead from client developers
who don't want to deal with multiple shifting data representations.

Batching almost seems like a nice-to-have.

------
phamilton
I guess in theory we could take a gql query like:

    
    
      query {
        user {
          first_name
          last_name
        }
        settings {
          debug
          paid
        }
      }
    

could be translated into:

GET /user/first_name GET /user/last_name GET /settings/debug GET
/settings/paid

And you could represent any gql query as a multiplexed http2 call. And you
could then have the server use a persistent user scoped dataloader (or some
other shared cache) to resolve all that data and respond to each of those
queries.

That's roughly an isomorphism between graphql and http2.

~~~
sourcesmith
In reality, that would be GET /user GET settings; the cost for the unneeded
associated fields at that point of time is typically not significant for many
backends as they stored in aggregate and text based responses compress well.

If the data is not particular dynamic then you can cache the entire
representation deriving a future benefit.

Graph base queries tend to lend themselves to adhoc query patterns and I would
be concerned about unpredictable patterns of loading. If the backend store is
distributed then graph QL looks more attractive to me. If the datastore stores
related attributes in aggregate there seems to be little benefit since
different parts of an adhoc graph would different levels of 'cachability'.

I have found an application for GraphQL in storing soft-defined triggers or
other criteria on data.

------
KuhlMensch
GraphQL has a very specific cross-functional advantage: it provides a spec for
data access, to cut down novel design (of APIs) by backend and frontend.

If Backend have few data entities, or the requirements are extremely clear,
your team is not likely to get the full spectrum of benefits.

If you have a large number of existing Backend data entities, or expect a
large number to be created - GraphQL is a very handy spec. But if the
Frontend/Product are EXPLORING how use the data, and unsure exactly how to
best utilize the data types, OR they are supporting many permutations of APIs,
GraphQL is a game changer. Write a python decorator to generate resolvers...

\- and BOOM, Backend and Frontend will never have to negotiate over a rigid &
novel API contract again.

The other stuff, like introspective documentation, sophisticated Frontend
state management, and so on are great conveniences, but are not the point.

As far as HTTP2 and Frontend goes, I'm excited as it solves a fundamental
networking problem. And theoretically saves us from having to bundle. But this
is not what I personally consider a big Frontend problem.

In most large webapps with network-connected components, you don't want each
component to make a discrete network call and pump its data straight into the
component. Often you will want to use the response and update a global state,
to ensure nothing is out of date. This encourages you to colocate your network
logic, with some facilities for this. The GraphQL ecosystem ticks this box.
Additionally network requests are a complicated flow, due to APIs having
different semantics, needing to shunt value objects through promise/callback
chains and the need to covering various edge cases. This encourages
codification of network logic, which again, GraphQL does a great job of.

This is of course quite complicated stuff, and if you don't need the Frontend
magic - you can just put your GraphQL query on a fetch, and use it like a REST
endpoint.

And of course - if you don't really need the spec, I'd say think very hard
before adding GraphQL.

That said, big fan of HTTP2 (although last I looked, the perf envelope created
by plotting no. of connections against speed, the shape told me "don't rely on
this yet").

------
cgarvis
Having built a lot of react apps with and without flux/redux, I would say the
best part of GraphQL is the simplification of SPAs. Building up the query with
fragments and colocating data fetching with the component that need it, is a
huge win. If you have lots of micro services or even a few SOA apps, GraphQL
is “developer ergonomic” win.

Majority of the latency/bandwidth wins can be achieved with a well architected
jsonapi. This should not be your only reason for choosing GraphQL.

------
farcitizen
GraphQL is barely relevant today with the older HTTP standard. There is a very
limited use case for GraphQL, and you most likely don't need it. If you are
new to GraphQL I would recommended simply trying to use it to delete an item
by Id. While this is a trivial task if you were using the MongoDB with
Node/Express.. just and the GraphQL Layers.. and see all the extra code you
need..

