Something about GraphQL reminds me about constructing SQL queries on the client side, which by itself seems like a really bad idea.
Sure, GraphQL queries are read only, but the client still has the opportunity to DOS the server by constructing something complicated or unbounded.
The other issue I can see with GraphQL is managing data model migrations. I’ve had the misfortune of seeing a few large code bases over the years with inline SQL scattered all over the place. The answer to data migrations in these environments is often “don’t even try”.
Both of these kinds of problems can be addressed more easily by putting your queries in a service behind some endpoints.
Kind of wonder what the GraphQL solutions to these sorts of problems are.
Yeah, when I get the choice, I make sure SQL snippets are always in some sort of template file, with an easily-searched extension. Putting it inline in source code is just a really bad idea.
And yes, until I have my fantasy of being able to whitelist what kinds of queries a client can run, SQL needs to be constructed server-side. Putting access control on individual columns is a nice start, but in no way adequate protection.
Most of my recent frustrations, though, are really the fault of backend web frameworks. The modern way appears to be to let an ORM write your SQL for you, and doing it yourself is supported very badly if at all. I understand why people want architectures that conceal the existence of SQL, but I don’t agree and would not do it in my own system if there were a reasonable alternative.
I think the case for Relay, Falcor and GraphQL is better made without hanging it on REST’s deficiencies (imagined or not). Reminiscent of NoSQL vs Relational. Different tools, different problems.
Enjoyed the article though.
I’m a particular fan of how the article is apparently a response to several Facebook blog posts, but doesn’t start out by saying what it’s replying to. The entire thing is a cherry-pick of points the author finds egregious, which are only part of a single narrative in the author’s mind. I started to go into detail about how incoherent this is, but… I’m pretty sure that’s obvious to all of us.
The “Complicated Object Graphs” section is particularly nonsensical. The paragraph it links to is from a different blog post than most of the other complaints, and that post clearly begins by saying that GraphQL is completely independent of the request architecture - it’s a query language, not a protocol. Which is why its name is “query language”. The article ignores this, leading off by objecting that GraphQL shouldn’t require changes to REST. Indeed…
Lacker’s comment, and the ensuing discussion, are an excellent response to the rest of the piece. It really doesn’t deserve this amount of thought, given how its only unifying theme is “not invented here”.
So one thing that could differentiate this from a uninformed rant is a link to a well implemented REST (as they decree it) interface that I can play with that uses JSON Schema, HTTP/2, content-types to make a multiplatform, multilingual app that serves ~ 1.44 billion users monthly.
I don’t think a response of, effectively, “shut up until you have billions of users, which will authorize you to talk” is a very reasonable reply. I don’t even particularly agree with the linked criticism, but imo it’s pretty anti-intellectual to say that they can’t criticize Facebook’s architectural choices unless they first build a successful competing product.
Yeah, I almost left off the users figure when I wrote this offhand critique, since it’s immaterial to the quality of the ideas of relay, graphql, react, etc.
“I shall not today attempt further to define the qualities I understand to be embraced within a REST API; and perhaps I could never succeed in intelligibly doing so. But I know it when I see it, and the API involved in this blog post is not that.” - programmers
There have been a lot of posts questioning GraphQL. Assuming good faith and ability on Facebook’s part (& they have a history of it), all that’s happening is Facebook is having a hard time articulating why they created GraphQL. I think what they’re not communicating is scale.
I used to work at Amazon. Our team owned an internal service with 50+ business-logic service dependencies (more dependencies for ops tools) and 100+ clients. We didn’t invent GraphQL but we did have our own tools. New teams needed to quickly integrate into existing calculation pipeline and expose new data. Clients needed to consume this data quickly and they don’t really care where it comes from (!!). Interfaces should be uniform and unsurprising. From my perspective, GraphQL is about enabling change as quickly as possible in an environment like this. Without the scale and unique pressures of a big business with many teams both independent and tangled, GraphQL may indeed not be the best tool for the job.
Facebook doesn’t talk about scale in their docs because it’s not relatable. If I’m right-ish, this is unfortunate because it’s precisely the understanding of scale that makes GraphQL relatable.
You have to cache the whole chunk or nothing. It’s entirely possible that an API using fine-grained resources will outperform a course-grained one, because its focus isn’t to optimize making requests, but rather to avoid them entirely.
It is extremely unlikely that something as personalized as a social graph can be effectively cached at the network layer. Facebook’s clients can save smaller pieces of requests, there’s no way they’re requesting entire chunks if just one piece has been invalidated.
Second, HTTP can fire network requests in parallel. That’s been possible for years. There is some overhead with each request, but it’s unlikely that’s your bottleneck, especially if we’re talking about large object graphs.
No amount of parallelism will save you from having to traverse a deep graph.
If you’ve got a protocol with a built-in type system, and you complain about it not having a type system, that’s just an indicator of your own ignorance. […] If you use content types correctly, and also use JSON Schema with JSCK, you get strong typing over HTTP.
This is not REST though, this was never mentioned in REST, it’s your own solution to the same problem Facebook mentions, and is definitely not what everybody else is doing. Is Facebook really ignorant for not recognizing your non-standard solution?
In addition, you’re getting pretty defensive about the perceived slights to your sacred cow, but did you spend any time considering their proposed alternative? I have to say, it’s pretty dope. And even if you decide you still don’t like it, I bet there’s at least one idea in there that could inspire how you design your RESTful apis. That would be a lot more productive than coming up with conspiracy theories.
“If you implement REST, you use content negotiation, and thereby eliminate versioning and typing issues.”
This sounds like the “no true Scotsman” fallacy. Hardly anyone who implements a REST API does this, because it’s a big pain in the ass. But really, you are free to develop your applications however you want. Using Relay and GraphQL doesn’t lock you into any platform - it’s just open source technology. Facebook does not “charge rent” if you use a different query language instead of a REST API.
This sounds like the “no true Scotsman” fallacy
How is it a “no true Scotsman”? REST has a fairly precise definition. That (many|most|a lot of) people ignore details of the precise definition doesn’t change that.
In technology, we should be well past the attractive fiction that the party who invented something has final say over what it is. It’s hard to think of a single technology which hasn’t at some point in its history been embraced-and-extended into something unrecognizable, even for cases like HTML where that usually gets retroactively ratified.
That doesn’t mean the “embracers and extenders” get to call their new “thing” the old “thing” with impunity though. And it hardly means that people who actually care about the definitions of things should just throw their hands up and say “nothing has a definition”.
I think people have to accept that terms are actually populist, and you have to sort of give in to current understood meaning. “Nice” used to mean “foolish”. “Fathom” used to mean “encircle in arms”. “Naughty” used to mean “you have nothing (naught)”.
What makes a word “real”? feels someone relevant, and is an interesting talk.
Which of the many similarly-aged things with the same name is the definition, in this case?
REST has a fairly precise definition.
Dang, I have been searching for one for around a decade, can you link? Every authoritative definition of REST I have ever seen conflicts with all the other authoritative definitions of REST. Heck, I wish there was a clear winner just among version specification methods: URL, Request Header or Content Type.
Please excuse the friendly snark, but REST is hardly well defined… let alone implemented.
The canonical reference is Chapter 5 of Roy Fielding’s PhD thesis (he coined the term). He also wrote a smaller blurb some years later summarizing his opinion of how the term is commonly misused.
Thanks, I was aware of his thesis and that he coined it – but the term has been hijacked by many claiming to be the one true king. The clarification link was great, but I am not certain how relevant it is today to people consuming “REST” services.
You can spin it as a problem that lots of people are implementing “REST” wrong and should stop calling it that, which is perfectly fair… but useless, as people who have “REST”-similar (although often horribly broken and surprising) will continue to say “Use our great REST API”.
but the term has been hijacked by many claiming to be the one true king.
And? Just because a bunch of people hijacked a term doesn’t mean people who know what the term actually means should just stand around with their hands in their pockets and say nothing.
I admire you fighting the good fight! Sadly, I think like “literally” – we might have already lost this one and need to keep our eyes peeled for the next word definition battleground. At the end of the day, it is about communication and that means shared definitions.
Ah yeah I think you edited your comment after I replied, so it wasn’t as clearly a rhetorical question when I replied (or else I just misread it).
I agree, I think putting any kind of real meaning onto REST is kind of a lost cause at this point in practice. When I read someone say they have a “REST API”, I just read it as “API”, with the adjective adding no further information.
EDIT: Indeed, I edited after the fact (your reply came in fast).
Interestingly, the clarification post you linked by Roy Fielding seems to conflict with some of the things in the article.
From Linked Post:
Most alleged “REST” implementations underuse content negotiation, and underestimate the degree to which REST is intertwined with HTTP. But REST comes from Roy Fielding, a principal author of the HTTP spec. It’s not a coincidence.
From Roy Fielding:
A REST API should not be dependent on any single communication protocol
One needs to really, really read into that to reach the conclusion that an “Accept: v=2” header is correct REST and a “?v=2” URL param is incorrect REST.
Actually, his thesis seems to imply the opposite, that version is supposed to be part of the resource identifier. The Accept header should be used instead for deciding whether you want json or xml.
(It doesn’t help that the thesis is quite verbose, but not always specific.)