GraphQL, fads, and tech fanboyism
“What Do You Need to Know About GraphQL? — Postlight — Digital Product Studio”
A fair, if a tad too positive, overview of GraphQL.
I’ve been doing a lot of research into GraphQL over the past few weeks and it’s worrying how little interest there seems to be in critical assessments of whether GraphQL is appropriate for you or not. Because, based on my research, GraphQL is likely to increase your coding productivity in the short term but, in most cases, substantially increase the complexity and code for your project.
And there’s frequently a mismatch between the GraphQL schema you’ve written and the optimum for the various data sources and APIs you’re integrating. So, as with React itself, it increases developer productivity, helps multi-departmental organisation, but likely at the expense of long term performance. The complexity hits development sooner or later, and the schema-datasource mismatch is only going to grow as your app evolves. And it abstracts over HTTP a little bit too much for you to be able to leverage all of the free performance stuff that HTTP gives you for free (caching, built-in clients, universal support).
Of course, there’s a point where the payoff is big enough for it to be worth your while but I have yet to see an article that actually engages with and studies properly the costs and payoffs for concrete use cases.
That isn’t surprising. Tech writing alternates between utter hateful contempt and uncritical love-fests. Critical writing is in short supply. There is no way for an outsider (like, say, a manager) to assess whether something is a fad or not just by reading tech writing. You’re going to need to do the heavy lifting analysis yourself.