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

361–370 of 721 posts

Re: After 6 years, I'm over GraphQL

#361

Post by arp242 »

hansonkd wrote: post #197
ComputerGuru wrote: post #188

Earlier quoted context omitted.

> With internal REST for companies I have seen so many single page specific endpoints. Gross. Hardly gross. It is what it is and it’s universal across the domain. I bet Windows has internal APIs or even external ones that were created just for one page/widget/dialog of one app. It’s the nature of things at times.

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.

This is like, an hour per endpoint. For maybe 30 endpoints (high figure for many apps) throughout the lifespan of your application. But let's say 3 hours: you're talking about 90 hours in total, over a period of 2 or more years. It's really not that much.

And GraphQL isn't free either; you need to actually implement that. It pervades your entire stack, too – it's not something you can just "put on top of it".

I think that in many cases, perhaps even most, GraphQL is a "spend 8 hours to automate a half hour task" kind of affair. Are there cases where that's not the case? Probably. Maybe your specific use case is one of them. But for the general case? I'm entirely unconvinced.

Re: After 6 years, I'm over GraphQL

#362

Post by phaedryx »

I worked on a GraphQL API a few years ago and we solved these problems at the beginning and then forgot about them. We generated the schema for a user from their CanCan abilities (CanCan can handle attribute-level access, I wrote the PR). Shopify has support gems for the N+1 stuff, if I remember correctly. You can limit how many levels deep your query can go. We added some rate limiting.

Basically, these are all solved problems.

Re: After 6 years, I'm over GraphQL

#363

Post by hot_gril »

romanovcode wrote: post #10
oksteven wrote: post #8

Earlier quoted context omitted.

agree, it solve problem at FB for sure, that is a good point.

Same with Redux. Solved problem in FB. Increases complexity tremendously for 90% of other websites. I remember seeing the tutorial being showed in Todo app and thinking "wtf is this garbage needed for here". I'm glad Redux hype train is over and nobody is using it on new projects no more.

If it takes more than a minute to understand how a single button example works, one should give up. Maybe some day I'll come crawling back to Redux, that'll be fine, but so far it hasn't happened. Same with Angular.

Re: After 6 years, I'm over GraphQL

#364

Post by taeric »

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…

That fun fact bothers me at a fundamental level. I've seen it happen so many times and is really painful when the people were promoted out of the place. Even worse when they are good developers, but often in a cowboy style where they confuse their energy for some fundamental efficiency of what they were doing.

Re: After 6 years, I'm over GraphQL

#365

Post by [deleted] »

kiney wrote: post #196
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…

Unpopular opinion: I'm actually a fan of singe page specific endpoints. You get much easier debugging, easier to audit security, easier performance optimization an the imho pretty small price to pay is that it's "not elegant" and a bit of backend code

[deleted]

Re: After 6 years, I'm over GraphQL

#366

Post by hansonkd »

realusername wrote: post #359
hansonkd wrote: post #337

Earlier quoted context omitted.

> pile into the definitions That is how REST works but is the opposite of the way GQL works. You don't pile into existing defintions but extend the current definitions out. A team needing new data doesn't affect the consumption of other teams. which is not the case of REST where if one team needs to change a REST endpoint to return different shape of data, they have to verify the new shape with other teams.

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 has built in annotations for deprecation, something not in REST.

Re: After 6 years, I'm over GraphQL

#367

Post by klibertp »

marcosdumay wrote: post #318
kiney wrote: post #196

Earlier quoted context omitted.

Unpopular opinion: I'm actually a fan of singe page specific endpoints. You get much easier debugging, easier to audit security, easier performance optimization an the imho pretty small price to pay is that it's "not elegant" and a bit of backend code

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 "backend" developer split is so incredibly inefficient that it's really jarring—you take something that should take 2 hours and magically, through tickets, delegation, and waiting for results (then repeat that for debugging, who knows how many times!), make it into a 2-3 day task.

I once reproduced (black-box style!) a two-week effort by a three-man team in six hours of work simply because I had PyCharm and IDEA opened side-by-side and could write code on both sides at the same time.

If someone has a good explanation for why the full-stacks that were once the norm went almost extinct, I'd be happy to give it a read!

Re: After 6 years, I'm over GraphQL

#368

Post by randomdata »

hansonkd wrote: post #355
randomdata wrote: post #341

Earlier quoted context omitted.

You don't, obviously – we already talked about how many don't. But if you don't have a graph of "microservices" in which to query, what do you need GraphQL for? Especially if all you are doing is returning the results from a database. The database will already have its own API. Why not just use it? The native API is always going be better than your attempt to translate.

Because exposing your Database to the outside world is asinine. GQL sits between letting the frontend query semi-customizable queries and not having any customizability to select related resources.

Nobody said you should expose your database to the outside world. Do you not understand the difference between APIs and services?

Re: After 6 years, I'm over GraphQL

#369

Post by travellingprog »

shepherdjerred wrote: post #336
travellingprog wrote: post #128

Earlier quoted context omitted.

TanStack Query (fka React Query) is a REST client similar to Apollo Client, with many of the same pros and cons: https://tanstack.com/query/latest/docs/framework/react/overv...

TanStack Query isn't a REST client. It's a generic data fetching framework. You could use TanStack query with GraphQL, Apollo, REST, or any other data source.

yeah, you're right!

Re: After 6 years, I'm over GraphQL

#370

Post by arp242 »

bryanrasmussen wrote: post #332
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…

>And both these projects had clear signs of "learning-on-the-go" with loads of bad practices I think two projects having loads of bad practices is too small a dataset to really assume anything, you sort of need to see widespread "bad practices" in the tech to be able to determine that the bad practice is actually the norm practice and there is perhaps a flaw in the tech that encourages that norm.

You're not wrong, but at the same time I think it's a decent data point that getting it right is not straight-forward and that, practical speaking, you at the very least need to think very carefully before actually using it.

"The idea of it" is sometimes fine, but then there's also "the practicality of it", and sometimes that's a very different thing.

Remember the old microkernel vs. monolithic debate; everyone more or less agrees that in principle, a microkernel is better. But the practicality of it is a lot more complex, so monolithic kernels and hybrid ones are much more common. Microservices vs monolithic is essentially the same debate, and I've seen a lot of Microservices with very poor implementations and a lot of problems. That doesn't mean the idea is bad in itself, but if it's hard to execute well, then you do need to be very careful.

There's tons more examples of this. You also see this sort of thing in e.g. politics, where what's "more fair" vs. "what's actually achievable without introducing heaps of bureaucracy and overhead" are sometimes very different things.

In the case of GraphQL, I think it's pretty obvious that the general idea, as described from a high level, is a good one. But the practicalities of it are a lot less straight-forward, as this article explains reasonably well IMHO.

Post reply on HN