GraphQL and serverless—where cloud computing is heading

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.