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

Re: After 6 years, I'm over GraphQL

#321

Post by randomdata » Thu, May 30, 2024, 4:03 PM UTC

hansonkd wrote: post #266

realusername wrote: post #233

Earlier quoted context omitted.

> With internal REST for companies I have seen so many single page specific endpoints. Gross. Single page endpoints is exactly what you want if you have more than 5 engineers in your company anyways. It ensures that the endpoints are maintainable and future-proof when people are working on different features.

> It ensures that the endpoints are maintainable and future-proof when people are working on different features How does GQL prohibit this? It encourages it by focusing on 1 stable API for everyone instead of a custom API endpoint for each case.

It doesn't. That's literally what GraphQL was designed for: To provide a resolver that sits between high latency clients and all of the various REST/RPC services in order to roll up all of the requests at datacenter speeds into one in order to overcome the latency issues.

But you still need all of the various single page REST/RPC endpoints to make use of GraphQL as it is intended. Some developers out there skip the REST/RPC part, making GraphQL their entire service, violating its principles.

If it works it works, but it does not come tradeoff free.

Re: After 6 years, I'm over GraphQL

#322

Post by discreteevent » Thu, May 30, 2024, 4:03 PM UTC

hansonkd wrote: post #300

RVuRnvbM2e wrote: post #292

Earlier quoted context omitted.

I've never seen this kind of graphql server implementation that can automatically boil down a complex nested query to sensible SQL. It sounds like the best of both worlds. Do you have links?

Typically libraries use a Dataloader + ORM to implement this which gets you pretty far, outside of that some libs like Strawberry with automatically optimize your queries for you if you return Django ORM Querysets. Any query you were going to build and serve with Rest can be made with these two methods or even a raw dataloader and manual SQL string.

The inventors of GraphQL did not intend it to be mapped directly to a database.

"That would be one way to implement the system in a DB-centric way. However we believe that intermediate application code is pretty critical to any GraphQL implementation." [1]

"GraphQL is a client-server dance that needs server-side capabilities, not just CRUD semantics." [2]

[1] https://news.ycombinator.com/item?id=9879870

[2] https://news.ycombinator.com/item?id=14351800

Re: After 6 years, I'm over GraphQL

#323

Post by moribvndvs » Thu, May 30, 2024, 4:04 PM UTC

chuckadams wrote: post #260

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 mi…

After building several GraphQL-based applications, the design time experience and expressivity offered to UI developers particularly when the application is first starting out feels really great. But like the author, it sours quickly after that.

I found myself spending a large amount of time inventing and trying to patch in solutions that most RPC and REST frameworks solved long ago for both the server AND the client (auth, rate limiting, error handling and validation stick out particularly). Client solutions are comparatively heavy, complicated, and riddled with gotchas (e.g. caching) that trip up new team members more than REST. It’s not impossible to build performant GraphQL solutions, but the solutions feel more like afterthoughts and require more vigilance to ensure your team doesn’t stick their finger in an electrical socket compared to REST. The lack of namespacing or organization results in almost unintelligible query and mutation documentation for large projects. The comparatively large size and complexity of requests can be a headache for ops teams. I loathe that interfaces and inheritance don’t work for mutations. Front end devs just use it like a very heavy REST and the holy grail promised by stuff like Relay never materializes. I could go on.

And at the end of the day, the app’s API usage will stabilize and mature, and the expressiveness becomes less compelling compared to its cost. When I went back to OpenAPI and REST, it was like a breath of fresh air, I felt I was building things much faster. I will grant you that generating clients from OpenAPI still is the worst part.

Re: After 6 years, I'm over GraphQL

#324

Post by hansonkd » Thu, May 30, 2024, 4:06 PM UTC

randomdata wrote: post #321

hansonkd wrote: post #266

Earlier quoted context omitted.

> It ensures that the endpoints are maintainable and future-proof when people are working on different features How does GQL prohibit this? It encourages it by focusing on 1 stable API for everyone instead of a custom API endpoint for each case.

It doesn't. That's literally what GraphQL was designed for: To provide a resolver that sits between high latency clients and all of the various REST/RPC services in order to roll up all of the requests at datacenter speeds into one in order to overcome the latency issues. But you still need all of the various single page REST/RPC endpoints to make use of GraphQL as it is intended. Some developers out there skip the R…

? why do you need a REST endpoint with GraphQL? Nearly every language has a GraphQL engine that integrated directly with the database and exposed functions as GQL directly without REST at all.

Re: After 6 years, I'm over GraphQL

#325

Post by daxfohl » Thu, May 30, 2024, 4:06 PM UTC

brabel wrote: post #82

RedShift1 wrote: post #67

Earlier quoted context omitted.

* 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 th…

About nulls: you're right, but because of authorization, everything can be null - if you don't have access to something, we need to remove it from the result (instead of just throwing an error, as you may still get enough information to do what you need to do) - and that will always be a fetcher error in GraphQL if the field was non-nullable. And because you shouldn't really know or care beforehand which fields may b…

Same thing in sql. Non null guarantees are great until you do a left join.

Re: After 6 years, I'm over GraphQL

#326

Post by BiteCode_dev » Thu, May 30, 2024, 4:06 PM UTC

hansonkd wrote: post #211

jerf wrote: post #155

Earlier quoted context omitted.

There's a lot of relevant differences between REST & GraphQL. It is possible to construct a REST endpoint that simply can't do any of those things, and such construction is a mid-level developer task at best. For instance, pagination of "all posts ever" is not uncommon, and clients won't be shocked to deal with it. GraphQL is enough harder to characterize the performance of that it definitely qualifies as a change in…

This is Wrong. GraphQL only exposes what you ask it to. There are plenty of pagination plugins for GraphQL frameworks just as there are plugins to REST framework. GraphQL can be restrictive as REST if you want it to be. The point is GraphQL can be "as restrictive" as REST, but if you want to enable more efficient queries by knowing all the data that the frontend is requesting, you can. But the opposite isn't true of…

But then what's the point of using it if it's to get the limitation of REST?

You get something more complex, more expensive to maintain, consuming more resources, and configure it to basically be REST with extra steps.

Re: After 6 years, I'm over GraphQL

#327

Post by bunderbunder » Thu, May 30, 2024, 4:08 PM UTC

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 sounds like more of an org chart problem or a value chain management problem than a technical problem.

Re: After 6 years, I'm over GraphQL

#328

Post by BiteCode_dev » Thu, May 30, 2024, 4:08 PM UTC

hansonkd wrote: post #227

clintonb11 wrote: post #214

Earlier quoted context omitted.

I think the point here is, if you have to involve a backend team to add restrictions to the graphql endpoints and try to make good educated guesses where those might be, then the idea of frontend not needing backend engineers to query whatever they need becomes less of an advantage. So is the complexity of setting up graphql and then having your backend team try and make sure no frontend engineers can do terrible que…

> if you have to involve a backend team to add restrictions to the graphql endpoints and try to make good educated guesses where those might be, then the idea of frontend not needing backend engineers No because if you dont do that you have to involve more engineers anyways to build the REST endpoints and keep modifying the rest endpoints. GraphQL is also default restrictive (i.e. exposes nothing). You don't need to…

But you actually don't need to keep modifying the REST endpoints for most projects, that's what everybody is saying.

The vast majority of projects don't gain anything from this flexibility, because you don't have suddenly a 1000 of farmvilles copy cat that need their own little queries. You just have bob that need an order by.

Re: After 6 years, I'm over GraphQL

#329

Post by realusername » Thu, May 30, 2024, 4:10 PM UTC

hansonkd wrote: post #266

realusername wrote: post #233

Earlier quoted context omitted.

> With internal REST for companies I have seen so many single page specific endpoints. Gross. Single page endpoints is exactly what you want if you have more than 5 engineers in your company anyways. It ensures that the endpoints are maintainable and future-proof when people are working on different features.

> It ensures that the endpoints are maintainable and future-proof when people are working on different features How does GQL prohibit this? It encourages it by focusing on 1 stable API for everyone instead of a custom API endpoint for each case.

I don't think it would hold true for very long, devs will have specific cases which will pile into the definitions.

That's why GraphQL examples usually focus on querying data from users and not how you are going to manage 10 different views of the same data.

Re: After 6 years, I'm over GraphQL

#330

Post by chuckadams » Thu, May 30, 2024, 4:10 PM UTC

dudeinjapan wrote: post #57

DanielHB wrote: post #47

Earlier quoted context omitted.

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…

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…

Most REST APIs I've seen in the wild just send the entire object back by default because they have no idea which fields the client needs. Most decent REST API implementations do support a field selection syntax in the query string, but it's rare that they'll generate properly typed clients for it. And of course OpenAPI has no concept of field selection, so it won't help you there either.

With my single WordPress project I found that WP GraphQL ran circles around the built-in WP REST API because it didn't try to pull in the dozens of extra custom fields that I didn't need. Not like it's hard to outdo anything built-in to WP tho...