Serverless and GraphQL: A Perfect Match for the New Cloud Paradigm
When developers design their APIs using GraphQL and their applications with serverless architecture, they make it easier for themselves to issue queries and function calls to APIs, while at the same time enabling more complex business logic with serverless and microservices. Perhaps this combo represents the perfect delivery model for complex, cloud-based data architectures.
Last month, Jared Short, director of DevOps at South Bend, Indiana, serverless solutions provider Trek10, spoke at Serverlessconf on the topic of building and scaling single page apps directly using AWS Lambda and AWS API Gateway. In Trek10’s architecture, content is served up via a GraphQL endpoint, with function resolvers communicating with the data store. It relies heavily on single-page apps, so there are plenty of notifications in place to alert Short, as DevOps commander, when something goes wrong — such as, for instance, an image being set in the wrong location.
“Part of our business at Trek10 is this 24/7 managed authoring where we get all of the alerts come to us first,” said Short. “And that can be painful, especially if you don’t have these super-scalable systems in place. Maybe someone screwed up configuring an autoscaling group, so I get to wake up right? I have never had to wake up for a GraphQL, serverless, single application setup.”
Managing Business Logic in Serverless
Vince Ning, co-founder and COO at GraphQL “back-end-as-a-service” provider Scaphold, has been building out serverless components as a complementary feature.
“With serverless, it can be hard to wrangle all of your serverless functions together,” said Ning. “Leveraging GraphQL provides cohesion for all your microservice functions as if they were a monolithic API. So you get the best of microservices, and the best of compute, efficiency and performance and still get to maintain the one standard API that connects all of your data.”
Ning offered this example of a typical use case for making a “create user” action: With a typical REST API architecture, you might create the instance of the user, then issue a call to make a blog for that user at the same time. Serverless functions would then carry out some business logic before and after the event — for example, validating inputs before creating the user instance, or confirmation afterward.
Using GraphQL and serverless together, however, functions can be carried out asynchronously, so pre- and post- activities are all served to the client through a single endpoint.
Ning describes the design pattern:
“The client makes a GraphQL request to create user. In your architecture, you set up pre- and post-hooks as part of your serverless workflow. For pre-hooks, you might do some validation to confirm it is an email address and some data cleansing. Post-hooks might include a confirmation email to the user and make a connection between data items.
“So the create user call goes to the server, you can pass in inputs (like username and password), and any pre-hook functions for custom validation or data cleansing are carried out (for example, checking that the email address has an @ and domain using RegEx),” Ning continued. “After it calls that microservice, it will do the actual create user mutation (that is, write the data via the API), and save it in the database. Then you can have a post-hook function — a lambda function to send a MailChimp email with a welcome email. After that is sent, it will come back with a response with the create user mutation payload. That would be three separate requests, but they are all done in one GraphQL request.”
There’s no limit to the number of pre-hooks and post-hooks you may create for this workflow, Ning added. For example, to generate a blog for this newly created users, said Ning, “you have to create the user and the blog, and create the connection, ‘user has blog.’ In a post-hook function, you can say upon creating a user, create a blog and then create a connection. So, again, instead of a roundtrip to create the two, in a post-hook function, I can offload that logic.”
There’s just one call, it’s issued with assured type safety, and the logic always produces exactly what’s expected, continued Ning. “Anywhere you are using microservices, we will bubble that up to your client, so it is one cohesive mutation that you are calling.”
Ning says for now, custom function composition is one of the most popular use cases he is seeing for combining serverless with GraphQL.
“Serverless gives you a lot more flexibility to run your processes. Normally, you have to keep your REST API as something generic as you wouldn’t want it to be bloated with custom logic. People are seeing serverless as a solution to that constraint.”
GraphQL at the Contentful Serverless Platform
API-first content management service Contentful is a server-less platform in some respects. Customers store their content data with Contentful, so they don’t have to manage servers. Through Contentful, developers have access to an architecture that automatically scales with their customers and responds to their preferences and requirements, so customers can focus on composing content.
“We saw more developers talking about GraphQL and were beginning to see its value,” said Peter Sunna, head of product at Contentful. Its GraphQL library started as a side project, but has now become a part of its Labs offering. Here, its developers can test whether customer demand is growing sufficiently enough for them to incorporate its features with their core feature set.
“We soft-released the library a month ago”, said Jakub Elżbieciak, who leads the GraphQL work at Contentful. “Even before our official launch last week, I had a dozen issues and suggestions before the package was even announced and we had 450 downloads on NPM. That’s from Contentful customers who are searching for ‘GraphQL’ and ‘Contentful.’”
The latest from the Contentful labs: a @graphQL library for querying your spaces! Deploy it to @zeithq & you’re set!https://t.co/C4jhRgbDFe
— Contentful (@contentful) May 9, 2017
Sunna told us that technically, everything users can do with GraphQL they can do with Contentful’s REST API, which includes a large number of relational query capabilities that Sunna said customers aren’t yet taking full advantage of. Unlike Scaphold, Contentful’s GraphQL project sits immediately on top of its REST API. There is an available serverless config file for Contentful’s GraphQL project, so it can be deployed on Infrastructure-as-a-Service platforms like AWS and Heroku. A GraphQL endpoint may be deployed automatically as a standalone application, though it also exposes a programmatic interface that can be used inside or alongside other serverless business logic functions.
Other GraphQL and Serverless projects
By stitching together various functions from third-party suppliers as part of a serverless supply chain, Jared Short told Serverlessconf, developers avoid reinventing the wheel. That’s definitely the case at Scaphold, agreed Ning. For example, Scaphold shows how search API Algolia can be put to use in serverless environments. “In a matter of minutes,” said Ning, “you’ll have Algolia’s search experiences available through GraphQL on Scaphold’s platform, without having to manage any infrastructure yourself.”
Graph.cool, another GraphQL backend as a server (mentioned in Short’s Serverlessconf presentation), this week launched a new serverless back-end platform, built on the principle of stateless, short-lived computational functions. Its announcement noted, “The GraphQL API plays the same role as an object-relational mapper in traditional back-end applications, with the important distinction that the GraphQL API is consumed equally by the front-end application and back-end logic.”
In the Internet of Things space, experiments like John McKim’s serverless garden monitoring system demonstrate the potential of using GraphQL as a single endpoint for a rapidly amassing data store, due to its constant sensor readings. McKim built a custom authorizer to verify a JWT token via Auth0 and built a web client to monitor the soil moisture of his garden. In his blog post, he shows the architecture design:
“We saw GraphQL as a huge thing,” said Scaphold’s Ning. “And serverless is going to be the way of the future, so GraphQL and serverless is a match made in heaven. The purpose of GraphQL is to consolidate data services and serverless doesn’t solve the problem of scattered data sources, so they really complement each other well. This is what we want to keep pushing forward with.”
