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

261–270 of 721 posts

Re: After 6 years, I'm over GraphQL

#261

Post by smaudet »

jpalawaga wrote: post #153
DanielHB wrote: post #116

Earlier quoted context omitted.

> It is far better for the Backend to provide Frontend a contract It sure is better for the backend team, but the client teams will need to have countless meetings begging to establish/change a contract and always being told it will come in the next sprint (or the one after, or in Q3). > This leads to far more fingerpointing/inefficiency in the log run, despite whatever illusion of short-term expediency it creates. I…

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

Yup. And the solution to that org problem is for the front engineers to slow down, and help out the "backend" engineers. The complexity issues faced by the back-end are only getting worse with time, the proper solution is not adding more complexity to the situation, but paying down the technical debt in your organization.

If your front-end engineers end up twiddling their thumbs (no bugs/hotfixes), perhaps there is time (and manpower) to try to design and build a "new" system that can cater to the new(er) needs.

Re: After 6 years, I'm over GraphQL

#262

Post by hansonkd »

RVuRnvbM2e wrote: post #252
hansonkd wrote: post #197

Earlier quoted context omitted.

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.

What? GraphQL is purpose built to solve that in 1 Query. Not doing it in 1 query is on you not the protocol.

In practice with REST the frontend engineer didn't want to wait and tried to use the existing REST endpoints, did N+1 API HTTPS calls and then joined them client side in javascript.

Re: After 6 years, I'm over GraphQL

#263

Post by aeonik »

dventimi wrote: post #134

I generally agree and am likewise "over" GraphQL. Having said that, I disagree on some of the finer points. First, some of these issues--authorization, security, N+1--can be mitigated by using something like Prisma, PostGraphile, or Hasura, instead of crafting GraphQL backends with code. Second, there are gains to be made by compiling a GraphQL operation to a single operation in the underlying database's query langua…

N+1 problems were the primary bottleneck in a Websphere backendi worked on for years.

Transactions were being aggregated with thousands to 10s of thousands of SQL statements like this.

    SELECT * from customer
    where id =
The developers had no idea the ORM was doing this under the hood.

It's trivially easy to say that if every SQL statement took 1ms to execute, that thousands of round trips can really start to tank whatever process it might be blocking.

Re: After 6 years, I'm over GraphQL

#264

Post by eYrKEC2 »

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?

It may not be an exact analog, but "swagger UI" for openapi is the best I've seen like GraphiQL. Example https://petstore.swagger.io/ . Not sure of other alternatives.

No analog for "subgraph federation systems", unless a load balancer will suffice.

Re: After 6 years, I'm over GraphQL

#265

Post by stratigos »

The hype train strikes yet again! In fellow consultancy circles, we were giving talks on exactly this back in '17 and '18, but the hype train was too strong then. It was even harder to convince this same crowd that SPAs are usually a bad idea, and emerging technology like Hotwire or LiveView would soon eclipse the SPA-obsessed culture. GraphQL is immensely powerful and useful for its exact use case, and extremely burdensome and expensive for any other use case. If you dont already know that use case, YAGNI. The same can be said for any hype train. The problem with any kind of hype train in tech is everyone looks for reasons to use whatever the new hyped thing is, rarely does anyone determine if the new hyped thing actually fits their use case(s). This will continue so long as there is a dichotomy of culture between youths and those with lengthy experience. We old people will continue to point out exactly why this or that is pure hype, and will continue to be drowned out by the emotions that come along with participating in hype.

Re: After 6 years, I'm over GraphQL

#266

Post by hansonkd »

realusername wrote: post #233
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…

> 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.

Re: After 6 years, I'm over GraphQL

#267

Post by [deleted] »

swader999 wrote: post #152
dopylitty wrote: post #129

Earlier quoted context omitted.

I wonder if this phenomenon happens in other industries as well. I can't imagine a road crew getting away with spending an extra year to build a road because they decided to use completely nonstandard equipment that doesn't work well for the task or they don't know how to operate. I especially can't imagine the road crew screwing up multiple jobs in a row because they change equipment every time they're starting to u…

Construction is always the wrong metaphor for sw dev. Think more like marketing campaign or product design.

[deleted]

Re: After 6 years, I'm over GraphQL

#268

Post by electrondood »

GraphQL is a great way for FE devs to make life harder for BE devs.

The entire point is composition + client customization of the response body, but in practice the request schema is never modified. And even if it were, you could just version a REST endpoint.

GraphQL is never done "correctly," adds a layer of obscurity to monitoring and error tracing, and I've yet to see a case where it's actually the right tool for the job.

Maybe if you need to aggregate calls to multiple services into one, but if you're trying to avoid latency by reducing number of calls, you still eat that latency while the GraphQL server makes those calls for you.

GraphQL sucks.

Re: After 6 years, I'm over GraphQL

#269

Post by arcticfox »

dudeinjapan wrote: post #251
fire_lake wrote: post #159

Earlier quoted context omitted.

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".

You can whitelist queries in most systems though. In development mode allow them to run whatever query, and then lock it in to the whitelist for production. If that type of control is necessary.

Re: After 6 years, I'm over GraphQL

#270

Post by bbkane »

tommica wrote: post #185
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…

> I find it a bit poor though that the only recommended alternative is OpenAPI rest APIs. What are your recommendations? gRpc?

Someone above recommended https://connectrpc.com/ , which looks quite promising to me. Maybe I'll get time to play with it today
Post reply on HN