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

331–340 of 721 posts

Re: After 6 years, I'm over GraphQL

#331

Post by powersurge360 »

I think GraphQL works its best magic when you are building your own unified data access layer for a backend. Your individual services can be backed by Postgres or Mongo or an in memory database, whatever, doesn’t matter. And from there a backend queries that, translates the data into a RESTful one, and passes it along to a front end Backends-for-Frontend style.

In this way services get freedom to define their stack while still neatly fitting into the suite of services, products get a tidy interface from which to query everything, and because the GraphQL consumer is more akin to a regular database consumer, the database muscle memory kicks back in.

I’ve also grown to prefer bespoke backends for each client over a super backend that tries to anticipate all of the needs of all the clients. It just opens too many holes and what it buys in versatility for the client author it also gives to the exploit author.

Re: After 6 years, I'm over GraphQL

#332

Post by bryanrasmussen »

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…

>And both these projects had clear signs of "learning-on-the-go" with loads of bad practices

I think two projects having loads of bad practices is too small a dataset to really assume anything, you sort of need to see widespread "bad practices" in the tech to be able to determine that the bad practice is actually the norm practice and there is perhaps a flaw in the tech that encourages that norm.

Re: After 6 years, I'm over GraphQL

#333

Post by hansonkd »

BiteCode_dev wrote: post #326
hansonkd wrote: post #211

Earlier quoted context omitted.

This is Wrong. GraphQL only exposes what you ask it to. There are plenty of pagination plugins for GraphQL frameworks just as there are plugins to REST framework. GraphQL can be restrictive as REST if you want it to be. The point is GraphQL can be "as restrictive" as REST, but if you want to enable more efficient queries by knowing all the data that the frontend is requesting, you can. But the opposite isn't true of…

But then what's the point of using it if it's to get the limitation of REST? You get something more complex, more expensive to maintain, consuming more resources, and configure it to basically be REST with extra steps.

> more complex, more expensive to maintain, consuming more resources,

Idk. Strawberry GQL and most GQL libraries are maybe equally as complex as the REST libraries for the same language. Strawberry and FastAPI I would say are equal in complexity and configuration.

It would be hard for me to say GQL is more expensive or consumes more resources. Opposite of the purpose and most uses of GQL.

Re: After 6 years, I'm over GraphQL

#334

Post by BiteCode_dev »

barrkel wrote: post #171
BiteCode_dev wrote: post #106

Earlier quoted context omitted.

Ah but that's the beauty of GraphQL, a query can actually fetch data from several systems: the db, the cache, the search engine, etc. It's all abstracted away. But let's say you have a timeout, and they have a retry, then suddenly, your server is now spammed by all the clients retry again and again a query that worked a week ago, but today is too heavy because of a tiny change nobody noticed. And even if it's not the…

To be clear, the main thing that's abstracted away are server round-trips and client-side joins. REST APIs can fetch data from different systems too.

Sure but queries are crafted in the client, that may know nothing about this, while a rest api, the requests are restricted and the queries are more likely under control of the server, which mean the backend will likely decide what fetches what and when.

It takes a lot of work to actually ensure all possible combinations of graphql params hit exactly what you want in the backend, and it's easy to mess with it in the frontend.

Re: After 6 years, I'm over GraphQL

#335

Post by emlos »

mcdonje wrote: post #281

>1. Write a succinct human readable TypeSpec schema >2. Generate an OpenAPI YAML spec from it Why? Isn't YAML human readable?

Yes, but OpenAPI specs tend to be verbose and hard to navigate. Remembering the exact anchor for the type you defined can be difficult, finding the reference can be harder, and you probably won't get any help from an IDE.

I tend to prefer just writing the yaml, but I can also see why these kinds of tools crop up to mitigate the need to remember all the details.

Re: After 6 years, I'm over GraphQL

#336

Post by shepherdjerred »

travellingprog wrote: post #128
probabletrain wrote: post #85

What about the benefits/drawbacks of the graphql client in a web app, e.g. Apollo [1], Relay [2]? You get a client-side normalized cache of all data fetched by any query. Here's a handful of benefits: - If data already exists in cache, a query will return that data instead of making a network request. - Everything that has a data dependency on something in the cache will automatically update when the data is updated,…

TanStack Query (fka React Query) is a REST client similar to Apollo Client, with many of the same pros and cons: https://tanstack.com/query/latest/docs/framework/react/overv...

TanStack Query isn't a REST client. It's a generic data fetching framework.

You could use TanStack query with GraphQL, Apollo, REST, or any other data source.

Re: After 6 years, I'm over GraphQL

#337

Post by hansonkd »

realusername wrote: post #329
hansonkd wrote: post #266

Earlier quoted context omitted.

> It ensures that the endpoints are maintainable and future-proof when people are working on different features How does GQL prohibit this? It encourages it by focusing on 1 stable API for everyone instead of a custom API endpoint for each case.

I don't think it would hold true for very long, devs will have specific cases which will pile into the definitions. That's why GraphQL examples usually focus on querying data from users and not how you are going to manage 10 different views of the same data.

> pile into the definitions

That is how REST works but is the opposite of the way GQL works.

You don't pile into existing defintions but extend the current definitions out. A team needing new data doesn't affect the consumption of other teams. which is not the case of REST where if one team needs to change a REST endpoint to return different shape of data, they have to verify the new shape with other teams.

Re: After 6 years, I'm over GraphQL

#338

Post by hot_gril »

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 enough reason. Finally it's not cool anymore, but there will be another thing.

Re: After 6 years, I'm over GraphQL

#339

Post by hansonkd »

discreteevent wrote: post #322
hansonkd wrote: post #300

Earlier quoted context omitted.

Typically libraries use a Dataloader + ORM to implement this which gets you pretty far, outside of that some libs like Strawberry with automatically optimize your queries for you if you return Django ORM Querysets. Any query you were going to build and serve with Rest can be made with these two methods or even a raw dataloader and manual SQL string.

The inventors of GraphQL did not intend it to be mapped directly to a database. "That would be one way to implement the system in a DB-centric way. However we believe that intermediate application code is pretty critical to any GraphQL implementation." [1] "GraphQL is a client-server dance that needs server-side capabilities, not just CRUD semantics." [2] [1] https://news.ycombinator.com/item?id=9879870 [2] https://n…

The Language Libs like Strawberry implement what he is describing by intermediate application code. It doesn't map directly to a database.

GQL implementations don't map to the database but to application code.

Post reply on HN