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

681–690 of 721 posts

Re: After 6 years, I'm over GraphQL

#681

Post by int_19h »

neonsunset wrote: post #596
int_19h wrote: post #568

Earlier quoted context omitted.

It was enough of a problem that Microsoft eventually saw it fit to come up with the official replacement.

It was made so that the ecosystem could continue to evolve, particularly in terms of performance and security hardening . But okay, what was the reason System.Text.Json introduced in your opinion? What were the egregious problems with Newtonsoft.Json?

In my opinion, the single biggest issue with Newtonsoft.Json is https://github.com/JamesNK/Newtonsoft.Json/issues/862.

Sure, you can disable it, but the fact that it is opt-out to begin with - i.e. that by default the parser will try to creatively interpret any string it sees in JSON input and convert in a locale-specific manner that also quietly loses data - is, frankly, insane through and through. I've personally run into this issue many times in existing code - it usually happens when people first start using the library and just never run into any inputs that would trigger this behavior while testing. Then once that code is shipped, someone somewhere just happens to have the data that triggers it.

And if you look at the comments to that issue, there are numerous mentions from other GitHub repos due to bugs it caused for them, including some Microsoft projects.

The cherry on that cake was author's response indicating that he doesn't even understand why this design is problematic in the first place: "I like what it does, I have no plans to change it, and I would do it again if given the chance." I wouldn't trust any parser written with this kind of attitude.

Re: After 6 years, I'm over GraphQL

#684

Post by groone »

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…

Entity Framework Core has got you covered! Writing some LINQ and returning data in Aspnet Core API takes no time at all.

Re: After 6 years, I'm over GraphQL

#685

Post by shados »

A lot of the points in the articles are issues anywhere, it just depends on how well they are understood in the context and how mature the tooling is. Eg: rate limiting in REST is rarely problematic because we have no end of WAFs and gateways and circuit breaker libraries that understand REST very well.

It's very true that a few years ago the gap was there, and people implementing GQL had to solve all these problems without access to these mature solutions.

But these days, they're mostly solved problems. Authorization by type that propagate through the graph is pretty simple. Rate limiting and complexity limits on queries is often built in the frameworks. Query parsing is solved with persisted query all the major frameworks have as first class citizen. Performance: lots of GQL caching solutions out there, and the "multi threaded by default" model used by most frameworks helps a lot.

Etc etc etc.

I jumped companies a lot, did both. For a while I too thought GQL was redundant, then went back to a more classic world after a successful GQL implementation. I had forgotten how many problems were solved, especially organizational and people communication issues, through GQL. And so we're moving to GQL again.

Someone in the comment mentioned GQL is a tech solution for an organizational problem. I'll say most good software tooling and frameworks ARE tech solutions for org problem, because technology is usually a solution to people problem. GQL is the peek of that, and it does it quite well. Don't use GQL to solve tech problems, there's better tools for those.

Re: After 6 years, I'm over GraphQL

#686

Post by hosh »

jamra wrote: post #490
svieira wrote: post #473

Earlier quoted context omitted.

> I seem to recall Meta/Facebook engineers on HN having said they have a tool that allows engineers to author SQL or ORM-like queries on the frontend and close to where the data is used, but a compiler or post-processor turns that into an endpoint. I don't know about on-HackerNews but there's a discussion about their "all of Facebook optimizing compiler" infrastructure from when they did the site redesign in 2020: ht…

Code generation is very common at Meta. One just needs to create a query or fragment. A fragment can be spread at the root query level using relay so it will do the fetch once. It gets more complex because you can lazily query more data based on parameters you pass into GQL. It feels like magic and is really annoying imo.

Just asking for clarity, when you used “GQL”, are you referring to GraphQL or are you referring to GQL, the successor to Cypher and openCypher?

Re: After 6 years, I'm over GraphQL

#687

Post by hosh »

Onawa wrote: post #511
hosh wrote: post #393

Earlier quoted context omitted.

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

I am looking at Apache AGE because it is a Postgres extension and it parses openCypher

Re: After 6 years, I'm over GraphQL

#688

Post by shados »

joegibbs wrote: post #514
nfw2 wrote: post #453

Earlier quoted context omitted.

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.

Not really. The usual strategy for persisted query is to only use them in production or adjacent areas. You build your app using regular graphql doing whatever you need, then after you tested things and it all looks good, when you ship, you parse the codebase, store the queries, and ship them.

It doesn't work if you don't have control over the client (eg: exposing to third parties), in which case query complexity limits are easy to implement and do the job, too.

Re: After 6 years, I'm over GraphQL

#689

Post by shados »

kiney wrote: post #196
hansonkd wrote: post #177

Earlier quoted context omitted.

REST APIS suck for nested resources. GraphQL is a huge breakthrough in managing them. Ever seen an engineer do a loop and make n+1 REST calls for resources? It happens more often then you think because they don't want to have to create a backend ticket to add related resources to a call. With internal REST for companies I have seen so many single page specific endpoints. Gross. > There have been different opinions ab…

Unpopular opinion: I'm actually a fan of singe page specific endpoints. You get much easier debugging, easier to audit security, easier performance optimization an the imho pretty small price to pay is that it's "not elegant" and a bit of backend code

The backend for frontend pattern. Something most apps where frontend and backend are in the same organization (fullstack or otherwise) should have. It does wonder to maintainability and performance.

Even though we use GQL here, we still have a B4F, so it's browser -> B4F -> GQL -> Database.

The tooling we use make it trivial so it doesn't add any development overhead (often reduces it. No CORS bullshit for one), and our app goes ZOOOOOOM.

Re: After 6 years, I'm over GraphQL

#690

Post by torginus »

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…

This.

The past few years I've been a 'full-stack' engineer - which is code for a backend guy who knows frontend.

In my personal taxonomy, a frontend developer is someone who cares a lot about UX, and making things look pretty, who also writes code.

I've met a lot of these people and they were more than happy to hand over all the infrastructure plumbing side of frontend apps to me - which I did along whatever REST API needed implementing on the server.

Post reply on HN