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

691–700 of 721 posts

Re: After 6 years, I'm over GraphQL

#691

Post by torginus »

sodapopcan wrote: post #484
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…

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

Why does Facebook keep pumping out 21st century moral equivalents of UML and OOP design patterns - trendy technological ideas that are often considered the gateway to writing 'professional' code, but end up being overengineered boilerplate nobody actually needs.

GraphQL is one, Redux is another.

Re: After 6 years, I'm over GraphQL

#692

Post by crabbone »

vitiral wrote: post #427
crabbone wrote: post #165

Earlier quoted context omitted.

Just use SQL? A much better language with saner semantics overall. My first and last impression from GraphQL were that whoever wrote it hadn't had a chance to work with other query languages. A lot of the problems OP mentioned were quite on the surface. Had you ever used ORM, you'd be very intimately familiar with N+1 problem. Had you ever encountered SELinux, you'd be painstakingly familiar with authorization proble…

> Protobuf Google's entire software backbone is literally built on this haha. There are things about it I don't like, but it DEFINITELY scales

Oh but there are some hilarious and obvious problems with Protobuf that are a sure tell of the author being a first-timer.

For example, messages inside messages and messages in other "packages" can, accidentally be named the same, and then the author of such a definition will be spending a lot of efforts debugging such code because, without telling anyone, Protobuf parser (the one written by Google, other implementations behave differently) will prefer the one inside another message to the one inside another package.

To make this more obvious, suppose Protobuf had "package" separator, let it be ":". Then, you could define messages a.b:c and a:b.c. Then, there's no ambiguity. However, since there's none, and physically, the message a.b:c lives in b.pb file and a:b.c lives in a.pb file...

Another hilarious aspect is that fields inside messages are allowed to repeat (in the wire format). And the last one wins! So, using this easy foot-gun, Protobuf made streaming impossible.

Another tell is that Protobuf didn't have a formal grammar until much, much later. And once it was written, it was never tested on the real parser. I submitted a handful of tickets against that grammar because it was ridiculously bad. Simple and very common stuff like strings, that requires a little bit of sophistication (because of quotes and escape characters) was broken in the way indicative of someone doing it for the first time (and not even trying to test). The kind of screwups I saw my classmates do in our automata theory class.

It's wild and weird how such a poorly conceived "invention" gets enormous amount of attention and use (probably because of the company behind it).

Re: After 6 years, I'm over GraphQL

#693

Post by vitiral »

crabbone wrote: post #692
vitiral wrote: post #427

Earlier quoted context omitted.

> Protobuf Google's entire software backbone is literally built on this haha. There are things about it I don't like, but it DEFINITELY scales

Oh but there are some hilarious and obvious problems with Protobuf that are a sure tell of the author being a first-timer. For example, messages inside messages and messages in other "packages" can, accidentally be named the same, and then the author of such a definition will be spending a lot of efforts debugging such code because, without telling anyone, Protobuf parser (the one written by Google, other implementat…

Good stuff. Most languages are non-perfect. I will say that of the things made by Google to "scale" I think protobufs are a better one.

Re: After 6 years, I'm over GraphQL

#694

Post by tangkikodo »

hansonkd wrote: post #172

I never understood peoples positions that GraphQL all of the sudden the frontend can make any Query it wants and control is out of the hands of the backend. That seems orthogonal to my experiences with GraphQL. GraphQL is a protocol and you define the implementation. Some GraphQL implementations like REST implementations try to generate everything for you. That is not "GraphQL" but one type. GraphQL is way to query n…

I would like to recommend pydantic-resolve, it can enjoy benefits from botn rest/rpc and gql.

the triky part of gql is we need to build a Query system for all business requirement in single entry, and we can not predict what query will be issued by client.

this is anti-pattern because presenter layer should not care about how data is composed.

It would be much easy if we treat each rest/rpc endpoint as a GQL entry, use resolver and dataloader to quickly & easily build complicated view data, everything is still under the control of backend.

here is a demo. https://github.com/allmonday/pydantic-resolve/blob/master/ex...

Re: After 6 years, I'm over GraphQL

#695

Post by tangkikodo »

abound wrote: post #119

Having worked extensively with OpenAPI, GraphQL, plain JSON/HTTP, and gRPC/Buf Connect services, most of this rings true for me. One thing the author doesn't mention is that you can limit the set of queries clients can call in a GraphQL service, by hash or signature. This mitigates a lot of the gnarly performance and security issues because the attack surface goes from "arbitrary queries" to "queries you've already '…

different tool for different aspect.

using OPENAPI, rpc, GQL types in client, etc to share typing (schema) information between client/server

resolver/dataloader in GQL, eager join in ORM is to handler internal data composition

presenter layer should not care about data composition, so that writing Query at presenter is an anti-pattern.

presenter should fetch schema info & data passively, like what https://github.com/hey-api/openapi-ts did, the job of implementation belongs to backend.

In fact what rest/rpc really need is the resolver and dataloader, to help backend easily extend or composing data together, and immediately transferring the schema & data to clients.

pydantic-resolve is the python binding for this idea.

Re: After 6 years, I'm over GraphQL

#697

Post by Yhippa »

hackthemack wrote: post #564
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…

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…

Think about all the LinkedIn clout you missed out on by not incessantly talking about the ${NEW_THING}!

Re: After 6 years, I'm over GraphQL

#698

Post by ethagnawl »

ethagnawl wrote: post #500
jack_riminton wrote: post #442

Earlier quoted context omitted.

This is why the Rails community should be applauded in my book, for their dogged determination that we should keep it a “one person” framework. Yes it may not be as performant, type safe or flashy on the front end but my god it’s productive. At my startup there are 7 devs who can all do tickets across the stack and as we grow I think it would be good if we could resist the pressure to silo and specialize

> but my god it’s productive. It really is. Regrettably, I've drifted away from it in large part because of client requirements for more "modern" and "maintainable" solutions (e.g. Python or Node; I'll take Python every time, thanks). Django comes very close in terms of productivity (and is better in some ways: auth, admin, etc.) but the Rails CLI, generators and community (not sure if this is still relevant) give it…

I don't agree with much of this but it's timely: https://zenstack.dev/blog/js-fullstack

Re: After 6 years, I'm over GraphQL

#699

Post by sk10y »

As much as I opposed GeaphQL at first I found a use case for it and have been using it successfully for past 4 years. In my application GraphQL is just a layer on top of GRPC API. It helps to fetch data across different services and glue together different entities in one frontend friendly payload. Since GraphQL is essentially a proxy in front of GRPC (which is the real API, exposed over REST endpoints as an alternative to GraphQL) I haven't suffered from most of the issues described by author.

Authorization is performed by GRPC which returns only fields available to the user, rate limiting is performed on GRPC requests so at some point your data will start coming partially if you make too many queries or query that is too complex, N+1 problem is still there, but in a distributed system it's there even without GraphQL, the mitigation is caching in GraphQL server on GRPC request level.

In my experience GeaphQL really helped decouple frontend and backend and I'm pretty happy about it.

Besides GraphQL offers some standard way of making server side event streaming, it's not supported that well, but at least it's more comprehensive than bare web sockets.

I never got around to implement mutations though, individual change requests via REST are enough.

Re: After 6 years, I'm over GraphQL

#700

Post by vintermann »

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

There's boring and there's boring. Personally I think Java EE / beans and SOAP is really boring, but I would never, ever choose it.
Post reply on HN