Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: If GraphQL Is So Great, Why Doesn't Everyone Use It Already?

news.ycombinator.com

Post reply on HN
Print view View original

31–40 of 41 posts

Re: Ask HN: If GraphQL Is So Great, Why Doesn't Everyone Use It Already?

#31

Post by satvikpendem »

greatgib wrote: post #17

In my opinion, graphql is a good detector of companies that want to be "cool" and thinks that they do software well as they follow dogmatically things like clean code. But that are not pragmatic and so they don't realize the bad side effects of it. Often early stage startups. Graphql is a typical example of something that is nice on paper but doesn't pass the reality check.

It does, but only if you use it as intended, ie with Relay: https://alan.norbauer.com/articles/relay-style-graphql

Otherwise, yes, it's not better than REST.

Re: Ask HN: If GraphQL Is So Great, Why Doesn't Everyone Use It Already?

#32

Post by satvikpendem »

BrainInAJar wrote: post #23

GraphQL is great if you're a frontend developer. REST is great if you're a backend or infra developer (not because of complexity of developing it, because of complexity of using it) You cannot satisfy both with one tool. Migrating to GraphQL (or choosing it in the first place) will frustrate consumers of it who primarily use your API for things other than writing frontend clients. Using REST will frustrate people who…

> REST is great if you're a backend or infra developer

Not sure about that, we have a codebase that's huge, with 100s of REST endpoints, and the backend engineers simply start writing new endpoints because frontend needs one more specific field, and the backend folks can't be bothered to refactor the codebase for an endpoint that's used elsewhere, as that takes time. GraphQL solves that cleanly by allowing the frontend to request any data they want and for the backend to focus on figuring out how to give back a piece of data if it's requested. No 100s of endpoints required.

Re: Ask HN: If GraphQL Is So Great, Why Doesn't Everyone Use It Already?

#33

Post by chatmasta »

BrainInAJar wrote: post #23

GraphQL is great if you're a frontend developer. REST is great if you're a backend or infra developer (not because of complexity of developing it, because of complexity of using it) You cannot satisfy both with one tool. Migrating to GraphQL (or choosing it in the first place) will frustrate consumers of it who primarily use your API for things other than writing frontend clients. Using REST will frustrate people who…

GraphQL is great for both. It's a collaboration tool between front and backend. You can design the schema for the resolvers during the RFC phase of planning a new feature, and then both teams can implement their tasks in parallel. And you can use the spec to generate type safe libraries on each side.

We did this with Strawberry in Python for backend (which uses dataclasses for defining resolvers), and TypeScript + graphql-codegen on the frontend. We have fully automated type generation from the backend to the frontend, meaning GraphQL becomes a cross-language, shared type layer. It works great, once you get everything setup. Worth the effort IMO.

Re: Ask HN: If GraphQL Is So Great, Why Doesn't Everyone Use It Already?

#34

Post by greatgib »

precommunicator wrote: post #20
greatgib wrote: post #17

In my opinion, graphql is a good detector of companies that want to be "cool" and thinks that they do software well as they follow dogmatically things like clean code. But that are not pragmatic and so they don't realize the bad side effects of it. Often early stage startups. Graphql is a typical example of something that is nice on paper but doesn't pass the reality check.

"doesn't pass the reality check" Can you elaborate on that? We're thinking of migrating to it from plain REST.

For example, one promoted advantage of graphql is to be able to be more efficient by only requesting fields that you really need.

But the reality is that it is often more costly to parse exactly what the client want and have graphql retrieve the whole data and decimate just the needed fields. And you don't even save bandwidth because a lot of metadata had to be transferred to do that.

In a similar way, you will do one request, and the graphql server will have to trigger n requests to internal services. Then you have things like having to wait for the slower service to be able to reply and display anything to the user, also having to still send n internal requests even if one of the first and important one would fail, like retrieving an user account.

It will be harder to cache responses if the response content is specific to each request.

A lot of things like that, where, in the end, you see that it is a lot more easier and efficient to have the client do generic individual api requests.

Re: Ask HN: If GraphQL Is So Great, Why Doesn't Everyone Use It Already?

#35

Post by jelan »

logicalmonster wrote: post #27
jelan wrote: post #26

GraphQL has its place, but IMHO it is at either side of the bell curve of project complexity. It will be great for trivial projects, and it can help simplify things in really complex large projects with multiple clients and services, but it just isn’t worth it for everything in between these two extremes. Significant engineering time will need to be spent ironing out important things that just work with REST (like ca…

> GraphQL has its place, but IMHO it is at either side of the bell curve of project complexity. It will be great for trivial projects, and it can help simplify things in really complex large projects with multiple clients and services, but it just isn’t worth it for everything in between these two extremes. I understand why GraphQL might make a lot of sense at a very large scale, but how does it add anything noticeab…

I don’t think it will add anything as compared to REST for trivial projects but it’s just easy to setup and get working

Re: Ask HN: If GraphQL Is So Great, Why Doesn't Everyone Use It Already?

#36

Post by rahula13 »

mattbrewsbytes wrote: post #8

When you have performance issues with hand crafted REST API's, a GraphQL enabled set of API's feels like it could be a lot worse. Huge volumes of data for tables don't blend well with a mix-n-match way of joining things.

I am curious how do you do performant joins between different REST APIs?

Re: Ask HN: If GraphQL Is So Great, Why Doesn't Everyone Use It Already?

#37

Post by isuckatcoding »

satvikpendem wrote: post #32
BrainInAJar wrote: post #23

GraphQL is great if you're a frontend developer. REST is great if you're a backend or infra developer (not because of complexity of developing it, because of complexity of using it) You cannot satisfy both with one tool. Migrating to GraphQL (or choosing it in the first place) will frustrate consumers of it who primarily use your API for things other than writing frontend clients. Using REST will frustrate people who…

> REST is great if you're a backend or infra developer Not sure about that, we have a codebase that's huge, with 100s of REST endpoints, and the backend engineers simply start writing new endpoints because frontend needs one more specific field, and the backend folks can't be bothered to refactor the codebase for an endpoint that's used elsewhere, as that takes time. GraphQL solves that cleanly by allowing the fronte…

Not sure this always happens in practice. I’ve seen lots of redundant resolvers being implemented for the same type at work because someone didn’t know one already existed.

Re: Ask HN: If GraphQL Is So Great, Why Doesn't Everyone Use It Already?

#39

Post by meiraleal »

rahula13 wrote: post #36
mattbrewsbytes wrote: post #8

When you have performance issues with hand crafted REST API's, a GraphQL enabled set of API's feels like it could be a lot worse. Huge volumes of data for tables don't blend well with a mix-n-match way of joining things.

I am curious how do you do performant joins between different REST APIs?

How do you do it in graphql? You are going to hit multiple APIs that aren't integrated so it will be multiple requests. One request to a graphql server and multiple requests to other APIs isn't faster than doing just the requests to the different APIs. Actually it might be faster.

Re: Ask HN: If GraphQL Is So Great, Why Doesn't Everyone Use It Already?

#40

Post by mannyv »

satvikpendem wrote: post #32
BrainInAJar wrote: post #23

GraphQL is great if you're a frontend developer. REST is great if you're a backend or infra developer (not because of complexity of developing it, because of complexity of using it) You cannot satisfy both with one tool. Migrating to GraphQL (or choosing it in the first place) will frustrate consumers of it who primarily use your API for things other than writing frontend clients. Using REST will frustrate people who…

> REST is great if you're a backend or infra developer Not sure about that, we have a codebase that's huge, with 100s of REST endpoints, and the backend engineers simply start writing new endpoints because frontend needs one more specific field, and the backend folks can't be bothered to refactor the codebase for an endpoint that's used elsewhere, as that takes time. GraphQL solves that cleanly by allowing the fronte…

The only reason GraphQL is "better" is it forces documentation.

The fact is, you still need those endpoints, it's just your developers aren't afraid to change the GraphQL endpoints because they're documented. Sometime down the line your developers will become afraid to change the GQL endpoints and you'll have the same, but different, issue.

Post reply on HN