
Ask HN: Is GraphQL still relevant? - rapphil
 - Is it still relevant?<p>- How is the adoption of GraphQL compared to REST APIs?<p>- What popular services are providing a GraphQL endpoint?<p>- When would you use It aside from the cases you want to optimize the access to your service (mobile)?<p>- Are you using in your projects? What work, and what doesn&#x27;t work?
======
xrd
I personally think it is amazing and relevant.

These two videos are worth watching for the reasons: in short, it's a great
way to aggregate legacy backend services. And, your client data shapes are
much better, and this makes a difference when optimizing your server side
(without knowing how your clients use the data, you can't really optimize,
which REST doesn't tell you).

[https://www.youtube.com/watch?v=H8YnVk2vhzg](https://www.youtube.com/watch?v=H8YnVk2vhzg)

[https://www.youtube.com/watch?v=zVNrqo9XGOs](https://www.youtube.com/watch?v=zVNrqo9XGOs)

But, the reality is that even the biggest providers of public APIs, GitHub
being the biggest example, have major holes in their offerings. For example,
you can't yet make commit mutations in their API, which means you can't edit
git data using their graphql API, though you can edit GitHub data... (My
O'Reilly book is still relevant for this reason:
[https://buildingtoolswithgithub.teddyhyde.io/](https://buildingtoolswithgithub.teddyhyde.io/))

Graphql is not always the best fit, but it is really a powerful idea.

In the same way that people suggest you learn a new language each year even if
you don't necessarily switch to using it full time, learning graphql will make
you really think through how you access APIs.

------
rwieruch
1) I think GraphQL is more relevant than ever. Facebook ran into the same
problems like Netflix, Airbnb and Twitter and thus came up with GraphQL [0].

2) The most popular one I know is GitHub's GraphQL API [1]. I made the
difficult decision to rely on their API to teach GraphQL in my free book [2].
So far, there were no breaking changes for me and people love it to learn
GraphQL from a client's perspective.

3)I would use it if I want to have no under-/overfetching, declarative data
fetching, microservice API aggregation, ... [3]

4) Using it in personal projects and one client of mine is using it in one
application to aggregate multiple microservices (each one speaking GraphQL)
into one GraphQL API gateway. So far, everything works like expected. We
didn't hit any rate limiting and caching issues because of the N+1 problem
yet. But we are prepared for them :)

[0]
[https://www.youtube.com/watch?v=783ccP__No8](https://www.youtube.com/watch?v=783ccP__No8)

[1] [https://developer.github.com/v4/](https://developer.github.com/v4/)

[2] [https://www.robinwieruch.de/the-road-to-graphql-
book/](https://www.robinwieruch.de/the-road-to-graphql-book/)

[3] [https://www.robinwieruch.de/why-graphql-advantages-
disadvant...](https://www.robinwieruch.de/why-graphql-advantages-
disadvantages-alternatives/)

------
truth_seeker
We tried to migrate an old gigantic legacy software from REST to GraphQL and
left it in midway. We were just not convinced by the effort which goes into
creating and maintaining the GraphQL layer.

We went ahead with JSON RPC

[https://www.jsonrpc.org/specification](https://www.jsonrpc.org/specification)

JSON/RPC is much simpler to implement and consume. You just have to expose
server-side functions as endpoints and when it comes to build authentication
and Authorization you can build using (Python or Typescript like) Decorator or
just a Higher Order Functions which wraps the functions to be exposed to
control the input and output in aspected oriented way.

------
gtirloni
If you search for "graphql whitepaper", you may find some useful material
about that.

[https://www.google.com/search?q=graphql+whitepaper](https://www.google.com/search?q=graphql+whitepaper)

~~~
yen223
Funnily enough, this comment thread is the third result I get.

~~~
gtirloni
That's indeed funny. I hope it makes to the top :-)

------
codegladiator
To me "migrating from rest to graphql" feels like the new "migrating from
monolith to microservices". Everyone is being told to get to graphql because
of some benefits they might never need.

------
sergiotapia
We're using GraphQL at Papa. Elixir postgres, absinthe exposing graphql and
queries.

It's great for our frontend team, makes things simpler for them. Mobile also
benefits from less queries. Also it's great for aggregating data from multiple
sources.

It does come with more plumbing, but you get better and better at it with
muscle memory. If you're a tiny team, I wouldn't use it.

Learn about it here: [https://pragmaticstudio.com/courses/unpacked-full-stack-
grap...](https://pragmaticstudio.com/courses/unpacked-full-stack-graphql-with-
absinthe-phoenix-react)

------
therealtbs
I have been using GraphQL professionally as a frontend developer for about 1.5
years and I think it is definitely getting more relevant now.

I can't speak for many services that use GraphQL since we always have our own
backend that we use. But I can speak a bit from my experiences using it with a
number of different backends.

So first up: The number one thing GraphQL does really well is the tooling. You
can have anywhere from a full-featured client for your SPA with Apollo [0] to
a simple client for just one-off requests like urql[1]. You can have your
schema be automatically turned into type definitions for TypeScript so
everything is strictly typed from the backend to the frontend. Do you want to
adopt microservices? You can offer your frontend-devs a single GraphQL-
endpoint with schema stitching or Apollo Federation[2].

Also great is the ability to compose queries how you see fit. Need a sub-sub-
sub entity of whatever you're querying? If the schema is properly set up, that
is easily done in one request, while with REST you are potentially looking at
up to 4 requests that need to be made. So from a UX-perspective it is also
quite nice because there may be lower latency.

Since GraphQL is different from REST, it does require a different way of
thinking by the backend developer. I've worked on one project where the
developers weren't quite thinking in GraphQL, so they had fields that referred
to objects by their ID instead of referring to it directly. That coupled with
not having a unified schema in a microservices environment meant, that the end
result wasn't much better than just using a REST API.

So I would recommend GraphQL for projects where, like the name suggests, you
have a complex graph of objects or entities you need to regularly traverse. I
wouldn't use it for things where in most cases a single REST-Request is all
that's needed.

\- [0]
[https://www.apollographql.com/docs/react/](https://www.apollographql.com/docs/react/)
\- [1]
[https://github.com/FormidableLabs/urql](https://github.com/FormidableLabs/urql)
\- [2] [https://blog.apollographql.com/apollo-
federation-f260cf525d2...](https://blog.apollographql.com/apollo-
federation-f260cf525d21)

------
birdiesanders
I would go so far as to say it is just now getting truly relevant.

------
tuesdayrain
I recently started using GraphQL/Apollo and so far it feels more "proper" than
REST. I particularly enjoy how it handles queries, subscriptions, and the API
explorer. It seems like the patterns it encourages could lead to some
standardization in areas where developers previously had little guidance.

------
ruairidhwm
I'm using it at work to develop an API and I'd say that it's been a great
experience. I find that it fits well with our use case.

I find it works well for when we need to collect information from several
places at once which in our older API required several requests to REST
endpoints. Now we have a single request and a much faster response time.

~~~
ScottFree
> I find that it fits well with our use case.

What's your use case? Also, how difficult is it to create and maintain the
API? I hear nothing but good things about it from the frontend people, but
some of the backend people I've asked about it just mutter to themselves about
increased complexity then run away. Which also makes me think I need to become
friends with backend people who don't mutter to themselves, but one thing at a
time.

~~~
ruairidhwm
A platform which handles listings and bookings. I work primarily on the
backend and haven't really felt any discomfort in terms of complexity. It just
gives a lot of flexibility in how we work with the data that we have and what
we can offer to the frontend.

The stack is GraphQL Yoga and Prisma which simplifies things quite a bit!

------
genbit
a lot of job descriptions I see these days say "migrating REST to GraphQL"

