GraphQL and serverless—where cloud computing is heading
![GraphQL and Serverless - Where Cloud Computing is heading](https://images.ctfassets.net/fo9twyrwpveg/17Lm1Hkq8W4qsoMeYu0QMc/5055238b9cca51246576e6a8aceb05ad/GraphQL_and_Serverless_-_Where_Cloud_Computing_is_heading.png?fm=jpg&q=90&w=1536)
GraphQL and serverless are two important trends that both, interestingly enough, 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
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:
A query language which allows for expression of queries on a graph or relationships
Efficient network transfer — a consequence of the query language’s expressiveness, where it is possible to request all the data necessary for a given task with one query
A type system that defines what a GraphQL API is able to provide
Buried deeper in the page are some more important points about GraphQL, explained in a way that’s more utilitarian than conceptual:
Advanced developer tooling that enables things to move faster
The ability to evolve the API without having to deal with versioning
The ability to write code in any programing language because of type definition being language agnostic
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.
Is this just XML and SOAP all over again?
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:
It starts by solving some very practical problems — see the GraphQL homepage that showcases its pragmatic points at the top and more conceptual last at the bottom
It’s actually developer friendly — SOAP and XML were optimized to be machine-friendly, though I have never indeed encountered any humans who have said anything positive about working with them
It gets adopted by development teams that buy into it, instead of being prescribed to them — SOAP and XML just became, at some point, a non-negotiable requirement of enterprise software
What is serverless?
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:
Run code without provisioning servers
Pay based on how much your code is actually invoked
Doesn’t require any administration
The implications are much bigger than the above:
When you use serverless, your server is actually everywhere. (It isn't not nowhere as the name suggests.) You can deploy a lambda function in any region AWS is available. With new concepts like lambda@edge your deployment is actually planetary.
Serverless make your server absolutely identical to anyone else's serverless server. Once you get effective ways of distributing serverless code, you’re in a position to replicate consistent deployments in a way that has no precedent.
Why Serverless and GraphQL are interesting in combination
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.
Through GraphQL, there’s a way to define types for objects, and how these can be queried and modified.
Through CDNs and gradually faster inter-region connection in the cloud, it is possible to distribute these objects (and their schemas) so that they are available anywhere
Through serverless, and particularly its deployment at the edge, it is possible to recombine these objects and create derivative or new domain models for clients, or even just simply for other cloud applications that are higher or lower in the stack
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.
Five possible outcomes serverless and GraphQL could bring
Schema stitching and transformations will become a category
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 will become an important way of building and distributing software
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).
Developers skills and profiles will shift
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.
Databases will be pushed down the stack
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.
Some traditional make or buy trade-off factors will fade away
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.