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

After 6 years, I'm over GraphQL

bessey.dev

Post reply on HN
Print view View original

61–70 of 721 posts

Re: After 6 years, I'm over GraphQL

#61

Post by afiori »

DanielHB wrote: post #47
atsjie wrote: post #24

Worked on two GraphQL projects; I was quickly cured from the hype. I recognize a lot of points in this article. In both these projects the GraphQL had started small. I came in during a more mature phase of these projects (2 and 4 years). That's where the requirements are harder, more specific, and overall complexity has grown. Adoption and demand on the API were growing quickly. Hence you logically spend more time de…

GraphQL is very good for places where frontend and backend developers are isolated from each other (separate teams). Or rather places where you have data-producers and data-consumers as separate teams. If you have a big enough org eventually there will be many of such teams, interdisciplinary teams are not feasible at scale for everything. It allows teams to work with less communication overhead. It solves more of a…

> In some ways yes, in others no. For example it can be near impossible to see if a deprecated field in a REST API is still being used and by which clients it is being used. With GraphQL this is fairly simple.

You should log deprecation warnings.

But also if the client is composing urls/params manually then you are not doing REST, you are doing RPC.

Rest APIs should mainly use HATEOAS hyperlinks to obtain a resource. that is clients almost always call links you have provided in other reponses (starting from a main entrypoint)

Re: After 6 years, I'm over GraphQL

#62

Post by tarkin2 »

I heard the argument that it's good because you don't need the server devs to change the backend; you can specify the data you want. As echo'd before, I guess that's great if your frontend and backend can't be developed in sync. Overall, I'd rather improve the development synchronisation/modification problem between backend and frontend than drive the GraphQL tank through the codebase. I guess I'll need to wait another 6 years before I can avoid GraphQL. Marketing-driven fads: exciting at the start of my career, a painful chore now

Re: After 6 years, I'm over GraphQL

#63

Post by eterps » 

    > Data fetching and the N+1 problem
    > [...] if a field resolver hits an external data source such as a DB or HTTP API, and
    > it is nested in a list containing N items, it will do those calls N times
Why is this considered a problem regardless of the situation at hand?

F.e. using REST, if the nested list contains on average N-2 items that can be efficiently cached, wouldn't that be better than having the cache constantly invalidated on the aggregation of the parent and its items?

Re: After 6 years, I'm over GraphQL

#64

Post by 0-bad-secrotrs »

Aside from all the valid points listed in the blog I found out that the frontend engineers in my company save some queries in central library and reuse them even if they don't need all the field returned by this array just to save themselves the time they spend writing queries so they are basically using GraphQL as REST at the end and now we have the worst of both worlds.

Re: After 6 years, I'm over GraphQL

#65

Post by CuriouslyC »

lpapez wrote: post #25

Kudos to the author for reevaluating his opinion and changing heart on a technology he admits to have championed before. IMO GraphQL is a technological dead end in much the same way as Mongo is. They were both conceived to solve a perceived problem with tools widely adopted at the time, but ended up with something which is even worse, while the tools they were trying to replace rapidly matured and improved. Today Ope…

GraphQL by itself has a lot of issues, but Hasura is IMO a power tool. It gives you CRUD with a security model and a lot of bells and whistles out of the box, and paired with Apollo client on the front end it's pretty quick to set up and use. I still use random REST endpoints, and I'm not interested in federation, but as a quick way to get an app going it's great.

Re: After 6 years, I'm over GraphQL

#67

Post by RedShift1 »

jvans wrote: post #50

Additional graph pain points I'd add: Reliability: * Not null fields in a distributed system are a lie. Clients write code assuming something is not null, so a query that fetches data from N sub systems breaks the entire page when one of them fails. Performance: * People say you only need to fetch just what the page wants but in practice clients create re-usable fragments for every object in the system and use it eve…

* Not null fields in a distributed system are a lie

If something is null that's not supposed to be null, then the entire operation should be called into question. It's probably not safe to proceed so it's a good thing he entire page breaks, you don't want users to continue based on wrong information. If you define something in the schema that it's possible that it's null, but then the frontend dev ignores the fact that it can be null, why is it GraphQL's fault then that the page breaks?

* clients create re-usable fragments for every object

As a frontend developer I don't know why you would do that, but if your frontend devs are doing that then yes they are doing it wrong... However switching to REST with statically defined endpoints doesn't solve the over/underfetching problem, but as backend developer you do get to gatekeep that aspect. So yeah the devs should really be just doing it right.

Re: After 6 years, I'm over GraphQL

#68

Post by jakubmazanec »

For web apps (not simple pages), developed by a single full-stack developer, I think the best solution currently is to use Remix's loaders + actions (i.e. no need to create separate API layer) with EdgeDB (EdgeQL is like GraphQL but with capabilities of SQL, and the DB itself has authn+authz baked-in).

Re: After 6 years, I'm over GraphQL

#69

Post by dgb23 »

One of the major issues I have with GraphQL from the get go is that it introduces it's own syntax instead of using a commonly understood and established _data_ format like JSON or similar.

Same problem with Prisma Model definitions and other such things.

Please, if you make a new thing and it fits neatly into a data format, use a data format! Let me use all of those well established libraries, schema definitions and programming concepts in order to generate, parse and make sense of your thing. Let me seamlessly write your language with the data structures I already know in my language if that's possible.

Don't make it pretty, make it usable.

Re: After 6 years, I'm over GraphQL

#70

Post by vinnymac »

I still enjoy using GraphQL, because it has allowed my teams to move measurably faster when developing APIs over the last half-decade. Some organizations seem fairly allergic to full stack development, but it has broken that barrier in ways I hadn’t witnessed before at my workplace.

However, lately I’ve been thinking that with the advent of React Server Components we will see a migration away from GraphQL-focused Frontend applications, and instead move toward other solutions. Such as ones based purely on exposing Postgres databases (e.g. supabase & postgREST) and type safe APIs (e.g. tRPC).

Post reply on HN