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

181–190 of 721 posts

Re: After 6 years, I'm over GraphQL

#181

Post by Kwpolska »

UweSchmidt wrote: post #18
zer00eyz wrote: post #2

GraphQL is the peanut butter to Reacts chocolate at FB. It works there because 1. Every user is logged in. Is there anything you can do at FB without giving up something to the Zuck? 2. Because it's all behind a login, you can front load the first login/request with a giant SPA and then run all the custom queries you want. 3. everything at FB is some sort of blended context (my user, someone else's user, a permission…

What if Facebook wanted to open up parts of the site for users without an account, would that require a major reengineering? I've wondered why Facebook (and Instagram) are so strict about not showing anything to logged-out users, could technical reasons be part of that decision?

Not really, it’s 100% business reasons. Facebook and especially Instagram used to be much more open to logged-out users in the past.

Re: After 6 years, I'm over GraphQL

#182

Post by Capricorn2481 »

BiteCode_dev wrote: post #99
yonixwm wrote: post #90

Earlier quoted context omitted.

That’s the problem. In the days of jQuery/Angular2 (and even now personally), React was a blessing. Everyone hoped the same here. We should just join technology a little later on the hype cycle and have less stress.

React was a blessing for the few creating apps that needed more than jquery, and that AngularJS 1 couldn't handle for perfs reason. That was actually a very small parts of the projects in the world at the time, and in fact, a very small part of the number of projects that adopted react at the time. I remember above all that: - React was hyped to the roof by facebook. They had a fantastic marketing machinery for that.…

> React was a blessing for the few creating apps that needed more than jquery, and that AngularJS 1 couldn't handle for perfs reason.

React solved a very specific issue that was a pain in Angular, which is making it easy to write small, self-contained components and attach them to a mostly static site. That people decided to use it to make entire SPAs further illustrates how much easier they found it than other solutions.

I can't think of a case where JQuery code is ever simpler than React code, even for small things. If you need to worry about the order of rendered items or moving them into different categories on a page based on input, it's much simpler in React.

Re: After 6 years, I'm over GraphQL

#183

Post by foobarian »

jerf wrote: post #161
danielheath wrote: post #103

Earlier quoted context omitted.

The problem is that the client team can - without notice - change their query patterns in a way that creates excess load when deployed. When you use the "REST" / JSON-over-HTTP pattern which was more common in 2010, changes in query patterns necessarily involve the backend team, which means they are aware of the change & have an opportunity to get ahead of any performance impact.

My blocker on ever using GraphQL is generally if you've got enough data to need GraphQL you're hitting a database of some kind... and I do not generally hand direct query access to any client, not even other projects within the same organization, because I've spent far too much time in my life debugging slow queries. If even the author of a system can be surprised by missing indices and other things that cause slow q…

It seems there is a recent trend of using adapters that expose data stores over graphql automatically, which is kind of scary.

The graphql usage I'm used to works more or less the same as REST. You control the schema and the implementation, you control exactly how much data store access is allowed, etc. It's just like REST except the schema syntax is different.

The main advantage of GraphQL IMO is the nice introspection tools that frontend devs can use, i.e. GraphiQL and run queries from that UI. It's like going shopping in a nice supermarket.

Re: After 6 years, I'm over GraphQL

#184

Post by darthmallrat »

mst wrote: post #98
FrustratedMonky wrote: post #76

Earlier quoted context omitted.

That is pretty funny, But that video is 11 years old. It can't still be like that? can it? Seems like people are down on Mongo in the last year, and I'm trying to catch up.

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?

Re: After 6 years, I'm over GraphQL

#185

Post by tommica »

theK wrote: post #174

Fine article describing the weak points of GrahQL. I find it a bit poor though that the only recommended alternative is OpenAPI rest APIs. I have no beef against doing REST, jsonRPC etc. Actually I consistently steer people that way. But the documentation format we chose as an industry to build these things with, Swagger, is just disappointing. Some times I think the industry would be at a totally different point had…

> I find it a bit poor though that the only recommended alternative is OpenAPI rest APIs.

What are your recommendations? gRpc?

Re: After 6 years, I'm over GraphQL

#186

Post by foobarian »

theK wrote: post #174

Fine article describing the weak points of GrahQL. I find it a bit poor though that the only recommended alternative is OpenAPI rest APIs. I have no beef against doing REST, jsonRPC etc. Actually I consistently steer people that way. But the documentation format we chose as an industry to build these things with, Swagger, is just disappointing. Some times I think the industry would be at a totally different point had…

> But the documentation format we chose as an industry to build these things with, Swagger

This right here is IMO the biggest advantage of a GraphQL system. What equivalent to GraphiQL is there for OpenAPI? With GraphQL my frontend devs can go shopping for data in one UI, with rich descriptions and strong typing and even try out the queries live.

Re: After 6 years, I'm over GraphQL

#187

Post by 015a »

0-bad-secrotrs wrote: post #64

Aside from all the valid points listed in the blog I found out that the frontend engineers in my company save some queries in central library and reuse them even if they don't need all the field returned by this array just to save themselves the time they spend writing queries so they are basically using GraphQL as REST at the end and now we have the worst of both worlds.

Yup, we saw the same thing. Everyone wants RPC. That's it. We keep inventing crazy complicated patterns on top of RPC that serve mostly as good fodder to yell about in meetings, when `POST /list_users` and `POST /create_user` work great.

Re: After 6 years, I'm over GraphQL

#188

Post by ComputerGuru »

hansonkd wrote: post #177
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…

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…

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

Re: After 6 years, I'm over GraphQL

#189

Post by foobarian »

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…

> IMO GraphQL is a technological dead end in much the same way as Mongo is.

Can you suggest alternatives to graph introspection and related UI tools like GraphiQL, and the subgraph federation systems?

Re: After 6 years, I'm over GraphQL

#190

Post by tisdadd »

BillyTheKing wrote: post #5

GraphQL basically only really works with monoliths that share the same access-pattern (either everyone logged in, or everyone logged out), it's otherwise a pain to merge multiple different graphql-schemas into a single one (or at least I'm not aware of an elegant way to achieve that).. The worst of two worlds is a micro-services back-end with a graphql Api interface, it makes testing individual services and the Api a…

I remember having to solve the merge in the past and we ended up using a merging tool pretty easily to do so. Believe it was this one? https://the-guild.dev/graphql/tools/docs/schema-merging

We were basically just enhancing an external graph with some of our own stuff added on though so fairly straightforward.

Post reply on HN