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

571–580 of 721 posts

Re: After 6 years, I'm over GraphQL

#571

Post by [deleted] »

ForHackernews wrote: post #476
burutthrow1234 wrote: post #397

Earlier quoted context omitted.

GraphQL absolutely feels like a technological solution to an organizational problem. What if your front-end team wants to write crazy queries and your back-end team wants to build their resume doing Real Engineering, but what you actually need is just a CRUD app? Now your backend devs aren't bored writing "business logic" and your front end devs aren't bored waiting for your backend devs. You have a new class of insc…

Sounds good to me. I'll do GraphQL for $250k.

[deleted]

Re: After 6 years, I'm over GraphQL

#572

Post by int_19h »

mc10 wrote: post #518
int_19h wrote: post #437

Earlier quoted context omitted.

IMO the fact that being a full-stack dev is so taxing is an indication that the stack as a whole is just way too complex and overengineered. Which is rather obvious from looking at the state of affairs on the frontend side of things. Desktop GUI devs don't usually have those problems.

I don’t think this is a fair conclusion; web development is harder than desktop GUI development for various reasons. For one, clients (mobile, desktop) are drastically different with all sorts of downstream implications: - Differing screen size requiring responsive design - Internet speeds magnitudes different - Intermittent internet - Uneven feature support due to different versions of browsers - Everything needs to…

Thing is, even when web apps are essentially used as desktop app replacement (Electron etc), all the complexity discussed here is still there.

As far as looking OS-native, this is (unfortunately) increasingly less relevant as OSes themselves drop desktop UX consistency even internally. But that aside, Qt is still around and is a very mature framework for "near native" UI, and then there's Avalonia and others. Even Gtk is surprisingly decent on Windows these days. Although I'm not sure what this all has to do with the original subject, since web apps most certainly don't look native anywhere.

Re: After 6 years, I'm over GraphQL

#573

Post by intelVISA »

burutthrow1234 wrote: post #397
joshstrange wrote: post #374

I bought into the hype and I feel bad for the company where I implemented it. One true endpoint to rule them all and cause endless headaches in the process. With most tech that I screw up I assume that "I wasn't using it right" but with GraphQL I'm not sure how anyone could. The permissions/auth aspect alone is a nightmare. Couple that with potential performance issues (N+1 or just massive amounts of data) and I want…

GraphQL absolutely feels like a technological solution to an organizational problem. What if your front-end team wants to write crazy queries and your back-end team wants to build their resume doing Real Engineering, but what you actually need is just a CRUD app? Now your backend devs aren't bored writing "business logic" and your front end devs aren't bored waiting for your backend devs. You have a new class of insc…

> GraphQL absolutely feels like a technological solution to an organizational problem

Because it is :')

Re: After 6 years, I'm over GraphQL

#574

Post by finack »

wruza wrote: post #481
finack wrote: post #294

Earlier quoted context omitted.

No, that's an important facet of compatibility. If a change is purely additive, existing clients will keep working, something the industry has basically forgotten all about, it seems.

I think I have to agree with this correction in general, but don’t take one commenter for a whole industry please. I’m not even remotely representative of it.

I'm not, I'm using my decade of experience and nascent alcoholism.

Re: After 6 years, I'm over GraphQL

#575

Post by joshstrange »

mlnj wrote: post #570
joshstrange wrote: post #496

Earlier quoted context omitted.

Well that wasn't me, I implemented an Akka + GraphQL nightmare instead :) Joking aside, I'm sorry that happened to you and I'm sorry for the people that took over the system I helped to write.

Been there, done that. Did Akka; thank goodness that didn't make it to production. GraphQL: Helped in many ways. Hurt in so many too. In production. Everything in Actors: State was everywhere. So much pain. In production. I just use Postgres + RPCs for everything now.

Yeah, I love my TypeScript serverless backend project and my successful DynamoDB project but often I think I could have saved a lot of pain by using PHP and/or Postgres.

Re: After 6 years, I'm over GraphQL

#576

Post by tango12 »

I’m the founder of Hasura - sharing some notes from how I’ve seen GraphQL usage evolve over the last few years.

1. GraphQL was and remains insanely hard to build without an underlying data layer that does the heavy lifting. Without projection push-down, predicate push-down, a data layer that can support heavy parallelism it’s untenable. Exactly the problems the OP highlights - needing to “hoist”…

2. GraphQL on REST is an anti-pattern. The hype takes you there, but the juice is not worth the squeeze. The problem was lack of types? Add openapi. The problem was custom aggregation endpoints? Make it super easy / cheap to build aggregate endpoints in REST. Use an AI copilot to write an aggregate REST endpoint and a openapi schema for it even. But maybe the last thing to do is to build annd mainatian another API layer with a completely different execution model.

It’s not what it was meant for perhaps, but GraphQL’s killer use-case is an API to access / operate on data. Especially when there are multiple consumers of data (services, apps) and they don’t own the underlying data sources or speak the underlying language of the database. This turns out to be the underlying problem behind a lot of api, data modernization / migration / decomposition efforts.

The cost of this approach is implementing Graphql by building a compiler/planner with a robust authz system baked into it. A resolver based approach can never cut it, unless you resolve a query plan - aka build a compiler.

If you want to use graphql to just batch rest endpoints, it’s very likely going to become legacy tech as soon as the team that built it starts to move on.

Re: After 6 years, I'm over GraphQL

#577

Post by jeanlucas »

tango12 wrote: post #576

I’m the founder of Hasura - sharing some notes from how I’ve seen GraphQL usage evolve over the last few years. 1. GraphQL was and remains insanely hard to build without an underlying data layer that does the heavy lifting. Without projection push-down, predicate push-down, a data layer that can support heavy parallelism it’s untenable. Exactly the problems the OP highlights - needing to “hoist”… 2. GraphQL on REST i…

> GraphQL on REST is an anti-pattern.

Yes.

Re: After 6 years, I'm over GraphQL

#578

Post by tormeh »

I learned REST first, then I started working somewhere with gRPC. It was a revelation. Type-safe APIs! I was sold. Now I work somewhere where we’re all-in on GraphQL. It’s just a massive pain for very little benefit. In many ways it’s worse than REST. It really only works well if you’re writing something meant to behave like a database. Normal backends don’t want to do this.

Re: After 6 years, I'm over GraphQL

#579

Post by tormeh »

solidasparagus wrote: post #488
mattbrewsbytes wrote: post #140

Earlier quoted context omitted.

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

I think IDLs and gRPC in particular are a meaningful advancement in the problem space. The ecosystem and productivity that they enable via programatic tooling were really eye-opening for me (The OpenAPI ecosystem is, imo, extremely poor). They also have better support for modern techniques like streaming and even load-balanced streaming.

Amen, brother! gRPC is the best thing since sliced bread. Typed APIs are just so nice to work with, and OpenAPI is very unsatisfactory.

Re: After 6 years, I'm over GraphQL

#580

Post by bpicolo »

hosh wrote: post #393
joshstrange wrote: post #374

I bought into the hype and I feel bad for the company where I implemented it. One true endpoint to rule them all and cause endless headaches in the process. With most tech that I screw up I assume that "I wasn't using it right" but with GraphQL I'm not sure how anyone could. The permissions/auth aspect alone is a nightmare. Couple that with potential performance issues (N+1 or just massive amounts of data) and I want…

Hmm. I wonder if there is some kind of query builder that can live server-side. That is, capture the flexibility of a query language when developing, and then consolidating that when going into production. Though I guess you can do that with REST too. I'm currently exploring all of this myself. I have a side project in mind that can use a graph db, and I thought a front-end graphql can work well with a graphdb backen…

Back when GraphQL started being around, I prototyped a proxy server that accepted a JSON dsl to resolve a series of calls to a backend JSON/REST API, so that the chain of calls would be batched up closer to the server.

Worked pretty well. Definitely something that could be make to. Kind of graphql themed but how it translates to REST can be explicit.

Post reply on HN