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

431–440 of 721 posts

Re: After 6 years, I'm over GraphQL

#431

Post by nfw2 »

doctor_eval wrote: post #131
dgb23 wrote: post #69

One of the major issues I have with GraphQL from the get go is that it introduces it's own syntax instead of using a commonly understood and established _data_ format like JSON or similar. Same problem with Prisma Model definitions and other such things. Please, if you make a new thing and it fits neatly into a data format, use a data format! Let me use all of those well established libraries, schema definitions and…

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?

They are referring to the schema language

Re: After 6 years, I'm over GraphQL

#432

Post by jack_riminton »

burutthrow1234 wrote: post #397
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…

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

Re: After 6 years, I'm over GraphQL

#433

Post by jayd16 »

cess11 wrote: post #276
mattbrewsbytes wrote: post #140

Earlier quoted context omitted.

> RPC and REST are just more straightforward to monitor, log, cache, authorize and debug. REST API's are a proven solution for the problem of other apps, including front-ends, needing data from a data store. Using JSON is much improved over the days of XML and SOAP. Beyond that there haven't been advancements in technology that cause fundamental shifts in that problem space. There have been different opinions about s…

JSON winning over XML is like saying CSV won over MySQL. They aren't equivalent. Much like CSV, JSON isn't particularly standardised and different parsers and writers will do different things in some situations. Usually it doesn't matter, but when it does you're probably in for a lot of pain. If you handle structured data and the structures might change over time, JSON isn't a good fit. Maybe you'll opt for JSON Sche…

Its not JSON over XML. They're saying JSON REST won over _XML and SOAP_.

Re: After 6 years, I'm over GraphQL

#434

Post by apsurd »

GeneralMaximus wrote: post #416
klibertp wrote: post #367

Earlier quoted context omitted.

> idea that a frontend developer would send a ticket to somebody so they can get all the data they need... it's just crazy. For me, what's crazy is that there are "web" developers who can't just add the endpoint they need while working on a frontend feature, or "web" developers who can't just add an element or a page for testing the backend endpoint. What ever happened to full-stack developers? The "frontend" and "ba…

For context: I work on large-scale browser apps that are closer in complexity to something like Linear or Obsidian than to your standard WordPress blog with some forms. E.g I'm currently working on a browser-based GIS tool for the financial sector. I started my career as a full-stack developer, but went all-in on frontend because I felt I was spreading myself too thin. At one point I found that I could choose to be a…

> ... I don't think a single person could build a product like Linear end-to-end without cutting corners.

Cutting corners is a feature. I bet the Linear team is as pained as any, internally, at the tradeoffs they're making.

There is no way to know "what to get right" without going through it. So for 80% of the dev cycle the job is to cut corners to get to the 80/20, rinse and repeat forever.

This isn't against excellence and the dream of a beautiful product experience as your reply seems to convey.

Re: After 6 years, I'm over GraphQL

#435

Post by lcnmrn »

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…

Someone like you made me quit my first job as developer. He implemented a Clojure + GraphQL nightmare.

Re: After 6 years, I'm over GraphQL

#436

Post by patricius »

I will, once again, bring your attention to hashql, which is so pleasant to use. It's so minimal that it is almost more a pattern than a library. Try it out as an alternative to graphql if you are mainly querying a SQL database anyhow (although it can be easily configured to request data from other types of sources.) I don't think it can currently combine results from multiple data sources, but I think it should be within the realm of possible things

https://github.com/porsager/HashQL

Re: After 6 years, I'm over GraphQL

#437

Post by int_19h »

GeneralMaximus wrote: post #416
klibertp wrote: post #367

Earlier quoted context omitted.

> idea that a frontend developer would send a ticket to somebody so they can get all the data they need... it's just crazy. For me, what's crazy is that there are "web" developers who can't just add the endpoint they need while working on a frontend feature, or "web" developers who can't just add an element or a page for testing the backend endpoint. What ever happened to full-stack developers? The "frontend" and "ba…

For context: I work on large-scale browser apps that are closer in complexity to something like Linear or Obsidian than to your standard WordPress blog with some forms. E.g I'm currently working on a browser-based GIS tool for the financial sector. I started my career as a full-stack developer, but went all-in on frontend because I felt I was spreading myself too thin. At one point I found that I could choose to be a…

IMO the fact that being a full-stack dev is so taxing is an indication that the stack as a whole is just way too complex and overengineered. Which is rather obvious from looking at the state of affairs on the frontend side of things. Desktop GUI devs don't usually have those problems.

Re: After 6 years, I'm over GraphQL

#438

Post by arp242 »

hansonkd wrote: post #407
arp242 wrote: post #361

Earlier quoted context omitted.

This is like, an hour per endpoint. For maybe 30 endpoints (high figure for many apps) throughout the lifespan of your application. But let's say 3 hours: you're talking about 90 hours in total, over a period of 2 or more years. It's really not that much. And GraphQL isn't free either; you need to actually implement that. It pervades your entire stack, too – it's not something you can just "put on top of it". I think…

An experience engineer knows that a change that takes hour turns to days when a team is running at scale and needs to have CI approvals etc. Why waste any time? > And GraphQL isn't free either; you need to actually implement that Rest isn't free. You have to actually implement also that and end up with a more limited API. GraphQL libs in Python are equally as complex as the FastAPI etc..

And no one will be spending days working on it, they will work on other things while waiting for code reviews and such.

> GraphQL libs in Python are equally as complex as the FastAPI etc.

You need to account for the fact that anything can query anything, whereas a more traditional REST-type API will have much more limited codepaths.

This starts with just basic database maintenance and indexing, which in many case will be significantly more complex, to all sorts of other problems. This article already enumerates them so I'm not going to repeat them here.

You can't just handwave all of that away with "oh there's a library you can use".

If you think all of that is worth it then that's fine. As with many things it's a trade-off, and a bit of a judgement call too. But please, don't pretend this complexity doesn't exist, and that the trade-off doesn't exist.

Re: After 6 years, I'm over GraphQL

#439

Post by evantbyrne »

GeneralMaximus wrote: post #416
klibertp wrote: post #367

Earlier quoted context omitted.

> idea that a frontend developer would send a ticket to somebody so they can get all the data they need... it's just crazy. For me, what's crazy is that there are "web" developers who can't just add the endpoint they need while working on a frontend feature, or "web" developers who can't just add an element or a page for testing the backend endpoint. What ever happened to full-stack developers? The "frontend" and "ba…

For context: I work on large-scale browser apps that are closer in complexity to something like Linear or Obsidian than to your standard WordPress blog with some forms. E.g I'm currently working on a browser-based GIS tool for the financial sector. I started my career as a full-stack developer, but went all-in on frontend because I felt I was spreading myself too thin. At one point I found that I could choose to be a…

I don't think the claim is that a single developer should be able to build an entire enterprise product, but rather that a single developer should be able to implement the software side of a task end-to-end. The latter is a reasonable expectation when your software is monolithic.

Re: After 6 years, I'm over GraphQL

#440

Post by mirekrusin »

mdaniel wrote: post #353
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…

Nobody is looking at websocket handshakes. What I meant relates to simplicity around recording communication - req+res+duration and notifications, the fact that semantics are familiar and very clear, it's easy to filter/plot/explore it, everybody knows what is happening, where to optimize etc.
Post reply on HN