After 6 years, I'm over GraphQL • Hacker News Board

Re: After 6 years, I'm over GraphQL

#601

Post by grounder » Fri, May 31, 2024, 2:06 AM UTC

pants2 wrote: post #426

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

Buf Connect or any RPC design really is great. I'm sick of REST too. No more endless discussions about how to make this endpoint the most RESTful or how to cram a feature into REST that doesn't fit. "Oh you need an endpoint to hibernate the server? Just POST a new Hibernate object to the /api/v2/hibernations service." No. With RPC we can just make a HibernateServer call and be done with it.

Can you provide a link where I can learn more about "Buf Connect". A search gives me a lot of different results. Not sure what's official.

Re: After 6 years, I'm over GraphQL

#602

Post by cletus » Fri, May 31, 2024, 2:10 AM UTC

lkysow wrote: post #591

cletus wrote: post #565

Former Facebooker here. I have some thoughts. IME I find that many people don't have the problems GraphQL is intended to solve. No shade to the author but, as one example, i don't see the word "fragment" mentioned anywhere in this post and fragments are a real issue with GraphQL. Let me explain the problem GraphQL actually solves. FB, as we know, is an incredibly large mobile app, possibly one of the largest in terms…

Is the DB you use open source?

It depends on how you define "DB" in this context. Ex-Facebooker so I this may have changed but I doubt it. It's fairly fundamental.

At the lowest level, data is stored in MySQL so yes, that's open source. Almost nothing user-facing will talk to MySQL directly because you're bypassing all the privacy, scaling, auditing, security, etc. Some legacy systems are on different MySQL instances but we're talking internal systems, not public-facing.

The in-memory graph database on top of that, which I think you're actually referring to, is called TAO [1]. AFAIK, no, it isn't open source.

All of this is very much designed for the type of data Facebook stores and how it's used (eg "12,345 people liked this" is an easy query but listing all the things you liked can be really expensive beyond the most recent likes).

[1]: https://engineering.fb.com/2013/06/25/core-infra/tao-the-pow...

Re: After 6 years, I'm over GraphQL

#603

Post by elux101 » Fri, May 31, 2024, 2:11 AM UTC

another project to take a look at for schema-driven approach to writing backend services and fully code-generated clients: https://github.com/webrpc/webrpc

it's similar to OpenAPI, but its simpler, and cleaner. In fact, you can generate webrpc schema's to OpenAPI and then generate OpenAPI clients.

Re: After 6 years, I'm over GraphQL

#604

Post by gedy » Fri, May 31, 2024, 2:13 AM UTC

devit wrote: post #600

gedy wrote: post #599

Earlier quoted context omitted.

> I think the only reasonable way to use GraphQL is to only allow a set of whitelisted queries That's already how it works, it is not an open ended SQL query. The GraphQL schema is the whitelist.

No, I mean of whitelist of full GraphQL queries with string/number arguments, where you can only run one of the queries in the whitelist, and the client can only choose which query and the string/number values, but not submit an arbitrary query string.

The schema you expose can do that afaik.

Re: After 6 years, I'm over GraphQL

#605

Post by socketcluster » Fri, May 31, 2024, 2:18 AM UTC

This is a great write-up. I was already aware of most of the drawbacks that the author wrote about in the early days of GraphQL... Another category of solutions which was ignored completely is CRUD with field-granularity over WebSockets.

I've built platform which does just that: https://saasufy.com/

This approach has allowed me to create a library of highly generic components which can be composed into surprisingly complex front ends and where all data updates in real time (in a targeted, efficient and scalable way): https://github.com/Saasufy/saasufy-components?tab=readme-ov-...

You can build just about any front end you can imagine just by assembling these components. Almost no code needed. It takes me hours to build web applications which would take weeks or months to build. The real time update features come free. The dev experience is essentially bug free; any 'bugs' you may encounter have clear visual symptoms which can be 'debugged' by observing the HTML DOM.

I'm currently observing people getting hyped up over HTMX and it's kind of funny to realize that developers do actually like the declarative approach... And yet they're going in the wrong direction again. Just as they did with GraphQL.

It would have been impossible to do this with GraphQL because field-granularity/autonomy is essential. GraphQL queries combine different resources and fields together in complex ways and this makes it impossible to efficiently avoid real time update conflicts on the front end.

Re: After 6 years, I'm over GraphQL

#606

Post by RedShift1 » Fri, May 31, 2024, 2:18 AM UTC

damidekronik wrote: post #446

ttfkam wrote: post #443

The only time I think GraphQL works is when it is when the GraphQL schema and resolvers are autogenerated by the underlying data stores. As a ORM layer, I love solutions like Postgraphile and Hasura where they mostly just reflect the structures you've already designed in your database. I also like REST solutions like PostgREST for the same reasons. Then I'm designing my table structure, optionally designing my views…

Postgraphile is great, until you need to debug row level security. Or when you realize you need another tool to make the query type safe.

What troubles have you had with debugging row level security? It has worked very well for me, I've not had issues debugging it. And what do you mean with making a query type safe? Type safety is built in to GraphQL, if you send in the wrong datatype for an input the query will be rejected without even hitting the database.

Re: After 6 years, I'm over GraphQL

#607

Post by hamandcheese » Fri, May 31, 2024, 2:19 AM UTC

RedShift1 wrote: post #593

hamandcheese wrote: post #588

Earlier quoted context omitted.

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…

So GraphQL is bad because you didn't implement authorization, which you should have been doing regardless of the API technology you use?

I am just pointing out that it is easy to make mistakes like this which would be, in this commenters experience, more obvious with a REST API.

In the equivalent REST API you would probably have to go far far out of your way to expose users order information in a reviews API, whereas in graphql that is the default.

In a typical REST application, it is enough to ask "does this user have permission to take this action".

In graphql, the question is rather different. It is "does this user have permission to access this data irrespective of the action they are taking", and you have to both ask that question and answer it correctly for everything in your graph.

Re: After 6 years, I'm over GraphQL

#608

Post by gedy » Fri, May 31, 2024, 2:23 AM UTC

cletus wrote: post #565

Former Facebooker here. I have some thoughts. IME I find that many people don't have the problems GraphQL is intended to solve. No shade to the author but, as one example, i don't see the word "fragment" mentioned anywhere in this post and fragments are a real issue with GraphQL. Let me explain the problem GraphQL actually solves. FB, as we know, is an incredibly large mobile app, possibly one of the largest in terms…

> How I see a bunch of people use GraphQL is as a 1:1 map to a relational model beneath it.

Yeah I've had trouble with some devs misunderstanding this, this seems to be the source of "omg you can run arbitrary queries" (especially if they've never used GraphQL.

You can't do anything that the GraphQL schema doesn't specify - it's not open ended SQL and joins.

Re: After 6 years, I'm over GraphQL

#609

Post by djbusby » Fri, May 31, 2024, 2:26 AM UTC

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…

There is a place for you, somewhere.

I spend loads of time on LoB apps, still rocking Apache prefork to CGI. Does it scale? Sure, to all 3200 users company wide. Everything it's boring. Caching? Never got in the Memcache vs Redis fight later. 10yr after that? We picked Redis for the case where it had proven to kick ass.

Did you know that PHP5.4 apps can still generate profit in 2024?

Re: After 6 years, I'm over GraphQL

#610

Post by cellularmitosis » Fri, May 31, 2024, 2:34 AM UTC

We tried GraphQL for about a year, then switched back to REST, but took the important bits with us: a published API contract (an OpenAPI spec), and code-gen'ed Swift from that spec.

Looking back, it is hard to believe I spent a decade working in shops with no published spec, no code-gen. So many ugly surprises discovered in production, all of which were avoidable. Never again.