GraphQL and serverless are two important trends that both, interestingly enough, originated in late 2014 and are now the new mainstream entries in the technological toolbox of developers. According to Google Trends, AWS Lambda and GraphQL now have equal momentum in regards to microservices.
Note: Read the next article in this series on the understated innovation of static site generators
While there has been a lot of discussion around the impact of microservices at the software architecture and infrastructure level, there doesn’t seem to be much about what the bigger picture for GraphQL and serverless looks like.
I thought I would take some time to reflect on the two technologies and look at the ways they can impact the software development landscape.
GraphQL originated from the need of a "data-fetching API powerful enough to describe all of Facebook" for the new version of the Facebook mobile application.
According to the GraphQL homepage, the main elements that it brings to the table are:
Buried deeper in the page are some more important points about GraphQL, explained in a way that’s more utilitarian than conceptual:
GraphQL is the most recent attempt to bring a language/runtime-agnostic type of description, typical in the wider developer community, together with description types that specify API interactions on how they should work and can be queried. This benefit and intent are, in order of magnitudes, more important than "data fetching."
It’s clear from some of the developments of the GraphQL toolchain, that interesting things are happening — for instance, Schema stitching provides an approach to API consolidation and unification, while projects like Apollo GraphQL and Prisma GraphQL demonstrate the usefulness of GraphQL at every level of the stack and not just at the very end, in the final hop to the user’s device.
GraphQL suddenly sparked discussion on ways to standardize how domain models are defined as type systems and exposed as services, and how such models can be combined and mixed in order to produce new domain models.
In the deeper section of the stack, there are definitely better contenders like gRPC, which has been compared or considered as an alternative to GraphQL at some level, but the concept of using only one technology at each layer of the stack still makes a very attractive stand.
If you’re old enough, a lot of this might echo the whole buzz around XML and SOAP, which ultimately failed to deliver most of their promises and were condemned to bloat the entire ecosystem.
GraphQL is much more likely to succeed because:
Serverless is just about as unfortunate a name as noSQL — it says what you don’t get but tells you nothing about what you get. Serverless came about as a label to describe technologies like AWS Lambda. The key points to take away about what "serverless" does, as stated on the AWS Lambda homepage, are:
The implications are much bigger than the above:
Somehow the conjunction of the two concepts came as a long term consequence of a tweet from Deane Barker. When I initially read it, I thought it was a very simplistic statement but "tossing modeled objects up into the cloud" can actually hide behind some very powerful concepts.
The above is an interesting frame of what cloud computing really means and how far we are moving from the concepts of servers and applications running on them, to a different concept; where we think in terms of pure domain models, their data and the logic that is applied to them.
A whole category of applications, which are now completely custom (falling in a number of categories like application proxy and middleware of all sorts), will be implemented as standard-schema transformations. These applications will be distributed or offered as Serverless, opening a new market for providers that specialize in providing it as a kind of middleware or as a service.
Serverless is becoming the standard way of allowing custom extensions in services, a strong trend for SaaS, with providers like Auth0 pioneering extensibility through functions.
Still, customization is only a first step towards a more complete model where application stacks are comprised of functions with defined input and output types, and softwares are made available as source (functions that you deploy) or SaaS (functions of a third party that you just call).
As Serverless pushes much of traditional server-side concerns and accidental complexity out of the picture, developers will be able to spend more time working on business logic and schema manipulations. This will reinforce current trends like full-stack developers, where one set of skills is applicable and effective at different layers of a development stack, though specialized profiles for the last mile (such as dealing with databases and datastores on one end of the extreme and graphical representation on the other) will still exist. In general, there will be more liberal collaboration between groups that were traditionally divided by different technologies and skill gaps.
Until a databases or datastore that "speaks" GraphQL natively emerges, there will be a trend of building services that offer database content as GraphQL API. This will effectively push databases one level down the stack to the point where applications will rarely have to connect directly to a database.
In a world of choosing between calling someone else’s function or a function of our own, certain topics like integration and vendor lock-in are starting to look very different. The same concerns still stand but it will become much easier to build a function to replace another and the overall degree of compatibility of the whole software ecosystem is likely to increase.
Static site generators is what developers who work with the web are talking about this year. Find out the understated innovation of static site generators in the follow-up article in this series.