Earlier quoted context omitted.
Everything works when you have an army of top-flight engineers.
I can name plenty of engineering tasks an army of top engineers has failed at, to the point of negatively impacting the product.
Ok, "most things". ;)
After 6 years, I'm over GraphQL
421–430 of 721 posts
Re: After 6 years, I'm over GraphQL
#422REST is simple and works well with debuggers, logging, caching, auth, request throttling e.t.c
For graphql like needs we use a standard set of props (select, filter, sortBy, limit, offset).
They map to a single sql statement and executed efficiently by PG.
select can be nested properties if we need deeper nesting. Server emits typescript types package for frontend.
It's worked really well so far at our scale. Eng team is fairly productive.
Re: After 6 years, I'm over GraphQL
#423For some reason every person I have worked with that pushed GraphQL seemed sufficiently obsessed with the idea of it that they prioritized its perceived elegance over the product we were trying to build.
In other words, they cared more about ideal ways to access data than the product of that data.
This has so consistently been the case in my personal experiences that I avoid people in hiring interviews that start talking about or try to sell me on why I should switch my stack to GraphQL.
Re: After 6 years, I'm over GraphQL
#424Re: After 6 years, I'm over GraphQL
#425I've read the article and a few of the responses but have never used GraphQL. However I have a question Would it be fair to say that GraphQL is extremely useful for internal-only clients? For example an inhouse data store, query service, test status monitor, etc? So many issues disappear when you aren't concerned about bad-actors and you have _some_ control over both client and server.
> Would it be fair to say that GraphQL is extremely useful for internal-only clients? Compared to what? If you're feeling really safe about the "internal-only" parts, just expose an endpoint to allow SQL (read) queries and you'll get essentially the same thing, especially if your data store already is SQL-like.
And GraphQL has no real benefits over SQL? If so... I'm not sold
Re: After 6 years, I'm over GraphQL
#426Having 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.
Re: After 6 years, I'm over GraphQL
#427I've read the article and a few of the responses but have never used GraphQL. However I have a question Would it be fair to say that GraphQL is extremely useful for internal-only clients? For example an inhouse data store, query service, test status monitor, etc? So many issues disappear when you aren't concerned about bad-actors and you have _some_ control over both client and server.
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
Re: After 6 years, I'm over GraphQL
#42895% of this is specific to Ruby, not GraphQL. I also found ruby-graphql not to be a excellent library in contrast to what the author says. Other implementations (apollo for node, gqlgen for Go) alleviate many of the concerns mentioned in the article, especially when implementing the server with certain principles in mind (always use the data loader pattern, etc).
Re: After 6 years, I'm over GraphQL
#429I 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…
Hmm. I wonder if there is some kind of query builder that can live server-side. That is, capture the flexibility of a query language when developing, and then consolidating that when going into production. Though I guess you can do that with REST too. I'm currently exploring all of this myself. I have a side project in mind that can use a graph db, and I thought a front-end graphql can work well with a graphdb backen…
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 actions" as a mechanism that is very similar to that. Engineers can author what looks, ostensibly, like frontend code, merely splitting the "client" side and "server" side into separate annotated functions, and the React bundler splits those into client code, a server API handler, and transforms the client function call into the annotated server function into an HTTP API call.
Having used it for a bit it's really nice, and it doesn't result in yielding so much control to a very complex technology stack (GraphQL batchers, resolvers, etc. etc.)
Re: After 6 years, I'm over GraphQL
#430Why, after 6 years, I'm over increased complexity for marginal benefit. Sounds like most things developed and promoted by FANG