For context, I'm a frontend development lead who oversees a number of projects of different shape and size. My personal and very subjective opinion is it's simply hype. If you say "Datalog" to a frontend developer, they will either hear "obsolete" or just not know what you mean. If you say "GraphQL", they hear "+5 CV points". Obviously that is slightly tongue in cheek, but the marketing side of it is a very real factor.
Facebook currently holds one of the largest levers in frontend development — React. If they say the officially recommended way to do X with React is Y, you can be sure that Y will get at least moderate traction.
I'm sure they exist out in the wild, but personally I haven't seen a project where GraphQL really shines through. In my experience, HTTP2 and reasonably well designed RESTful endpoints are the right default to go with. There is the argument that building good APIs is hard, but I believe someone who has reasonable experience with a stable technology will outperform someone using a new tool for the job. If you're not familiar with it, you won't know what to look out for.
> I'm sure they exist out in the wild, but personally I haven't seen a project where GraphQL really shines through. In my experience, HTTP2 and reasonably well designed RESTful endpoints are the right default to go with. There is the argument that building good APIs is hard, but I believe someone who has reasonable experience with a stable technology will outperform someone using a new tool for the job. If you're not familiar with it, you won't know what to look out for.
GraphQL doesn't make a ton of sense to me, unless you're expecting many clients with significantly different query pattern requirements and prefer to take on performance and (maybe) security uncertainty & complexity to accommodate that more easily.
If you only expect one client (or a few very similar ones) and you want GraphQL-like division of labor just have your frontend and backend folks actually talk to each other and maybe have the backend folks also write a client library for their services (my preference, most of the time).
[EDIT] but you bet your ass I'm not putting up much of a fight against it if I'm in anything lower than a development lead or architect position—no use fighting that fight from poor footing when, as you mention, it's +5 CV points anyway, so who cares if it's maybe not the best solution :-)
> "GraphQL doesn't make a ton of sense to me, unless you're expecting many clients with significantly different query pattern requirements and prefer to take on performance and (maybe) security uncertainty & complexity to accommodate that more easily."
My impression of it is that it's an "API" that's masquerading as a dumb relay, essentially giving almost datastore-level access to the frontend client (even though they don't market it that way). And this is done so that "Frontend devs" can just do "Frontend" things with access to all the data they might end up using. A bit snarky, but I do see it as a way to just "offload" the problem down the line, instead of thinking about the API-usage and what it means for potential frontend clients. That's the "old way" of doing things of course.
It fits in to the rest of the "movement" or trend currently happening: Thick (web) clients that do everything and the kitchen sink (including auth. See JWT in arb HTTP headers instead of cookies), SPAs so that there is no server side page rendering (this must all be done in the thick web client you see), document databases instead of SQL so the "frontend" devs don't have to worry about schemas, SPAs so that we break half the bloody internet because we now need to retrofit browser navigation using hashtags, everything has to be an "API" now because we can't convey data using server-rendering, etc.
Honestly, just that navigation thing alone is nuts and I can't believe we ever allowed it to be imposed on us. At this point, I'm afraid to touch those buttons on a new website without first trying them to learn their specific behavior on that site.
>My impression of it is that it's an "API" that's masquerading as a dumb relay, essentially giving almost datastore-level access to the frontend client (even though they don't market it that way). And this is done so that "Frontend devs" can just do "Frontend" things with access to all the data they might end up using. A bit snarky, but I do see it as a way to just "offload" the problem down the line, instead of thinking about the API-usage and what it means for potential frontend clients. That's the "old way" of doing things of course.
Or to take into the account that you have no idea what people actually use your API for. Lately i had to write an simple reporting site(simple, as i work with backend and GIS mostly) - using an existing API.
I need a fraction of data sent by API, but in bulk - it doesn't support that, nor i can change it.
Currently i do have to make a bulk requests that includes filters on the query, then i do need to individually request each record - as bulk API does not return the bloody two extra fields i need.
It turns a single query into N queries - which is slow and annoying as server cannot handle being hammered by thousands of rest API calls. Not to mention that i literally need 4 fields out of like 40.
If the app implemented graphQL it would be a breeze to just fetch what i need instead of waiting minutes(!).
You can handle proper URLs in a SPA if you know what you're doing. It's not something your average frontend dev would pay attention to though, sadly. Server-side "isomorphic" rendering of pages is also possible but a lot more complicated to resolve all the async requests that have to run to render the page.
>My impression of it is that it's an "API" that's masquerading as a dumb relay, essentially giving almost datastore-level access to the frontend client (even though they don't market it that way)
Well that's exactly what GraphQL doesn't do. Each GraphQL endpoint is effectively as powerful as a REST endpoint that takes in a JSON object as a parameter. (in other words the QL in the name is a lie) The primary difference is that you can send a batch of GraphQL queries at once and that you can filter attributes that are sent by the endpoint.
I will admit though, that there are a lot of GraphQL implementations that are just a thin wrapper over a database but REST had these for a long time as well.
A few weeks ago, I was pondering over the pain involved in designing and implementing a REST api, for an simple backend.
After much deliberation, it was clear to me that I dont understand the HATEOS part of REST and that I have been using the url as a filter and get or post parameters as variables for calling some functions on the backend server. And often, for an SPA, I would have to do multiple queeies in quick succession.
Then I realised, why cant I simply group those multiple query calls into one giant post request, with custom codes for querying or mutation, send a post request with a body that is a DSL i have thought of, and let my backend decode that DSL and send the replies. No longer would I be limited by URL structure, no longer would I have to make multiple query calls for getting a complex nested entity.
The only downside is that I have to docume t it more thoroughly and that my api does not have easy discoverability.
But since I have only one client, my frontend that I program,this is not an issue.
After pondering over the DSL a bit, I realised I am actually conceptualizing GraphQL.
The complexity is just moved somewhere else; instead of being explicit in an API, it's implicit in a behaviour. If you want to permission those bits you're doing CRUD ops on, or refactor how they're stored, change their normalization in the database, split them out of a monolith into separate services, ensure you're not permitting the UI team (or worse, your customers writing direct to your API) take dependencies on stuff you want to deprecate, well, the complexity just comes back; it's just in the code handling those custom codes, and all you've invented is a multiplexer that obscures the complexity.
I think there's value to it though, to GraphQL, but mostly on the read side rather than CUD side. Often all sorts of widgets need to knit together data from different sources, and if your data is relational under the hood, with REST endpoints per relation, the knitting is work better left to a library. I'm less convinced for updates.
After years of programming, I am convinced that complexity cannot be overcome. For any non-trivial application, complexity is inevitable.
In my view, we, as developers, should take up complexity, so that the user is unburdened from it. Ultimately, that is the value addition of software. Remove complexity and improve productivity.
Fundamentally, data is relational and hierarchical, no matter how we store it (Documents / SQL). The value added by GraphQL, and often touted in documentation, is that the client, has control over the shape of the data received from the server. Though packaged in a slightly easier to read syntax, GraphQL is essentially SQL. Sending a GQL query is fundamentally sending an SQL query set, with joins and where clauses, and having a layer of abstraction that understands the query and converts it into lower levels calls to data storage systems.
In my view, this is a more powerful syntax and more flexible than using a REST API. To achieve the same with REST calls, you would have to do something akin to multiple simpler SQL queries, with manual linking of relational data.
I am sure, there will be more innovation in this area, particularly with pairin GQL with Document databases.
The options are not only GraphQL vs REST. In a lot of cases, you can also render server side and push just plain html / components to the client instead.
Aren't you just moving the client to the backend here? As I understand it we are talking about how whoever needs to render the data gets the data. GraphQL vs. REST vs. whatever is still as relevant in the backend-rendered case.
It absolutely is. It is in fact, one of my preferred ways to design systems when doing it in tight coupling between backend and frontend. Such as in a micro-fronted-style vertical. It’s very effective when the needs of the frontend dictate the needs of the backend.
GraphQL actually makes a fantastic frontend for a microservices architecture. We have several GRPC services that drive a suite of applications, we wrap those in a graphql schema and we've now made consuming those services much easier while maintaining the original underlying services.
Interesting, I was thinking the complete opposite. GraphQL for internal api or single client api, while a REST api for external consumers.
Internal graphql api can be iterated and broken faster, adapting it for internal use as the app grows, while an external REST api would be more carefully generated and thoroughly documented.
In addition to my other reply, it serves well to finely granularize an external facing API so that consumers can mix and match to their requirement. This granularity is best accomplished by a REST Api.
The big win of using GraphQL, at least for me, is not the performance, but the developer experience. I can craft a query in Graphiql, paste it into my application, and from there generate Flow types for the query response. Make a breaking change to my graphql API? Flow types will fail CI tests until I fix any dependent client code. All of this works pretty nicely out of the box, and it’s leaps and bounds better than my past experience with homegrown rest APIs.
You mean frontend developer experience. The backend developers I interact with are not too enthusiastic on moving the complexity from the frontend to the backend when using GQL.
From my experience the backend also becomes simpler because it standardizes a lot of patterns, especially regarding subscriptions. I have a feeling any backend developer that thinks GraphQL is a significant increase in complexity is just reluctant to learn a new technology.
It's a shift from supporting some defined, limited set of behavior to supporting a much broader set of possible behavior, to the point that it likely can't practically be fully enumerated. If that's somehow not the case, then I'm not sure what you're using GraphQL for, since that's its whole thing.
Many years ago I worked at a company that had built a janky version of GraphQL in-house. The model fit our use case perfectly: our customers were dealing with a complicated ontology of objects and it allowed us to build new UIs on top of that data without implementing new REST apis. Of course our implementation wasn't the best but for a certain class of applications the graph-query model is a godsend.
GraphQL makes a ton of sense when your queries use data from multiple different and possibly interdependent source APIs. It allows you to hide all manners of ugly hacks behind a single, neat, cacheable endpoint that can even act as a normalisation layer.
What you've said is true of any aggregating intermediate API, graphql or not. If you don't want to make n calls, you make a single API endpoint that makes two calls for your one, just like when you compose functions in code. You don't need GraphQL for this.
GraphQL only really brings a novel way of defining what data you want. That's it. GraphQL fixes none of your data fetching problems if you're responsible for the actual end to end solution - if anything it gives you more.
It's marketed at front end devs, who in my experience, really love _easy_ solutions, rather than simple.
As far as I can see, there is precisely one scenario where GraphQL makes sense - and that's where you are trying to build a lot of separate frontend clients which will consume the same large, complicated data model. And unless both of those things are true, GraphQL is going to cost you more than the value it adds.
> As far as I can see, there is precisely one scenario where GraphQL makes sense - and that's where you are building an unbounded number of front end clients which will consume a complex data model. And unless both of those things are true, GraphQL is going to cost you more than the value it adds.
That matches my impression. Frankly I don’t think it’s very interesting. But damned if 3/4 the webtech-focused job postings I see don’t list “graphQL experience” under the nice-to-haves.
> As far as I can see, there is precisely one scenario where GraphQL makes sense - and that's where you are trying to build a lot of separate frontend clients which will consume the same large, complicated data model. And unless both of those things are true, GraphQL is going to cost you more than the value it adds.
I don’t get why GraphQL would be better at that particular use case than anything else, really. Capable of it, sure, but shifting the query-crafting to the client doesn’t really have any effect on that problem.
[edit] I just mean it seems unrelated to that problem, as far as I can tell.
> If you only expect one client (or a few very similar ones) and you want GraphQL-like division of labor just have your frontend and backend folks actually talk to each other and maybe have the backend folks also write a client library for their services (my preference, most of the time).
Yeah, but same result is much easier faster with graphql. When frontend developer can in most cases just slightly tweak the query, then it takes less time then having to talk to backend developer and wait till backend developer even starts working on it.(I am assuming that backend developer is normally occupied and is not sitting around bored until frontend developer needs query.)
And also, it avoids friction when backend developer is one of those superstars who are difficult to talk with.
GraphQL turns a social problem (getting your frontend and backend folks to coordinate with each other) into a technical problem that someone else already solved 75% of for you. That's a big win.
GraphQL doesn't do anything that you can't do with sufficient coordination, but coordination is actually one of the hardest parts of getting things done at a large company.
I sort of agree. GraphQL just seems like a solution for a small set of niche problems that's being promoted as a general REST replacement for any and all web APIs.
Seems like we (as in, our industry) went through this before with everyone ditching relational databases and glomming onto NoSQL (particularly MongoDB) - only to realize later it was a mistake.
For what it's worth, if I saw Datalog on a CV I would think "has studied the ways of the old masters" and when I see GraphQL I think "blub". But I don't claim to be good at hiring.
Kinda unfair since it's 1000x easier to get started with GraphQL than Datalog.
> I'm sure they exist out in the wild, but personally I haven't seen a project where GraphQL really shines through.
Look into how Gatsby.js uses GraphQL. You can query data from markdown files, configuration files (JSON) and resize images by specifying it in a query.
Github's api [1] makes sense to me - there are lots and lots of query patterns and the previous Rest api results in quite a bit of link chasing and bandwidth burning.
It would actually be interesting to see if someone could design a very good Rest api for gh-like usage.
This assumes the backend teams are even ready to offer HTTP/2 for us. For some reason or another, we're stuck at HTTP/1.1 since we are fronted by a certain CDN provider and our process for change management in that tool is skittish, since the rules grew organically and making changes is now tough.
Facebook currently holds one of the largest levers in frontend development — React. If they say the officially recommended way to do X with React is Y, you can be sure that Y will get at least moderate traction.
I'm sure they exist out in the wild, but personally I haven't seen a project where GraphQL really shines through. In my experience, HTTP2 and reasonably well designed RESTful endpoints are the right default to go with. There is the argument that building good APIs is hard, but I believe someone who has reasonable experience with a stable technology will outperform someone using a new tool for the job. If you're not familiar with it, you won't know what to look out for.