After 6 years, I'm over GraphQL • Hacker News Board

Re: After 6 years, I'm over GraphQL

#251

Post by dudeinjapan » Thu, May 30, 2024, 3:08 PM UTC

fire_lake wrote: post #159

dudeinjapan wrote: post #57

Earlier quoted context omitted.

Couldn't disagree more. GraphQL encourages tight-coupling--the Frontend is allowed to send any possible query to the Backend, and the Backend needs to accommodate all possible permutations indefinitely and with good performance. This leads to far more fingerpointing/inefficiency in the log run, despite whatever illusion of short-term expediency it creates. It is far better for the Backend to provide Frontend a contra…

A GraphQL schema is a contract though. And the REST API can still get hammered by the client - they could do an N + 1 query on their side. With GraphQL at least you can optimize this without adding a new endpoint.

Yes, GraphQL is a "contract" in the sense that a blank check is also a "contract".

Re: After 6 years, I'm over GraphQL

#252

Post by RVuRnvbM2e » Thu, May 30, 2024, 3:08 PM UTC

hansonkd wrote: post #197

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.

Its gross because it is a waste. An engineer had to spend time to make that specific API for that page instead of the frontend consumer using what was already defined and get all the resources with one call and 0 backend engineer needed for that new page.

That backend engineer wrote a single SQL query that joined some tables, ensured indices were used, and always executed in In graphql land you'd be doing multiple SQL queries, "joining" in the API layer, and spending 50ms per API call.

Re: After 6 years, I'm over GraphQL

#253

Post by welder » Thu, May 30, 2024, 3:09 PM UTC

k__ wrote: post #16

A few weeks ago, I read that tRPC is an interesting alternative.

I've been using tRPC for 6+ months on a large web and mobile project with great results. The only downside is you're restricted to using TypeScript on both frontend and backend, but I was already going to do that anyway.

Another library to check out: Drizzle-ORM

Re: After 6 years, I'm over GraphQL

#254

Post by hansonkd » Thu, May 30, 2024, 3:11 PM UTC

WD-42 wrote: post #247

hansonkd wrote: post #245

Earlier quoted context omitted.

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.

Not nearly as often with Graphql and happens less and less as your backend and data models stabilizes.

Most of our frontend features now don't have backend changes and we were able to increase the ratio of frontend to backend devs.

Re: After 6 years, I'm over GraphQL

#255

Post by wruza » Thu, May 30, 2024, 3:11 PM UTC

chasd00 wrote: post #151

RedShift1 wrote: post #81

Earlier quoted context omitted.

Why is this a problem? If you add fields on a REST endpoint, you're going to have to change the client too to deal with those new fields.

If new fields show up in a json response just ignore them. Why would you need to change the client if new fields show up in the response?

Because receiving unexpected data is a signal you rarely want to ignore in programming. Doesn’t matter whether you’re gonna use it or not.

Re: After 6 years, I'm over GraphQL

#256

Post by aobdev » Thu, May 30, 2024, 3:12 PM UTC

foobarian wrote: post #189

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…

> IMO GraphQL is a technological dead end in much the same way as Mongo is. Can you suggest alternatives to graph introspection and related UI tools like GraphiQL, and the subgraph federation systems?

OpenAPI has a handful of open source API explorers. The ones I’m familiar with are Swagger UI, Redoc, and RapiDoc.

OpenAPI 3.0 has this concept of remote references, which can be URLs to other OpenAPI specs hosted anywhere. https://swagger.io/docs/specification/using-ref/

Re: After 6 years, I'm over GraphQL

#257

Post by adeptima » Thu, May 30, 2024, 3:12 PM UTC

Back in 2021, I asked one of our devs who badly wanted GraphQL for his resume (this dev left in 6 months) to address the following issues:

- GraphQL performance issues

- GraphQL makes tasks more complex

- GraphQL schemas confuse junior devs, higher entry level

- REST cache easier

- REST if you understand what you are doing ... can do the same

- REST is better for error handling and tooling

Now in 2024, I clearly see LLMs gives much better autocomplete for REST or SDK code generated with protobuf ecosystem

There is not enough code repos based on GraphQL for LLMs to reason.

If you have like minded people who loves GraphQL, nothing can stop them but at higher and broader level it's a huge risk for dev velocity (like anything else if you dont know what you are doing)

Re: After 6 years, I'm over GraphQL

#258

Post by mjburgess » Thu, May 30, 2024, 3:13 PM UTC

mgkimsal wrote: post #237

datavirtue wrote: post #224

Earlier quoted context omitted.

Agreed. Specific endpoints. I was on a project recently where a 40+ yr old dev was going crazy over "pure REST." It's embarrassing. Sure, have your pure REST but FFS create specific endpoints if you they make sense.

You are literally Transferring the REpresented State of a given page/view/screen. Screen-specific REST endpoints will make their way as a default in to a JS-based framework in 2025 and people will pretend like this is some breakthrough advancement.

And finally HyperText will progress into the futuristic HyperCard

Re: After 6 years, I'm over GraphQL

#259

Post by amjnsx » Thu, May 30, 2024, 3:13 PM UTC

0-bad-secrotrs wrote: post #64

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.

Sounds like an issue with your team rather than graphql

Re: After 6 years, I'm over GraphQL

#260

Post by chuckadams » Thu, May 30, 2024, 3:14 PM UTC

I must be the only one who found GraphQL, used it in a small project, and liked almost every bit of it. I used Apollo Client and graphql-codegen to generate types and functions for Vue 3, and nothing else could touch it. It wasn't all smooth sailing of course: I did find defining new scalar types to be fiddly, and I couldn't really even make proper use of union types, directives, or even enums due to the impedance mismatch of Apollo Client (JS) and API Platform (PHP). The latter had a lot of nice features in implementing the API backend itself, but the poor documentation for its graphql support held me back. But even the super-basic graphql subset I did use caught a great many errors at the type level where other solutions would not have.

These days, given the freedom to write the backend in TS too, I might look into tRPC instead. One thing's for sure, I won't be going back to OpenAPI unless and until I can fully autogenerate api.yaml and otherwise never have to touch it again (getting there with zod+openapi on another project, but it's nowhere near as easy as graphql-codegen doing all the things with one introspection query).