Ask HN: Does Anyone Like GraphQL?

#1

Post by langsa » Tue, Jun 06, 2023, 8:51 PM UTC

I personally think that GraphQL is one of those technologies that has a wide gap in how useful it actually is. For smaller projects it's easy to setup, write out your schema, and get going. Likewise, for much larger more complex projects some of the benefits you can get out of GraphQL can warrant the use of it. But there is a massive gap in the middle where it just seems unnecessary.

98% of the literature I have seen about GraphQL has always been positive, and it seems to have become the standard recommendation for anything from starting a small web app as a side project, to running a fortune 500 company. I'm fairly sure that this is because a lot of larger tech companies use GraphQL in some way, so there is this misconception that using it must be the correct choice for all use cases, but who knows.

I have worked with GraphQL in a few different companies now, and in all except the largest company where there was a dedicated team of engineers that worked on the GraphQL implementation for the company, I have felt strongly that we would have been better off with a more boring approach like REST.

I am curious to hear others perspectives on this, do you like using GraphQL? do you disagree with me and think that it is actually a good solution for the "middle ground" of use cases?

Also, I do think that GraphQL has some cool features and I'm not trying to write it off as a useless tool with no benefits. Like all tools, it has it's place but I think that where it's really helpful is not where people end up using it in the vast majority of use cases.

Re: Ask HN: Does Anyone Like GraphQL?

#2

Post by rvcdbn » Tue, Jun 06, 2023, 8:55 PM UTC

I think you have to ask yourself "compared to what?".

Compared to REST, I would argue auto-generated GraphQL clients are superior (compared to auto-generated REST clients based on something like OpenAPI).

Compared to gRPC, I think it has the advantage that it's much easier to use in the browser and many people seem to prefer text-based protocols for debugability.

What are you comparing it to?

Re: Ask HN: Does Anyone Like GraphQL?

#3

Post by langsa » Tue, Jun 06, 2023, 9:07 PM UTC

rvcdbn wrote: post #2

I think you have to ask yourself "compared to what?". Compared to REST, I would argue auto-generated GraphQL clients are superior (compared to auto-generated REST clients based on something like OpenAPI). Compared to gRPC, I think it has the advantage that it's much easier to use in the browser and many people seem to prefer text-based protocols for debugability. What are you comparing it to?

Mostly comparing it to REST. The main turn off for me personally is it really seems like you have to reinvent the wheel to get caching to work correctly with GraphQL for non trivial use cases. Not saying that it works perfectly out of the box if you choose REST instead, but you can get pretty far without needing to optimize anything.

Why do you prefer auto-generated GraphQL clients?

Re: Ask HN: Does Anyone Like GraphQL?

#4

Post by sbegaudeau » Tue, Jun 06, 2023, 9:15 PM UTC

In my company, we are building a set of monolith applications based on frontend and backend modules that we can compose (Spring jars and React npm packages). As the maintainer of several of those modules, I don't know how my modules will be integrated in each monolith and I don't know exactly how all the complete frontend of each monolith will interact with each API.

Having the ability to define small schemas for each module gives us a great way to communicate the contract provided by a backend module and the parts of the API required by its associated frontend module.

It can be extended very easily and it gives each monolith the ability to ask for anything they want. On top of that we are using a ton of subscriptions so having the ability to use a common language even for the websocket parts is great.

So in the end, the ability to request anything from the API, the simplicity to extend and compose APIs and the support for subscriptions are features that we would have needed in REST which are "included" in GraphQL.

Re: Ask HN: Does Anyone Like GraphQL?

#5

Post by sergiotapia » Tue, Jun 06, 2023, 9:28 PM UTC

Used it in multiple companies, never said "Wow this is great!" - always said "fuck this would be 10x simpler in REST".

The only benefit I have personally experienced is that since we have mobile apps more often than not with Apollo, having the graphql for both mobile _and_ web react is nice.

But with Phoenix Liveview that benefit quickly erodes for me. I say good riddance.

Re: Ask HN: Does Anyone Like GraphQL?

#6

Post by chrisquinnr » Tue, Jun 06, 2023, 9:31 PM UTC

>I have felt strongly that we would have been better off with a more boring approach like REST

What led you to this feeling? I know you want to hear from people on why GraphQL is good, but why would REST have been a better choice in that situation? I'm interested as someone who works with both day to day.

Re: Ask HN: Does Anyone Like GraphQL?

#7

Post by ruler88 » Tue, Jun 06, 2023, 9:33 PM UTC

langsa wrote: post #3

rvcdbn wrote: post #2

I think you have to ask yourself "compared to what?". Compared to REST, I would argue auto-generated GraphQL clients are superior (compared to auto-generated REST clients based on something like OpenAPI). Compared to gRPC, I think it has the advantage that it's much easier to use in the browser and many people seem to prefer text-based protocols for debugability. What are you comparing it to?

Mostly comparing it to REST. The main turn off for me personally is it really seems like you have to reinvent the wheel to get caching to work correctly with GraphQL for non trivial use cases. Not saying that it works perfectly out of the box if you choose REST instead, but you can get pretty far without needing to optimize anything. Why do you prefer auto-generated GraphQL clients?

auto-generated GraphQL clients works really well if you have a larger codebase and large team. You can think of it as a forced high quality documentation.

If you are working in a small project with just a few engs. The additional lift for GraphQL might not be worth it. Especially if the team is not already well versed.

Re: Ask HN: Does Anyone Like GraphQL?

#8

Post by gumballindie » Tue, Jun 06, 2023, 9:39 PM UTC

I like it because it can inflate my invoices. It makes projects last longer but at least i amuse myself when people write gql injections without knowing what they are. But otherwise i find it like yet another fashion tool, a symptom of engineering for the sake of engineering.

Re: Ask HN: Does Anyone Like GraphQL?

#9

Post by ipaddr » Tue, Jun 06, 2023, 9:41 PM UTC

chrisquinnr wrote: post #6

>I have felt strongly that we would have been better off with a more boring approach like REST What led you to this feeling? I know you want to hear from people on why GraphQL is good, but why would REST have been a better choice in that situation? I'm interested as someone who works with both day to day.

The tone from the author is less complexity. It's a backend vs frontend debate. GraphQL can be magic from the client side but on the server side you have tons of boilerplate weighing you down.

Re: Ask HN: Does Anyone Like GraphQL?

#10

Post by langsa » Tue, Jun 06, 2023, 9:53 PM UTC

chrisquinnr wrote: post #6

>I have felt strongly that we would have been better off with a more boring approach like REST What led you to this feeling? I know you want to hear from people on why GraphQL is good, but why would REST have been a better choice in that situation? I'm interested as someone who works with both day to day.

Thanks for your reply, I would love to hear more about which one you prefer in general REST or GraphQL, or if you have different situations where you choose one or the other and why.

Here were some of the things I noticed when comparing to REST:

  - Caching can become a nightmare and requires a lot of effort to get working correctly for non trivial use 
    cases / you cannot really use the already "built in" cache control headers in the browser with GraphQL

  - Another caching one, but you almost are required to have some kind of server side cache in addition to 
    the client side cache, it can quickly become disorienting trying to figure out exactly where something 
    is cached and why, or why you are getting stale data, etc...

  - Some abstractions in GraphQL can make the code hard to follow / read in my opinion (data loaders for 
    example) and also make it hard to follow where the data is actually coming from especially in federated 
    subgraphs

  - Error handling in GraphQL can be really unintuitive and more work is needed to not have the error 
    response come back as a 200 status code (or handle it correctly if it is an error inside of a 200)