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

511–520 of 721 posts

Re: After 6 years, I'm over GraphQL

#511

Post by Onawa »

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…

EdgeDB? Graph database built on top of Postgres so you can do row-based auth as well.

https://www.edgedb.com/blog/edgedb-5-introducing-passwordles...

Re: After 6 years, I'm over GraphQL

#512

Post by vdfs »

awongh wrote: post #478
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…

I’ve only been a consumer of a GraphQL API, so I don’t know what it’s like to maintain, but I mostly enjoyed using it. Of course the documentation on some kinds of query syntax was too sparse, (this is for Shopify) but I could see how it might be nice for certain kinds of cases. If you run a platform it might be a good option to offer in your API. For shopify afaik there are equivalent calls in both REST and graphql…

> equivalent calls in both REST and graphql so you have options.

It's not that simple, new features are add to GraphQL only, some other things are REST only,some APIs work differently (like product search by title, in REST it have to be an exact match, in GQL it can be partial match)

Re: After 6 years, I'm over GraphQL

#513

Post by vbezhenar »

eadmund wrote: post #471
hansonkd wrote: post #231

Earlier quoted context omitted.

I guess depending on the context of a simple app one level could be viewed as far. Any more levels and you have now reinvented GraphQL

> Any more levels and you have now reinvented GraphQL Sure, but reinventing the wheel can be good, particularly when the existing wheel technology is oblong, lumpy and constructed of stone and cheese. I’m just bitter than GraphQL endpoints return 200 on errors. If you’re returning 200 on errors, then you’re not really doing HTTP; you’re just using HTTP as a substrate for some other protocol, in which case you might a…

> you’re just using HTTP as a substrate for some other protocol, in which case you might as well just open a port and serve that protocol directly and not pretend to be HTTP.

Browser does not allow to access any ports with any protocols.

Often intermediate software gets in the way as well. For example with Kubernetes it's trivial to expose HTTP service using Ingress and it's not trivial to expose other protocols.

Another HTTP plus is that it's trivially secured by TLS and every developer knows API for that. Using TLS for your own protocol or QUIC is absolutely not trivial and probably more like arcane knowledge.

Re: After 6 years, I'm over GraphQL

#514

Post by joegibbs »

nfw2 wrote: post #453
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…

Whitelisting the queries that clients can use in prod actually doesn't seem like a bad option to avoid a lot of these security issues, assuming you control the clients

Yeah but then you’ve basically just remade REST, but the queries are stored in the frontend instead.

Re: After 6 years, I'm over GraphQL

#515

Post by albertgoeswoof »

pas wrote: post #495
awongh wrote: post #478

Earlier quoted context omitted.

I’ve only been a consumer of a GraphQL API, so I don’t know what it’s like to maintain, but I mostly enjoyed using it. Of course the documentation on some kinds of query syntax was too sparse, (this is for Shopify) but I could see how it might be nice for certain kinds of cases. If you run a platform it might be a good option to offer in your API. For shopify afaik there are equivalent calls in both REST and graphql…

Can you elaborate on lack of syntax docs? As far as I understand one of the big big huugge benefits of GraphQL is that you get the strongly typed schema via the introspection query, so you can build queries with some confidence, that as long as the schema (version) is the same it should be syntactically okay. What did Spotify do compared to this?

This is one of the problems with graphql, there are no docs because the schema is all you need. But that assumes the schema is logical and consistent, which it rarely is.

It also means you need to be an expert in the tooling to figure it out, so just dropping in to a graphql api is so frustrating compared to plain old rest

Re: After 6 years, I'm over GraphQL

#516

Post by koito17 »

culi wrote: post #470
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…

Just a couple nitpicks * openapi was basically nonexistent when GQL came out. It certainly wasn't "the tool they were trying to replace" * Postgres and GQL are not in any way mutually exclusive * Today, openapi is still tiny compared to GQL. At least as measured by StackOverflow question tags: https://trends.stackoverflow.co/?tags=graphql,openapi,soap,m...

Stack Overflow trends isn't really a good metric, but setting that aside, you need to sum the time series for Swagger and OpenAPI. There's still plenty of people who call OpenAPI 3.0 "Swagger". And strictly speaking, Swagger is "OpenAPI 2.0".

Re: After 6 years, I'm over GraphQL

#517

Post by feoren »

culi wrote: post #456
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 '…

GraphQL is meant to be used along side a very smart client-side cacheing library like Apollo The best practice for GQL is to make frequent, small, queries (Apollo handles batching them) throughout your application. Apollo won't do any extra work to fetch new fields if they're already in the cache Not to be that person because I understand there's always edge cases, but in general with GQL if your queries are highly c…

"Make frequent small queries and let a smart cache do the right thing every time" sounds like "make a perpetual motion machine". It just sounds like a fundamentally difficult problem with unavoidable tradeoffs. I admit I don't know the details of Apollo, but I find it hard to believe that a caching layer magically solves everything without introducing very gnarly bugs. A cache layer makes concurrent editing harder, for one.

Re: After 6 years, I'm over GraphQL

#518

Post by mc10 »

int_19h wrote: post #437
GeneralMaximus wrote: post #416

Earlier quoted context omitted.

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.

I don’t think this is a fair conclusion; web development is harder than desktop GUI development for various reasons.

For one, clients (mobile, desktop) are drastically different with all sorts of downstream implications:

- Differing screen size requiring responsive design

- Internet speeds magnitudes different

- Intermittent internet

- Uneven feature support due to different versions of browsers

- Everything needs to be JS at the end of the day

Desktop apps generally don’t have to worry about any of these issues.

Also, desktop GUI frameworks are typically either fragmented (one per OS) or don’t look OS-native.

Re: After 6 years, I'm over GraphQL

#519

Post by rbalicki »

nfw2 wrote: post #453
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…

Whitelisting the queries that clients can use in prod actually doesn't seem like a bad option to avoid a lot of these security issues, assuming you control the clients

This solution works very well, and I’m surprised that others on this thread do not take advantage of persisted queries. Yes, it’s recreating REST, except that you don’t need to version endpoints, etc. The source of truth is the front end repo. That’s the point!

Use of persisted queries also addresses the article’s concerns about DDOS.

Re: After 6 years, I'm over GraphQL

#520

Post by bigstrat2003 »

svachalek wrote: post #296
cess11 wrote: post #276

Earlier quoted context omitted.

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…

What's missing in ECMA-404? Never had a problem with JSON parsers or writers, using it all day every day for decades. It's crappy in some ways, sure, like lack of full floating point support, but standardization is not an issue. XML is mostly already lost on the current generation of developers though, much less future developers. Protobuf and cousins generally do typed interchange more efficiently with less complexi…

Frankly, if a developer can't figure out XML then they aren't worth their salary. Age is no excuse here; as a developer your job involves figuring out how to work with technology you haven't used before.
Post reply on HN