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

631–640 of 721 posts

Re: After 6 years, I'm over GraphQL

#631

Post by hinkley »

esafak wrote: post #505
hinkley wrote: post #350

Earlier quoted context omitted.

I knew we were in trouble when we started having to sort the query criteria in order to support caching of requests. If I use graphQL again it’ll only be for admin features. Anything where very few users will use it and very infrequently. Preferably in spots where caching works against the workflow. OLAP vs OLTP. GraphQL is really about reducing friction between teams. High functioning distributed systems all have tw…

what's work stealing?

It’s when you can reassign a task earmarked for one machine to another after the fact. There’s a latency and throughput problem to keeping all tasks on a central server until a worker finishes an existing task.

But if you locally queue, and one worker gets unlucky and gets the longest tasks, then the whole cluster sits idle while this worker starts and finishes multiple tasks. If you reallocate the ones that haven’t started or have timed out, then the overall time comes down quite a bit (and in the latter case also covers workers that crash).

For development teams it could mean moving the boundary on a service or API so your team does more of the feature work than originally planned, because the other team keeps getting jammed up on bugs or other operational issues.

Re: After 6 years, I'm over GraphQL

#632

Post by nprateem »

jhatemyjob wrote: post #561
nprateem wrote: post #559

Earlier quoted context omitted.

I'm surprised it took so long. I worked with k8s and realised pretty quickly it was pointless for my org.

Yeah that's what I'm saying, it shouldn't be surprising, these delusions last entire careers. Look at all the people who base their career on Java

I just picked java up again recently and it's really OK now. I'd have used it for my project but spring boot doesn't have an auto-generated admin like django so I binned it.

Re: After 6 years, I'm over GraphQL

#633

Post by 1oooqooq »

nfw2 wrote: post #453
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…

Whitelisting the queries that clients can use in prod actually doesn't seem like a bad option to avoid a lot of these security issues, assuming you control the clients

heh. BE takes control over FE all over again and the cycle of job security continues.

Re: After 6 years, I'm over GraphQL

#634

Post by cess11 »

Xarodon wrote: post #460
cess11 wrote: post #276

Earlier quoted context omitted.

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

XML parsers suffer the same fragmentation issues that JSON parsers do. Go's XML parser straight-up emits broken XML when trying to output tags that have prefixed namespaces.

How come? Someone had a boring summer and made their own instead of using libxml2?

Re: After 6 years, I'm over GraphQL

#635

Post by j45 »

A lot of good reading and learning in the comments about where graphql usage can end up.

Has anyone experienced something similar with typedb? It feels a little too good to be true. Make it seems like graphql and nosql trauma.

Re: After 6 years, I'm over GraphQL

#636

Post by cess11 »

svachalek wrote: post #296
cess11 wrote: post #276

Earlier quoted context omitted.

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

What's missing in ECMA-404? Never had a problem with JSON parsers or writers, using it all day every day for decades. It's crappy in some ways, sure, like lack of full floating point support, but standardization is not an issue. XML is mostly already lost on the current generation of developers though, much less future developers. Protobuf and cousins generally do typed interchange more efficiently with less complexi…

It differs from the RFC, notably "text" is valid JSON according to ECMA but not the RFC. I've come across JSON parsers stumbling on the bottom part of ASCII, for example. JSON -> internal representation -> JSON commonly leads to loss of information.

Sure, protobuf is nice, but more limited in scope and closer to a JSON alternative than an XML alternative.

I use JSON every other day and have been for decades.

Re: After 6 years, I'm over GraphQL

#637

Post by jononor »

hamandcheese wrote: post #588
pyr0hu wrote: post #487

Earlier quoted context omitted.

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

Let's say you add a user object to your graphql. It's only so the viewer can inspect themselves (i.e. the current authenticated user). Maybe this is for a settings page or something. A while later, suppose someone adds some connection from user to, say, orders. The person who added orders to users was kinda lazy and assumed (somewhat correctly, at that moment anyway) that permissions weren't an issue. So there's no a…

This can happen pretty easily with ORMs also, which is commonly used together with REST. Not that it really detracts, these risks are quite real.

Re: After 6 years, I'm over GraphQL

#638

Post by AlchemistCamp »

fouc wrote: post #582
hackthemack wrote: post #564

Earlier quoted context omitted.

One of the things that really burned me out over the years is how many times I would say something to the effect of "Maybe using GraphQL is over complicating the process and we should just use the old tried and true methods" and I would get drowned out by everyone chasing the latest thing or derided for not wanting to try something new. "Maybe implementing CORBA for message passing is over complicating it." "Maybe us…

I'm always reminded of the mantra "Choose Boring Technology" https://boringtechnology.club

For a long piece that doesn’t once mention Erlang or Elixir, it’s the strongest argument for using them I’ve read.

You could literally replace every part of any of the stacks he mentioned with Erlang. Python/PHP, cron, memcache, even the databases in the extreme case. It’s an older tech, too, so in his model this amounts to spending m zero innovation tokens for the entire stack.

Re: After 6 years, I'm over GraphQL

#639

Post by marcus_holmes »

Last time I used GraphQL the front-end devs ended up writing a single query to hydrate the entire data model in one pass, so they could be sure the data was present for all the components. We spent a month on the backend enabling GraphQL and we could have saved that and written a single "api/getAllTehData" REST endpoint in about half an hour.

I'm looking at Shopify API at the moment, and there's a notification that they're deprecating their REST API and moving it all to GraphQL. I hope it's a joke. But I suspect not. Enshittification intensifies

Re: After 6 years, I'm over GraphQL

#640

Post by robbyiq999 »

I remember about nearly 6 years ago gql showing up in job postings, I scratched my head a bit because it was so new. And also just a QL, why hire based on it? Shouldn’t you pick techs easy to use AND LEARN. Thereby nullifying must-have-experiences

Perhaps now it might be;

Nice to haves: Enough experience with GraphQL to never suggest nor implement it.

These are the kind of experiences I think which truly matter.

Post reply on HN