Earlier quoted context omitted.
Are you really surprised though? Like you alluded, people use Kubernetes and Bazel just because it has the big ol' G stamp on it. GraphQL is no different (Well... slightly different. It's the FB stamp, not the G stamp)
I'm surprised it took so long. I worked with k8s and realised pretty quickly it was pointless for my org.
After 6 years, I'm over GraphQL
561–570 of 721 posts
Re: After 6 years, I'm over GraphQL
#562Earlier quoted context omitted.
No idea why you bundle Mongo in there. I use Mongo in multiple production apps and I've never, ever looked back. Wouldn't even consider RDBMS's at all after my experience with Mongo unless I absolutely had to.
What kind of "production apps"? A todo list saas? I swear, the older I am, the more convinced I am that people who don't use a RDBMS just don't work on complex systems. Period.
Re: After 6 years, I'm over GraphQL
#563What about the benefits/drawbacks of the graphql client in a web app, e.g. Apollo [1], Relay [2]? You get a client-side normalized cache of all data fetched by any query. Here's a handful of benefits: - If data already exists in cache, a query will return that data instead of making a network request. - Everything that has a data dependency on something in the cache will automatically update when the data is updated,…
To me, the best feature is Relay Fragments (I think Apollo has fragments too?), as each component describes the data they need: no need to do a big top-level request then pass down the data to the responsible components, everything is in one file. It makes UI changes much much easier to deal with.
Deleting code automatically removes its data dependencies from the root query, it's ideal.
Re: After 6 years, I'm over GraphQL
#564I 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…
"Maybe implementing CORBA for message passing is over complicating it." "Maybe using OOP and facade classes is over complicating it." "Maybe using XML to store all the config information is over complicating it." "Maybe using this ORM with a strange file based caching mechanism is over complicating it."
And always get drowned out by everyone going with the trend.
Re: After 6 years, I'm over GraphQL
#565Let me explain the problem GraphQL actually solves. FB, as we know, is an incredibly large mobile app, possibly one of the largest in terms of actual code. Here are some realities about mobile apps:
1. Once released into the wild, that app version is out there forever. At app installs in the billions this is a serious problem. So you need something that handles versioning of your API. You need something to force you think about versioning and support old versions as long as possible. Again, I don't see the word "version" anywhere in this post. Versioning doesn't seem to be a problem the author has;
2. There are a lot of common objects in the FB app. Posts, comments, etc. When these objects become sufficiently complex, you don't want individual teams pulling out random fields. This is one thing fragments are for. It allows a specialized team define the object model and allow other teams to pull out a subset of that data.
3. FB uses an in-memory graph database for almost all things so issues like N+1 queries (which are real issues if you're talking to a relational DB) don't really come up. The in-memory database has a layer over it that does things like enforce permissions and privacy policies on reads and writes. GraphQL auth is really a superset of this. So if you're querying an endpoint for a user and their blocked users (one example from the post), you probably won't have auth in your endpoint because that'll be enforced by the data access layer that already exists and be written and maintained by a team responsible for that data.
Some comments here have complained that GraphQL is a technology for an organizational problem. I would counter that by saying all technology ultimately is tied to organization. They affect each other.
The above was all done to avoid things like privacy leaks, which at FB's scale is a real problem. Speaking from experience, a significant amount of computing power and software engineering time is tied to avoid these problems by the teams responsible as well as other teams to try and detect an unintentional leak.
How I see a bunch of people use GraphQL (not necessarily the author of this blog post) is as a 1:1 map to a relational model beneath it. That doesn't make a whole lot of sense. GraphQL probably isn't for you.
Re: After 6 years, I'm over GraphQL
#566Earlier quoted context omitted.
i agree with this. Writing queries is the most annoying part of graphql
I can’t imagine how annoying it would be if we had to write queries in JSON! writing queries is stupid easy if you use a tool like GraphIQL especially with the explorer.
I think this is a classic case of anecdotes not adding up to data.
Re: After 6 years, I'm over GraphQL
#567What about the benefits/drawbacks of the graphql client in a web app, e.g. Apollo [1], Relay [2]? You get a client-side normalized cache of all data fetched by any query. Here's a handful of benefits: - If data already exists in cache, a query will return that data instead of making a network request. - Everything that has a data dependency on something in the cache will automatically update when the data is updated,…
To me, the best feature is Relay Fragments (I think Apollo has fragments too?), as each component describes the data they need: no need to do a big top-level request then pass down the data to the responsible components, everything is in one file. It makes UI changes much much easier to deal with.
Re: After 6 years, I'm over GraphQL
#568Earlier quoted context omitted.
Those two are kinda orthogonal, and while there was some overlap for adoption, it was fairly common to serve XML over REST early on (because more languages and frameworks had proven-quality XML parsers out of the box, so it was easier for the clients to handle). JSON won in the end mostly because it was easier to handle in JS specifically, which is what mattered for the frontend. Then other languages caught up with t…
To claim that pretty much every .NET project adding Newtonsoft.JSON as a first step was somehow a problem is just strange. No adequate team would claim this to be a problem.
Re: After 6 years, I'm over GraphQL
#569Earlier quoted context omitted.
swr can handle the first issue you mentioned just fine.
I'm not sure I follow. Are you saying swr allows for fragments and deduplication? If you don't have fragments (in particular, if you have a single call to an swr hook at the root), then you have implicit deduplication. But then you run into the issue of it being unclear whether you can remove a given field when a subcomponent stops using it — you have to check whether any other subcomponent happens to use that. And i…
Re: After 6 years, I'm over GraphQL
#570Earlier quoted context omitted.
Someone like you made me quit my first job as developer. He implemented a Clojure + GraphQL nightmare.
Well that wasn't me, I implemented an Akka + GraphQL nightmare instead :) Joking aside, I'm sorry that happened to you and I'm sorry for the people that took over the system I helped to write.
Did Akka; thank goodness that didn't make it to production.
GraphQL: Helped in many ways. Hurt in so many too. In production.
Everything in Actors: State was everywhere. So much pain. In production.
I just use Postgres + RPCs for everything now.