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

Re: After 6 years, I'm over GraphQL

#441

Post by eddd-ddde » Thu, May 30, 2024, 6:07 PM UTC

kiney wrote: post #196

hansonkd wrote: post #177

Earlier quoted context omitted.

REST APIS suck for nested resources. GraphQL is a huge breakthrough in managing them. Ever seen an engineer do a loop and make n+1 REST calls for resources? It happens more often then you think because they don't want to have to create a backend ticket to add related resources to a call. With internal REST for companies I have seen so many single page specific endpoints. Gross. > There have been different opinions ab…

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

This is the true purpose of REST. If you need to make multiple requests for a single operation you don't have enough endpoints.

The idea that resources and the underlying data needs to map 1-1 is wrong.

Re: After 6 years, I'm over GraphQL

#442

Post by jack_riminton » Thu, May 30, 2024, 6:08 PM UTC

riffraff wrote: post #379

klibertp wrote: post #367

Earlier quoted context omitted.

> idea that a frontend developer would send a ticket to somebody so they can get all the data they need... it's just crazy. For me, what's crazy is that there are "web" developers who can't just add the endpoint they need while working on a frontend feature, or "web" developers who can't just add an element or a page for testing the backend endpoint. What ever happened to full-stack developers? The "frontend" and "ba…

Because people have a limited appetite for complexity. I wrote some front-end stuff back in the days but I've lost track of whatever is happening these days. jQuery to append some stuff took five minutes to learn, but learning react hooks takes a determined effort. Likewise, adding a field to a graphql type is simple, but doing it with authorization, controlling n+1s, adding tests etc.. requires front-end folks to ac…

This is why the Rails community should be applauded in my book, for their dogged determination that we should keep it a “one person” framework. Yes it may not be as performant, type safe or flashy on the front end but my god it’s productive.

At my startup there are 7 devs who can all do tickets across the stack and as we grow I think it would be good if we could resist the pressure to silo and specialize

Re: After 6 years, I'm over GraphQL

#443

Post by ttfkam » Thu, May 30, 2024, 6:10 PM UTC

The only time I think GraphQL works is when it is when the GraphQL schema and resolvers are autogenerated by the underlying data stores. As a ORM layer, I love solutions like Postgraphile and Hasura where they mostly just reflect the structures you've already designed in your database. I also like REST solutions like PostgREST for the same reasons.

Then I'm designing my table structure, optionally designing my views when I don't want a 1:1 reflection of how data is stored, setting up row-level security at the data layer, and making user-defined functions for the one-offs that deviate from plain CRUD.

But solutions like Spring DGS for Java, Graphene for Python, and Apollo for Node? No thanks. Never again. Way too much trouble and pain. I'd rather make lambdas that talk to the data store directly and output HTML than make and maintain a GraphQL schema manually again.

I really wish Postgraphile and Hasura were more popular, so folks could have skipped the low level plumbing and optimization fences like dataloaders that make GraphQL such a chore otherwise.

It really is elegant when you're not stuck in a swamp.

Re: After 6 years, I'm over GraphQL

#444

Post by shepherdjerred » Thu, May 30, 2024, 6:12 PM UTC

romanhotsiy wrote: post #137

travellingprog wrote: post #128

Earlier quoted context omitted.

TanStack Query (fka React Query) is a REST client similar to Apollo Client, with many of the same pros and cons: https://tanstack.com/query/latest/docs/framework/react/overv...

We use https://tanstack.com/query/v3 + openapi-based auto-generated SDK. I would say the DX is pretty much comparable to using Apollo Client.

What do you use to generate your SDK?

Re: After 6 years, I'm over GraphQL

#445

Post by defen » Thu, May 30, 2024, 6:13 PM UTC

klibertp wrote: post #367

marcosdumay wrote: post #318

Earlier quoted context omitted.

The modern web development practices are just insane. The GP's idea that a frontend developer would send a ticket to somebody so they can get all the data they need... it's just crazy. On the other extreme, we have the HTTP 1.0 developers saying something like "networks are plenty of fast, we can waste a bit of it with legible protocols that are easier to make correct", while the HTTP 2.0 ones are all in "we must cra…

> idea that a frontend developer would send a ticket to somebody so they can get all the data they need... it's just crazy. For me, what's crazy is that there are "web" developers who can't just add the endpoint they need while working on a frontend feature, or "web" developers who can't just add an element or a page for testing the backend endpoint. What ever happened to full-stack developers? The "frontend" and "ba…

Many organizations would rather pay 3 people $120,000 each instead of paying 1 person $300,000 to do the same work, for a variety of reasons. Some good, some bad.

Re: After 6 years, I'm over GraphQL

#446

Post by damidekronik » Thu, May 30, 2024, 6:15 PM UTC

ttfkam wrote: post #443

The only time I think GraphQL works is when it is when the GraphQL schema and resolvers are autogenerated by the underlying data stores. As a ORM layer, I love solutions like Postgraphile and Hasura where they mostly just reflect the structures you've already designed in your database. I also like REST solutions like PostgREST for the same reasons. Then I'm designing my table structure, optionally designing my views…

Postgraphile is great, until you need to debug row level security. Or when you realize you need another tool to make the query type safe.

Re: After 6 years, I'm over GraphQL

#447

Post by evantbyrne » Thu, May 30, 2024, 6:18 PM UTC

klibertp wrote: post #367

marcosdumay wrote: post #318

Earlier quoted context omitted.

The modern web development practices are just insane. The GP's idea that a frontend developer would send a ticket to somebody so they can get all the data they need... it's just crazy. On the other extreme, we have the HTTP 1.0 developers saying something like "networks are plenty of fast, we can waste a bit of it with legible protocols that are easier to make correct", while the HTTP 2.0 ones are all in "we must cra…

> idea that a frontend developer would send a ticket to somebody so they can get all the data they need... it's just crazy. For me, what's crazy is that there are "web" developers who can't just add the endpoint they need while working on a frontend feature, or "web" developers who can't just add an element or a page for testing the backend endpoint. What ever happened to full-stack developers? The "frontend" and "ba…

Microservice architectures and the associated explosion in complexity on both ends are to blame. When it takes twice the time to build something, it is natural to hire twice as many developers. Increased complexity drives specialization.

Re: After 6 years, I'm over GraphQL

#448

Post by int_19h » Thu, May 30, 2024, 6:20 PM UTC

hansonkd wrote: post #355

randomdata wrote: post #341

Earlier quoted context omitted.

You don't, obviously – we already talked about how many don't. But if you don't have a graph of "microservices" in which to query, what do you need GraphQL for? Especially if all you are doing is returning the results from a database. The database will already have its own API. Why not just use it? The native API is always going be better than your attempt to translate.

Because exposing your Database to the outside world is asinine. GQL sits between letting the frontend query semi-customizable queries and not having any customizability to select related resources.

I'm curious as to why you believe that exposing direct SQL over the database is "asinine" but GQL is fine, given that either one is very generic, and e.g. the security issues are very similar (as the article points out).

Re: After 6 years, I'm over GraphQL

#449

Post by culi » Thu, May 30, 2024, 6:20 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.

This isn't actually that terrible since these fields are cached by a client-side library like Apollo. If the query has already been made elsewhere then it won't be doing any extra work

The only downside is if one of those unused fields changes due to a mutation then all components using that field will rerender (ofc I'm assuming React here). Again, not the biggest concern if you've got your memoization set up correctly

Re: After 6 years, I'm over GraphQL

#450

Post by ttfkam » Thu, May 30, 2024, 6:21 PM UTC

foobarian wrote: post #183

jerf wrote: post #161

Earlier quoted context omitted.

My blocker on ever using GraphQL is generally if you've got enough data to need GraphQL you're hitting a database of some kind... and I do not generally hand direct query access to any client, not even other projects within the same organization, because I've spent far too much time in my life debugging slow queries. If even the author of a system can be surprised by missing indices and other things that cause slow q…

It seems there is a recent trend of using adapters that expose data stores over graphql automatically, which is kind of scary. The graphql usage I'm used to works more or less the same as REST. You control the schema and the implementation, you control exactly how much data store access is allowed, etc. It's just like REST except the schema syntax is different. The main advantage of GraphQL IMO is the nice introspect…

Not particularly scary. For something like Hasura, resolvers are opt-in, not opt-out. So that should alleviate some of your concerns off the bat.

For Postgraphile, it leans more heavily on the database, which I prefer. Set up some row-level access policies along with table-level grant/revoke, and security tends to bubble up. There's no getting past a UI or middleware bug to get the data when the database itself is denying access to records. Pretty simple to unit test, and much more resistant to data leakage when the one-off automation script doesn't know the rules.

I also love that the table and column comments bubble up automatically as GraphiQL resolver documentation.

Agreed about the introspection tools. I can send a GraphiQL URL to most junior devs with little to no SQL experience, and they'll get data to their UI with less drama than with Swagger interfaces IMO. (Though Swagger tends to be pretty easy too compared to the bad old days.)