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

341–350 of 721 posts

Re: After 6 years, I'm over GraphQL

#341

Post by randomdata »

hansonkd wrote: post #324
randomdata wrote: post #321

Earlier quoted context omitted.

It doesn't. That's literally what GraphQL was designed for: To provide a resolver that sits between high latency clients and all of the various REST/RPC services in order to roll up all of the requests at datacenter speeds into one in order to overcome the latency issues. But you still need all of the various single page REST/RPC endpoints to make use of GraphQL as it is intended. Some developers out there skip the R…

? why do you need a REST endpoint with GraphQL? Nearly every language has a GraphQL engine that integrated directly with the database and exposed functions as GQL directly without REST at all.

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.

Re: After 6 years, I'm over GraphQL

#343

Post by derekperkins »

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

Huge fans of Buf Connect. We run vanilla gRPC servers on the backend and have a typed experience through to the frontend

Re: After 6 years, I'm over GraphQL

#344

Post by edude03 »

Despite all of these things ringing true for me as well at the last few companies/projects I worked at that used graphql, I will say that like everything in tech, there are trade offs, but if the tool generally solves the problem you have well, you'll be motivated to find solutions to the additional problems you have - which often means the argument actually comes down to who is more passionate about the particular tech.

One example that stood out to me though:

> GraphQL discourages breaking changes and provides no tools to deal with them.

GraphQL the standard doesn't provide tools no, but I've been very successful using Apollo Studio to solve this as (in my experience) the workflow maps to how you generally develop applications:

1) agree on some schema 2) make a (Apollo studio) "branch" with the schema change 3) mobile & backend devs (typically) code gen the objects they need for the schema 4) backend dev deploys a preview branch of their implementation, mobile dev points the client to it 5) test it, merge it, publish the schema on the main "branch" - deal with the breaking changes if Apollo warns you of them.

So maybe you can accomplish this with other tools, and maybe it's not fair to compare "the standard" to a particular tool, but I usually say I stick to gql (where appropriate) because there is a tool for it that works so well for the problem(s) I'm typically solving.

Re: After 6 years, I'm over GraphQL

#345

Post by purge »

dventimihasura wrote: post #290
mst wrote: post #225

Earlier quoted context omitted.

postgraphile does look like it'll handle basic cases pretty nicely but I've gone through the docs and didn't find anything like an explanation of what SQL queries it ends up mapping to - do you happen to know if there's one I missed, or a list of examples of GraphQL + corresponding SQL, or something?

PostGraphile compiles GraphQL directly to SQL. The SQL is "custom" in that it's specific to the GraphQL operation, though naturally it does follow rules. For example, Hasura does the same thing, and among the rules that it follows is that it uses `LEFT LATERAL JOIN` between tables (at least, on PostgreSQL). Full disclosure, I work for Hasura, so I'm not super familiar with the style of SQL PostGraphile generates but…

postgraphile v5 has significantly improved query generation (https://postgraphile.org/postgraphile/next/) since moving to grafast (https://grafast.org/grafast/)

Re: After 6 years, I'm over GraphQL

#346

Post by asdasdsddd »

hot_gril wrote: post #338
lpapez wrote: post #25

Kudos to the author for reevaluating his opinion and changing heart on a technology he admits to have championed before. IMO GraphQL is a technological dead end in much the same way as Mongo is. They were both conceived to solve a perceived problem with tools widely adopted at the time, but ended up with something which is even worse, while the tools they were trying to replace rapidly matured and improved. Today Ope…

People need to stop judging the viability of something based on how satisfying it feels to use it in a toy project. When time is money, you'll see what really works. At least GraphQL supposedly works for Facebook, and I tried it out before deciding it wasn't a default. I never even bothered with MongoDB. I've had to repeatedly veto using both in projects, cause someone thought it'd be cool and thought that was a good…

GraphQL works when you have an army of engineers that are able to solve all the perf issues

Re: After 6 years, I'm over GraphQL

#347

Post by mst »

dventimihasura wrote: post #290
mst wrote: post #225

Earlier quoted context omitted.

postgraphile does look like it'll handle basic cases pretty nicely but I've gone through the docs and didn't find anything like an explanation of what SQL queries it ends up mapping to - do you happen to know if there's one I missed, or a list of examples of GraphQL + corresponding SQL, or something?

PostGraphile compiles GraphQL directly to SQL. The SQL is "custom" in that it's specific to the GraphQL operation, though naturally it does follow rules. For example, Hasura does the same thing, and among the rules that it follows is that it uses `LEFT LATERAL JOIN` between tables (at least, on PostgreSQL). Full disclosure, I work for Hasura, so I'm not super familiar with the style of SQL PostGraphile generates but…

> PostGraphile compiles GraphQL directly to SQL. The SQL is "custom" in that it's specific to the GraphQL operation

Yes, that's why I said GraphQL and -corresponding- SQL, I was hoping to find something that showed me the SQL for each of half a dozen or a dozen examples ... though the debug option there will let me point the out-of-the-box CLI at a pre-existing database and have a look at as many examples as I like, so that's pretty close to what I was looking for.

Would also be interested to see a bunch of examples of what Hasura generates if you have those to hand (I'm going to poke through the Hasura Community Edition docs but if you have the specific FM to R handy ... :)

Re: After 6 years, I'm over GraphQL

#348

Post by mdaniel »

Izkata wrote: post #163
doctor_eval wrote: post #131

Earlier quoted context omitted.

What do you mean? Both GraphQL queries and results are JSON. The query expression is just a json string. Are you referring to the schema language?

From https://graphql.org/learn/queries/ This isn't even close to valid json: { empireHero: hero(episode: EMPIRE) { name } jediHero: hero(episode: JEDI) { name } }

and I strongly agree with GP because those arguments https://graphql.org/learn/schema/#arguments> can get to be insaneo with anything other than simplistic "episode: EMPIRE"; I regrettably can't link directly to it but https://docs.github.com/en/graphql/reference/objects#:~:text... shows that stuff can start to be more than the interior field selection, to say nothing of schemas that define complex typed arguments e.g.

  type Starship {
    id: ID!
    name: String!
  }
  type CaptainQuery {
    captains(starshipFilter: [Starship!]): [Starship]
  }

  # leading to
  {
    captains(starshipFilter: [{name: "Alpha"},{id: "cafebabe"}]) { id }
  }
which I recognize is most often fixed via variables but when the hello-world examples call it out, something has gone awry https://docs.github.com/en/graphql/guides/forming-calls-with...

Re: After 6 years, I'm over GraphQL

#349

Post by throwup238 »

bunderbunder wrote: post #327
hansonkd wrote: post #245

Earlier quoted context omitted.

Typically the endpoints clients are multiple frontend developers. If the frontend is blocked for every page they need waiting on the backend to expose data that massively increases the costs of features and reduces the time for delivery.

This sounds like more of an org chart problem or a value chain management problem than a technical problem.

That's why we have Conway's law.

Re: After 6 years, I'm over GraphQL

#350

Post by hinkley »

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…

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 two qualities in common: work stealing and back pressure. Without back pressure there is nothing to stop the project from running off a cliff.

Post reply on HN