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

351–360 of 721 posts

Re: After 6 years, I'm over GraphQL

#351

Post by hot_gril »

asdasdsddd wrote: post #346
hot_gril wrote: post #338

Earlier quoted context omitted.

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

Maybe. Can that one army fix GraphQL for all the teams in the company? Cause I've seen things work that way, but I've also seen tools that are pitched as "maintained in one place for everyone" but are actually a complexity burden on every single team, especially if/when its usage changes.

Re: After 6 years, I'm over GraphQL

#352

Post by mst »

darthmallrat wrote: post #184
mst wrote: post #98

Earlier quoted context omitted.

WiredTiger was kinda Mongo's InnoDB and has made "your data will actually still be there later" rather more true than it used to be. I think the key thing is that people using MySQL were having trouble with deep data and found MongoDB's document oriented approach much easier, but these days people are tending to start with PostgreSQL, which can handle that nicely. (MySQL/MariaDB are far better than they used to be as…

> the license change was a shame ... avoid being killed by AWS That sounds similar to Elastic's story. Did MongoDB go through that as well?

MongoDB were the first major player to do that (that I know of, at least) back in 2018 - see https://www.mongodb.com/legal/licensing/server-side-public-l... or hit google for a plethora of people being angry about it.

Re: After 6 years, I'm over GraphQL

#353

Post by mdaniel »

mirekrusin wrote: post #297

Just use jsonrpc over websockets - you’ll have same semantics as function calling in your programming language, type it if you’re using static type aware lang and have happy life. It’s easy to optimise, refactor, trace/debug, use (same as using library with async functions) etc.

> trace/debug,

for whom? when was the last successful experience you had of telling a product manager to open their devtools and find the row in a websocket handshake showing the actual payload that went over the wire for the timeframe in question?

I am open to the fact that maybe there are super advanced organizations which have replay debuggers or Sentry or whatever that remove the need to utter the dreaded phrase "can you open the devtools?" but I regrettably haven't worked in one

Re: After 6 years, I'm over GraphQL

#354

Post by chuckadams »

RVuRnvbM2e wrote: post #292
chuckadams wrote: post #277

Earlier quoted context omitted.

The entire point of graphql servers is that they're basically ORMs (or use an underlying ORM) that turn complex nesting into a single query's worth of joins. It won't beat hand-crafted sql from an expert, but if that's your preferred approach, debates on the relative merits of different query frameworks are all academic to you anyway.

I've never seen this kind of graphql server implementation that can automatically boil down a complex nested query to sensible SQL. It sounds like the best of both worlds. Do you have links?

Symfony API Platform boils to ORM-generated SQL via Doctrine, which is verbose, but not overly clever. So the only link I could give you there would be to the Doctrine query builder docs (I won't subject you to API Platform's docs). I imagine a more sophisticated graphql dialect like what Prisma supports can generate some pretty gnarly sql, but that's ORMs for you. But exposing your data model directly through graphql is also not recommended, same with REST APIs (I can't claim the high ground, my biggest graphql project exposes models directly. The tradeoff was worth it in this case). So in the end you're writing custom controllers/resolvers anyway, and field resolvers are where graphql really starts to shine.

Re: After 6 years, I'm over GraphQL

#355

Post by hansonkd »

randomdata wrote: post #341
hansonkd wrote: post #324

Earlier quoted context omitted.

? 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.

Because exposing your Database to the outside world is asinine. GQL sits between letting the frontend query semi-customizable queries and not having any customizability to select related resources.

Re: After 6 years, I'm over GraphQL

#356

Post by arp242 »

datavirtue wrote: post #226
ComputerGuru wrote: post #188

Earlier quoted context omitted.

> With internal REST for companies I have seen so many single page specific endpoints. Gross. Hardly gross. It is what it is and it’s universal across the domain. I bet Windows has internal APIs or even external ones that were created just for one page/widget/dialog of one app. It’s the nature of things at times.

It's analogous to a specific method in code. No idea why people go nuts over this.

Some people treat codebases as an art project rather than engineering project.

I think this explains about three quarters of all engineering problems I've seen in corporate context, give or take.

Re: After 6 years, I'm over GraphQL

#357

Post by mdaniel »

eatsyourtacos wrote: post #230

I only have one experience with a client using GraphQL and it was horrendous . My biggest complain is there seemed to be no way to just to query all fields. I know that is intentional and the point of GraphQL.. but they should support something for the server side to enable this. Maybe they have over the years, I don't know. But my experience was during the implementation phase the client kept adding new fields that…

I am for sure no graphql ninja but I believe what you are describing is achievable via the introspection call, which the sibling comment hints at when mentioning the schema but I'm saying that's a runtime call just like any other and thus no "reading" required. I do think that introspection stuff is opt-in because some shops consider it an information leak vector, but for dev/staging I think it's a perfectly fine tradeoff

https://graphql.org/learn/introspection/

Re: After 6 years, I'm over GraphQL

#358

Post by ethbr1 »

blowski wrote: post #319
hansonkd wrote: post #254

Earlier quoted context omitted.

Not nearly as often with Graphql and happens less and less as your backend and data models stabilizes. Most of our frontend features now don't have backend changes and we were able to increase the ratio of frontend to backend devs.

My experience is that the problem is avoided in theory, but not in practice. Making a good API on a large system with many clients is always difficult. GraphQL makes it easier in theory, but if you have average level devs working on it, they’ll make a bigger mess than if they use simple REST. The latter will still be complex, but at least it’s easier to have observability.

Aka never underestimate the power of additional complexity to drive bad use, absent familiarity.

Re: After 6 years, I'm over GraphQL

#359

Post by realusername »

hansonkd wrote: post #337
realusername wrote: post #329

Earlier quoted context omitted.

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.

With REST, the endpoints are team based if you have even a semi-competent CTO so you never have this problem, you just check who owns the controller and that's it.

With GQL though, good luck retracing who owns what field and what does it affect if you change the definition of what it returns, especially that you you are not even using it on the same language.

Bonus points here if you are managing something outside of your control like a mobile app.

Re: After 6 years, I'm over GraphQL

#360

Post by gedy »

powersurge360 wrote: post #331

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

Sounds like you are describing the Backend For Frontend (BFF) pattern and I also quite like it.
Post reply on HN