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

371–380 of 721 posts

Re: After 6 years, I'm over GraphQL

#371

Post by drpossum »

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…

> used it in a small project, and liked almost every bit of it

This is the difference

Re: After 6 years, I'm over GraphQL

#373

Post by Kabootit »

jakubmazanec wrote: post #68

For web apps (not simple pages), developed by a single full-stack developer, I think the best solution currently is to use Remix's loaders + actions (i.e. no need to create separate API layer) with EdgeDB (EdgeQL is like GraphQL but with capabilities of SQL, and the DB itself has authn+authz baked-in).

Agree! Came here to give props to EdgeDB. Completely removes the API layer if used with something like SvelteKit. Everything defined in their schema language which then generates typed clients for you.

In my experience the use case is not limited to a single full-stack developer - this approach has turned our entire polyglot team into full-stack devs — no one is afraid of the data layer now. Super refreshing.

For public facing endpoints, "exposing an OpenAPI 3.0+ compliant JSON REST API" would be the first thing I'd reach for.

Re: After 6 years, I'm over GraphQL

#374

Post by joshstrange »

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 nothing to do with GraphQL anymore. Everything we attempted to fix our permissions issues just caused more problems. It would break existing queries and debugging GraphQL sucked so much.

If you only live on the frontend and someone else is responsible for the backend GraphQL then I understand why you might like it. From that perspective it's amazing, you can get as little or as much as you want with the specific fields you want. No waiting on the backend team to write an endpoint. However even then you end up saving queries as files or abstracting them (maybe IDE support has improved but it wasn't great last time I was using it ~5 years ago) and now you just have REST endpoints by another name.

At one point we considered whitelisting specific queries and that's when I knew we had gone too far and made a mess for ourselves. If we had taken the time to just write REST endpoints instead we would have gotten way more done and had way fewer grey hairs.

Re: After 6 years, I'm over GraphQL

#375

Post by chuckadams »

hansonkd wrote: post #339
discreteevent wrote: post #322

Earlier quoted context omitted.

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://n…

The Language Libs like Strawberry implement what he is describing by intermediate application code. It doesn't map directly to a database. GQL implementations don't map to the database but to application code.

Specifically, GQL implementations always map to a `resolve(source, args, context, info)` function (the names can be anything, the types are what matter). In that sense, you also get a standard server interface similar to wsgi/psgi/rack, but much more fine-grained (there can be a resolver for every field in the query).

Re: After 6 years, I'm over GraphQL

#376

Post by hot_gril »

rglover wrote: post #317

Worked with GraphQL from 2017 to 2021. It was the last tech "hype" I bought into. At first, it made a lot of sense and the thing that got me was the structure. But eventually, I realized how much extra work and duplication of everything there was. At the time, too, things that should have been easy like subscriptions had a nightmare API packed with weird terminology that made implementing simple features a slog. The…

I'd much rather find out the hard way that I need something than find out the hard way that I don't. There was one project where OpenAPI became a bit painful and I rediscovered why GraphQL could make sense, but it didn't reach the threshold.

Re: After 6 years, I'm over GraphQL

#377

Post by Izkata »

mdaniel wrote: post #348
Izkata wrote: post #163

Earlier quoted context omitted.

From https://graphql.org/learn/queries/ This isn't even close to valid json: { empireHero: hero(episode: EMPIRE) { name } jediHero: hero(episode: JEDI) { name } }

and I strongly agree with GP because those arguments https://graphql.org/learn/schema/#arguments > can get to be insaneo with anything other than simplistic "episode: EMPIRE"; I regrettably can't link directly to it but https://docs.github.com/en/graphql/reference/objects#:~:text... shows that stuff can start to be more than the interior field selection, to say nothing of schemas that define complex typed arguments e…

That has some json-ish embedded inside it, but the query itself still isn't json.

And even the embedded part isn't valid json without quoting the keys.

Re: After 6 years, I'm over GraphQL

#378

Post by BiteCode_dev »

hansonkd wrote: post #333
BiteCode_dev wrote: post #326

Earlier quoted context omitted.

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.

> more complex, more expensive to maintain, consuming more resources, Idk. Strawberry GQL and most GQL libraries are maybe equally as complex as the REST libraries for the same language. Strawberry and FastAPI I would say are equal in complexity and configuration. It would be hard for me to say GQL is more expensive or consumes more resources. Opposite of the purpose and most uses of GQL.

In stawberry you make a method per field you want to retrieve, I would say it is indeed more complex and costly.

Re: After 6 years, I'm over GraphQL

#379

Post by riffraff »

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…

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 actually invest time in learning whatever back-end they're dealing with this time.

Everything is just a lot more complicated these days, and if you've been around for a while you may not be excited anymore by the churn, but rather fed up.

Re: After 6 years, I'm over GraphQL

#380

Post by realusername »

hansonkd wrote: post #366
realusername wrote: post #359

Earlier quoted context omitted.

With REST, the endpoints are team based if you have even a semi-competent CTO so you never have this problem, you just check who owns the controller and that's it. With GQL though, good luck retracing who owns what field and what does it affect if you change the definition of what it returns, especially that you you are not even using it on the same language. Bonus points here if you are managing something outside of…

GQL you would only care about if someone removed a field not if someone added a field. How would adding a field change existing GQL calls return? Doesn't make sense. Also, Its about 1 line to set up CI to extract all GQL queries from a typescript project and do static analysis to check against the schema. But again you only care if someone deletes a field, and even if you have to delete it, at least the GQL schema ha…

Deleting things happens all the time though.

Yeah sure you can make it work with anything if you spend the extra effort but the ownership really isn't as defined as in REST.

Is there code which have fuzzy or no ownership? Are there changes which affect other teams? Suddenly those became much harder questions to answer.

Post reply on HN