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

241–250 of 721 posts

Re: After 6 years, I'm over GraphQL

#241

Post by luke-stanley »

theK wrote: post #174

Fine article describing the weak points of GrahQL. I find it a bit poor though that the only recommended alternative is OpenAPI rest APIs. I have no beef against doing REST, jsonRPC etc. Actually I consistently steer people that way. But the documentation format we chose as an industry to build these things with, Swagger, is just disappointing. Some times I think the industry would be at a totally different point had…

They did address that point specifically, suggesting TypeSpec as a more concise analogue. Presumably converting between them isn't that hard. A more concise DSL could be acceptable. Presumably it can be converted automatically anyway.

Re: After 6 years, I'm over GraphQL

#242

Post by petesergeant »

What are people using these days for TypeScript on both ends? I have a home-grown solution that starts with Zod schemas and gives synchronized types on the front end and backend as well as a client for free, but I'm always interested in using something standard

Re: After 6 years, I'm over GraphQL

#243

Post by mannyv »

From a backend point of view, you will never be able to stop front end people from doing the wrong thing with an API.

GraphQL makes it easier for front-end developers to do the wrong thing, which is why they love it.

Re: After 6 years, I'm over GraphQL

#244

Post by remus »

Calamitous wrote: post #234

Fundamentally, GraphQL is a _query language_, but people keep trying to build/use it as an _API_.

The same thought struck me when reading the article. Imagine a world where your API was 'send me some SQL, return results' and you'd have the same problems as described.

Re: After 6 years, I'm over GraphQL

#245

Post by hansonkd »

WD-42 wrote: post #240
kiney wrote: post #196

Earlier quoted context omitted.

Unpopular opinion: I'm actually a fan of singe page specific endpoints. You get much easier debugging, easier to audit security, easier performance optimization an the imho pretty small price to pay is that it's "not elegant" and a bit of backend code

Yup. Especially when your api really only has 1 (possibly 2 in the case of a mobile app) real clients. People like to pretend their apis are generic but they aren’t. There’s a good argument to stop writing generic apis for your single application.

Typically the endpoints clients are multiple frontend developers. If the frontend is blocked for every page they need waiting on the backend to expose data that massively increases the costs of features and reduces the time for delivery.

Re: After 6 years, I'm over GraphQL

#246

Post by hansonkd »

datavirtue wrote: post #226
ComputerGuru wrote: post #188

Earlier quoted context omitted.

> With internal REST for companies I have seen so many single page specific endpoints. Gross. Hardly gross. It is what it is and it’s universal across the domain. I bet Windows has internal APIs or even external ones that were created just for one page/widget/dialog of one app. It’s the nature of things at times.

It's analogous to a specific method in code. No idea why people go nuts over this.

A REST endpoint can be analogous to a specific method in code. just as much as a GraphQL field.

What people are excited about is that the frontend can request all the data it needs at once and the backend can efficiently serve it. Something not possible with REST without reimplementing something similar to GraphQL.

Re: After 6 years, I'm over GraphQL

#247

Post by WD-42 »

hansonkd wrote: post #245
WD-42 wrote: post #240

Earlier quoted context omitted.

Yup. Especially when your api really only has 1 (possibly 2 in the case of a mobile app) real clients. People like to pretend their apis are generic but they aren’t. There’s a good argument to stop writing generic apis for your single application.

Typically the endpoints clients are multiple frontend developers. If the frontend is blocked for every page they need waiting on the backend to expose data that massively increases the costs of features and reduces the time for delivery.

This happens anyway.

Re: After 6 years, I'm over GraphQL

#248

Post by smaudet »

strken wrote: post #121
BiteCode_dev wrote: post #92

Earlier quoted context omitted.

The problem is you delegate a lot of the query building to the client, hoping that it will not suddenly change your performance profile by being creative and that you will have not missed an obviously expensive use case coming. That's a huge bet, especially given that GraphQL is expensive in the first place, and given that the more you grow the API in size, the less you can actually map the cartesian product of all r…

I'm not sure this is any more or less of a problem for REST APIs. What if your engineers change $client/$server and the new version makes really expensive queries? Well, ask them not to do that, then when some of them inevitably ignore you, start to review their code, terminate long-running queries, batch or pool fanouts so they don't take anything down, monitor new releases and roll back if anything breaks, etc. If…

> What if your engineers change $client/$server and the new version makes really expensive queries?

Yes, so the cost benefit here is not in favor of GraphQL. If both technologies ultimately suffer from the same issues (what to do about unpredictable clients), but one is far more complex to implement and use (GraphQL), then there's a clear winner. Spoiler, its not GraphQL.

Page specific endpoints, I would argue, can do 99% of what GraphQL was trying to do. If you want to use it as some sort of template language for constructing page specific endpoints, that could be useful (the same way xml schema is useful for specifying complex xml documents).

But you can optimize a page specific endpoint, and do it with REST-style endpoint to boot.

Having a bunch of "simple" calls and optimizing for the "complex" ones that you need using metrics/analysis is what you should be doing, not creating a complex API that is far harder to break down into "simple" cases.

Re: After 6 years, I'm over GraphQL

#249

Post by dudeinjapan »

clintonb11 wrote: post #219
jpalawaga wrote: post #153

Earlier quoted context omitted.

trying to solve org problems with tech just creates more problems, allthewhile not actually solving the original problem.

This is what I wanted to say too. If your backend team is incapable of rapidly adding new endpoints for you, they probably are going to create a crappy graphql experience and not solve those problems either. So many frontend engineers on here saying that graphql solves the problem they had with backend engineers not being responsive or slow, but that is an org problem, not a technology problem.

At TableCheck, our frontend engineers started raising backend PRs for simple API stuff. If you use a framework like Rails, once you have the initial API structure sketched out, 80% of enhancements can be done by backend novices.
Post reply on HN