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

271–280 of 721 posts

Re: After 6 years, I'm over GraphQL

#271

Post by smaudet »

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…

> With GraphQL the only time you need to update the backend is when those "utility" functions change (i.e. 3rd party api calls, etc) or the data model changes.

This is akin to saying that "directly exposing the database is easier, you only have to change things if the data changes".

And yes this is true, but when the data changes, or the environment changes, the paradigm falls apart a bit, no? Which is what the backend code was for, insulation from that.

> In Startups typically:

Yes, so for a short lived, non-scaled application its far easier to do it one way, and maybe that's fine for most small apps (that will never scale far). I suspect a lot of the push back comes from larger, less nimble, more backwards-compat focused organizations/apps.

Re: After 6 years, I'm over GraphQL

#272

Post by Ozzie_osman »

As an alternative datapoint, we use GraphQL for a medium-sized app, are several years in, and are pretty happy with it. The downsides he mentions are all true, but on the other hand, are addressable, and for us feel worth the benefits of getting flexibility and control on the client-side.

Re: After 6 years, I'm over GraphQL

#273

Post by awirick »

I've run into all of these issues running a GraphQL API and, while they aren't easy, they aren't exactly intractable either. Let's not pretend that OpenAPI/REST or Protobuf are perfect alternatives. They've each got their warts and tradeoffs.

The thing that I still _like_ about GraphQL is that it's a nice approach for expressing complex domain models over a protocol. If you are working with either REST or protos, you may still have to reason about graph-like structures but without the benefit of a graph-like schema.

Re: After 6 years, I'm over GraphQL

#274

Post by electrondood »

surfingdino wrote: post #111

I worked on two projects using GraphQL and don't want to do it again. Both times the backend was a mess and the "design" or the lack thereof had all the signs of being written by "evangelists" who got bored or got fired leaving the new arrivals to sort out the mess. I'm sure GraphQL is the right fit for some problem domains, but most of the problems I deal with are happily solved with the help of a REST API.

> written by "evangelists" who got bored or got fired leaving the new arrivals to sort out the mess.

BINGO.

Someone (VP Eng who was a FE dev) 7 years ago decided shiny new thing was the best and we had to use it, it was owned by FE team, then no one wanted to own it, now BE team has to deal with it, and every dev goes out of their way to avoid it in arch design for new features.

Have seen this at two companies so far.

Re: After 6 years, I'm over GraphQL

#275

Post by dventimi »

aeonik wrote: post #263
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 what…

> It's trivially easy to say that if every SQL statement took 1ms to execute

Good thing I don't say that! What I do say is that the number of SQL calls will tend to scale with the volume of data retrieved. Limit the volume of data the user even is allowed to request and you'll naturally limit the extent of the N+1 problem.

Re: After 6 years, I'm over GraphQL

#276

Post by cess11 »

mattbrewsbytes wrote: post #140
atsjie wrote: post #24

Worked on two GraphQL projects; I was quickly cured from the hype. I recognize a lot of points in this article. In both these projects the GraphQL had started small. I came in during a more mature phase of these projects (2 and 4 years). That's where the requirements are harder, more specific, and overall complexity has grown. Adoption and demand on the API were growing quickly. Hence you logically spend more time de…

> RPC and REST are just more straightforward to monitor, log, cache, authorize and debug. REST API's are a proven solution for the problem of other apps, including front-ends, needing data from a data store. Using JSON is much improved over the days of XML and SOAP. Beyond that there haven't been advancements in technology that cause fundamental shifts in that problem space. There have been different opinions about s…

JSON winning over XML is like saying CSV won over MySQL. They aren't equivalent.

Much like CSV, JSON isn't particularly standardised and different parsers and writers will do different things in some situations. Usually it doesn't matter, but when it does you're probably in for a lot of pain.

If you handle structured data and the structures might change over time, JSON isn't a good fit. Maybe you'll opt for JSON Schema, maybe that'll work for your use case, but with XML you can be quite sure it'll be reliable and well understood by generations of developers.

The tooling is generally very good, commonly you can just point your programming language to the XSD and suddenly you have statically typed classes to program against. Perhaps you'd like to store the data in a RDBMS? You can probably generate the DB schema from the XSD. If you want you can just throw JSON into MongoDB instead, but there will be very important tradeoffs. Same goes for UI, you can write some XSLT based on the XML schema and suddenly you get web views directly from API responses. Or you could use those classes you generated and have your GUI code consume such objects.

None of this is as easy with JSON as it is with XML, similar to how many things aren't as easy with CSV as with a RDBMS.

Re: After 6 years, I'm over GraphQL

#277

Post by chuckadams »

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.

The entire point of graphql servers is that they're basically ORMs (or use an underlying ORM) that turn complex nesting into a single query's worth of joins. It won't beat hand-crafted sql from an expert, but if that's your preferred approach, debates on the relative merits of different query frameworks are all academic to you anyway.

Re: After 6 years, I'm over GraphQL

#278

Post by randomdata »

dopylitty wrote: post #129
projectileboy wrote: post #100

Earlier quoted context omitted.

Exaaaactly. I worked on big systems at a very large retailer, and at a very large bank, and in each case, there were reasons why GraphQL worked very well for us. But 90+% of developers across the world adopt tools and technologies because they look fun and shiny, not because they need it. For the overwhelming majority of developers (who in most cases are working at medium-to-large-sized companies on internally-facing…

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…

I don't know about construction, but as a farmer it's pretty natural to look at what your neighbours are doing and if they adopt a new technology in their operation you're at least going to give some thought to doing the same.

But I think it comes with a lot more reluctance and skepticism. You are not likely to jump in head over heels, and even when you do give it a try I expect most farmers will do so with the attitude of "if it doesn't work at least I can always go back to the old way".

The "OMG this is amazing and will solve all of my life's problems" attitude I see in tech certainly isn't there in my experience.

Re: After 6 years, I'm over GraphQL

#280

Post by fiddlerwoaroof »

hansonkd wrote: post #262
RVuRnvbM2e wrote: post #252

Earlier quoted context omitted.

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.

A lot of graphql implementation end up moving the n+1 problem to the query resolver.
Post reply on HN