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

481–490 of 721 posts

Re: After 6 years, I'm over GraphQL

#481

Post by wruza »

finack wrote: post #294
wruza wrote: post #255

Earlier quoted context omitted.

Because receiving unexpected data is a signal you rarely want to ignore in programming. Doesn’t matter whether you’re gonna use it or not.

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.

Re: After 6 years, I'm over GraphQL

#482

Post by chrisdrobison »

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…

No idea why you bundle Mongo in there. I use Mongo in multiple production apps and I've never, ever looked back. Wouldn't even consider RDBMS's at all after my experience with Mongo unless I absolutely had to.

Re: After 6 years, I'm over GraphQL

#483

Post by smaudet »

andrewingram wrote: post #454
smaudet wrote: post #248

Earlier quoted context omitted.

> What if your engineers change $client/$server and the new version makes really expensive queries? Yes, so the cost benefit here is not in favor of GraphQL. If both technologies ultimately suffer from the same issues (what to do about unpredictable clients), but one is far more complex to implement and use (GraphQL), then there's a clear winner. Spoiler, its not GraphQL. Page specific endpoints, I would argue, can d…

When you build a GraphQL server, you’re creating a system that outputs page-specific endpoints. They can be generated just-in-time (the default) or at build time (the general recommendation). The engineering work involved shifts from building individual endpoints to building the endpoint factory. This shift may or may not be worth the trade off, but there are definite advantages, especially from the perspective of wh…

https://graphql.org/blog/2020-12-08-defer-stream/

This? Yeah, that seems neat, for command/batch queuing.

I'd be curious how it compares to e.g. rest apis returning refs to e.g. webrtc streams or tcp/udp ones for non-browser. I presume the main advantage would be client side.

Re: After 6 years, I'm over GraphQL

#484

Post by sodapopcan »

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…

This was my experience. We were forced to use it in a project where we controlled the entire stack. It was so much extract work just to serve data from a backend we had full control over. I don't dislike it but I feel like it's far more of a time-and-place technology than most that people just default to using in any old situation. I'm sure some have used it successfully in a similar scenario—we certainly weren't exactly super knowledgable about it when we were told to use it. We tried, though!

Re: After 6 years, I'm over GraphQL

#485

Post by squidsoup »

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 is easily fixed by introducing a linter - relay complains about unused fields by default.

Re: After 6 years, I'm over GraphQL

#486

Post by esafak »

teaearlgraycold wrote: post #455
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…

I think a lot of people like GraphQL because it provides strongly typed API interfaces. But I've been able to hack together a better REST alternative in full-stack typescript codebases. And my solution doesn't need to compile any kind of client or intermediary.

You can type your REST API too. https://restfulapi.net/json-schema/

Re: After 6 years, I'm over GraphQL

#487

Post by pyr0hu »

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…

Can you give an example for the permission issues that you had with GQL and would've been easier in REST? Genuinely curious, as I'm implementing a GQL backend with simple permission handling and haven't run into anything yet, but I wanna know what could await me

Re: After 6 years, I'm over GraphQL

#488

Post by solidasparagus »

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…

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.

Re: After 6 years, I'm over GraphQL

#489

Post by healthdare »

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…

How does an engineer buy into hype? Ur supposed to be analytical. Everytime some new frontend bs like tailwind comes out I roll my eyes. People want to be famous not practical. React is only popular because of Facebook and react native. It's a shit ecosystem and frontend tool set. Webpages are slow due to bloat not shadow dom.

Re: After 6 years, I'm over GraphQL

#490

Post by jamra »

svieira wrote: post #473
AaronFriel wrote: post #429

Earlier quoted context omitted.

This is a vague recollection, but I seem to recall Meta/Facebook engineers on HN having said they have a tool that allows engineers to author SQL or ORM-like queries on the frontend and close to where the data is used, but a compiler or post-processor turns that into an endpoint. The bundled frontend code is never given an open-ended SQL or GraphQL interface. And perhaps not coincidentally, React introduced "server a…

> I seem to recall Meta/Facebook engineers on HN having said they have a tool that allows engineers to author SQL or ORM-like queries on the frontend and close to where the data is used, but a compiler or post-processor turns that into an endpoint. I don't know about on-HackerNews but there's a discussion about their "all of Facebook optimizing compiler" infrastructure from when they did the site redesign in 2020: ht…

Code generation is very common at Meta. One just needs to create a query or fragment. A fragment can be spread at the root query level using relay so it will do the fetch once. It gets more complex because you can lazily query more data based on parameters you pass into GQL. It feels like magic and is really annoying imo.
Post reply on HN