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

701–710 of 721 posts

Re: After 6 years, I'm over GraphQL

#701

Post by belter »

ForHackernews wrote: post #476
burutthrow1234 wrote: post #397

Earlier quoted context omitted.

GraphQL absolutely feels like a technological solution to an organizational problem. What if your front-end team wants to write crazy queries and your back-end team wants to build their resume doing Real Engineering, but what you actually need is just a CRUD app? Now your backend devs aren't bored writing "business logic" and your front end devs aren't bored waiting for your backend devs. You have a new class of insc…

Sounds good to me. I'll do GraphQL for $250k.

Plenty of SAP and COBOL around, to make more money, and feel miserable at the same time :-)

Re: After 6 years, I'm over GraphQL

#702

Post by belter »

jack_riminton wrote: post #432
burutthrow1234 wrote: post #397

Earlier quoted context omitted.

GraphQL absolutely feels like a technological solution to an organizational problem. What if your front-end team wants to write crazy queries and your back-end team wants to build their resume doing Real Engineering, but what you actually need is just a CRUD app? Now your backend devs aren't bored writing "business logic" and your front end devs aren't bored waiting for your backend devs. You have a new class of insc…

Yep, Conway’s Law: “ Any organization that designs a system will inevitably produce a design that mirrors the organization's communication structure. “ Your point about Resumé Driven Development, together with the dividing wall between front and backends is why FE frameworks have got so hideously and needlessly complex imo

In other words...Once in a while a new generation of software developers champions frameworks that not only repeat historical mistakes, but also systematically dismiss the proven wisdom of older developers. Must be that experience ages out like old code...

Re: After 6 years, I'm over GraphQL

#703

Post by LudwigNagasena »

torginus wrote: post #691
sodapopcan wrote: post #484

Earlier quoted context omitted.

This was my experience. We were forced to use it in a project where we controlled the entire stack. It was so much extract work just to serve data from a backend we had full control over. I don't dislike it but I feel like it's far more of a time-and-place technology than most that people just default to using in any old situation. I'm sure some have used it successfully in a similar scenario—we certainly weren't exa…

Why does Facebook keep pumping out 21st century moral equivalents of UML and OOP design patterns - trendy technological ideas that are often considered the gateway to writing 'professional' code, but end up being overengineered boilerplate nobody actually needs. GraphQL is one, Redux is another.

Few companies operate on a scale of Facebook.

Re: After 6 years, I'm over GraphQL

#704

Post by burutthrow1234 »

torginus wrote: post #691
sodapopcan wrote: post #484

Earlier quoted context omitted.

This was my experience. We were forced to use it in a project where we controlled the entire stack. It was so much extract work just to serve data from a backend we had full control over. I don't dislike it but I feel like it's far more of a time-and-place technology than most that people just default to using in any old situation. I'm sure some have used it successfully in a similar scenario—we certainly weren't exa…

Why does Facebook keep pumping out 21st century moral equivalents of UML and OOP design patterns - trendy technological ideas that are often considered the gateway to writing 'professional' code, but end up being overengineered boilerplate nobody actually needs. GraphQL is one, Redux is another.

GraphQL makes sense in the narrow context of "you have a high latency end-user and you're pulling in deeply nested social graph data". It didn't need to be a general purpose framework, but you don't get to start your own company and talk at conventions about the clever API design you did at Facebook for Facebook-only problems. The incentives are for (a certain type of) developers to act like this solution is a panacea and sell it as a revolutionary new architecture.

Re: After 6 years, I'm over GraphQL

#705

Post by williamdclt »

pjmlp wrote: post #113
williamdclt wrote: post #75

Earlier quoted context omitted.

I don't interact with that many SaaS products, but I've never seen that

If you want to be pedantic, some do offer REST or GROQ as well, which aren't much of an alternative anyway.

how is that pedantic? I assumed you were complaining about SaaS not offering REST (I don't even know what GROQ is) but it seems you're not okay with it either: what would you want then?

Re: After 6 years, I'm over GraphQL

#706

Post by serpix »

RHSeeger wrote: post #534
serpix wrote: post #102

Earlier quoted context omitted.

Then we just come back full round trip to REST where the backend clearly defines what is allowed and what is returned. So using GraphQL it is unnecessary complicated to safeguard against a caller querying for all of the data and then some. For example the caller queries nested structures ad infinitum possibly even triggering a recursive loop that wakes up somebody at 3am.

But GraphQL doesn't allow for infinitely nested queries; the query itself has to include as much depth as it wants in the response. > Then we just come back full round trip to REST Except that GraphQL allows the back end to define the full set of fields that are available, and the front end can ask for some subset of that. This allows for less load; both on the network and on what the back end needs to fetch data for…

You are correct and I agree with you. GraphQL can be used effectively like this and I've seen one example where GraphQL is used like this. New endpoint can be defined very quickly and it is essentially like a REST API with the possibility of the client specifying what data it wants back (as you described).

The other extreme end example is to expose by default the entire data model (PostGraphile) and then getting lost in the customisation and authorisation.

Re: After 6 years, I'm over GraphQL

#707

Post by GreenWatermelon »

ethagnawl wrote: post #500
jack_riminton wrote: post #442

Earlier quoted context omitted.

This is why the Rails community should be applauded in my book, for their dogged determination that we should keep it a “one person” framework. Yes it may not be as performant, type safe or flashy on the front end but my god it’s productive. At my startup there are 7 devs who can all do tickets across the stack and as we grow I think it would be good if we could resist the pressure to silo and specialize

> but my god it’s productive. It really is. Regrettably, I've drifted away from it in large part because of client requirements for more "modern" and "maintainable" solutions (e.g. Python or Node; I'll take Python every time, thanks). Django comes very close in terms of productivity (and is better in some ways: auth, admin, etc.) but the Rails CLI, generators and community (not sure if this is still relevant) give it…

There's no modern successor to Rails because Rails itself os still modern and very much up to date. The recent introduction of Stimulus allows to implement a SPA completely on rails (if they wanted) with the same simplicity present everywhere else in the framework.

Re: After 6 years, I'm over GraphQL

#708

Post by hamandcheese »

fennecfoxy wrote: post #655
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…

>Now every user can inspect all orders of every other user, if that user has left a review. Lmao that's just bad development, bad testing and the exact same thing can happen when using rest. "The dev wrote code and forgot to take permissions into account" happens to everyone. And unlike rest, a properly written schema helps ensure they mostly do the right thing - even without strict permissions check, it should be ob…

In practice, there are innumerable paths one can take through a complicated graph, and it is not reasonable or possible to test them all.

The cure is, like you say, writing a proper resolver. This form of permissions error most frequently happens when there is not a dedicated resolver (graphql-ruby, for example, makes it trivial to make a connection without a dedicated resolver).

I don't think this is as easy of a mistake to make with a typical REST application. In no normal universe would you return orders data in a reviews API, and the mistake would be much more obvious during development since you don't have to explicitly select the data you fetch from a rest API (so you are more likely to notice the extra information).

Whereas during development in graphql, the permissions error would be hidden because you probably would not select extra data for no reason.

Re: After 6 years, I'm over GraphQL

#709

Post by danielheath »

ttfkam wrote: post #668
RHSeeger wrote: post #543

Earlier quoted context omitted.

But as people noted, it's not the "can this get the data" unit testing that's a problem here. It's the performance issues. > I can send a GraphiQL URL to most junior devs with little to no SQL experience, and they'll get data to their UI with less drama But that's like giving direct (read) database access to someone that was taught the syntax of SQL but not the performance implications of the different types of queri…

Hasura and Postgraphile are quite performant. No complaints there. And you can both put queries on an allow list, control max query depth, and/or throttle on query cost.

> put queries on an allow list, control max query depth, and/or throttle on query cost.

All of which are features which give you some way to respond to the performance issues you avoid by planning your API up-front.

Re: After 6 years, I'm over GraphQL

#710

Post by janmatejka »

hosh wrote: post #393
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…

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…

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

Like a stored function in postgresql?

https://www.postgresql.org/docs/current/xfunc-sql.html

Post reply on HN