Nader Dabit

Posted on Jul 30, 2019

Infrastructure as Code in the Era of GraphQL and Full Stack Serverless

#serverless #awsamplify #graphql

In the past we could clone a client application and then launch it in our browser or mobile simulator. Today we can clone and deploy full stack applications by leveraging a new paradigm of infrastructure as code that allows us to deploy both the front end and back end code.

GraphQL is changing the way that applications are being built. Infrastructure as code is especially well-suited for GraphQL applications because we can shape and evolve our data model over time, allowing developers to build, collaborate on, and deploy applications in new and exciting ways. In this article, I'll show you how front-end developers and developers new to cloud computing can begin taking advantage of this paradigm.

To see an example of Amplify IAC in action, check out this video.

One of the most powerful advantages of cloud computing is the ability to deploy cloud and serverless resources based on configuration files, known in the industry as infrastructure as code (IAC).

As a traditionally front-end developer that only occasionally would build out and deploy back end resources (like databases, servers, and authentication mechanisms), I was always used to clicking around admin panels, digging around SSH, and writing a bunch of boilerplate in order to set up my APIs (and usually spending a bunch time doing so).

When I learned that developers had the ability to deploy an entire technology stack in just a couple of minutes I was shocked and wondered why this wasn't a much bigger deal in the front-end developer community.

It turns out that it wasn't that easy. The ability to deploy in this manner is easy once the configuration is complete, but to write and manage this configuration it usually takes someone who is already at least somewhat knowledgable about cloud computing. Front-end and developers new to cloud computing like myself would be lost trying to deploy even the simplest of resources. This is no longer the case.

Modern tooling

The good news is that tooling has improved and it is rapidly becoming easier and easier for front end developers and developers new to cloud computing to get up and running with this type of infrastructure.

Serverless technologies are especially good candidates for this paradigm as we need much less infrastructure to be deployed in the first place. This leads to overall less complexity therefore creating an opportunity to lower the learning curve and enable a larger community of developers to take advantage of the scale and opportunities cloud computing has to offer.

Serverless Framework

Take for example the Serverless Framework. The Serverless Framework introduced a much easier abstraction over traditional IAC tools (like AWS CloudFormation) by allowing developers to only have to worry about the most necessary configurations and then the framework would handle the rest by using CloudFormation under the hood to deploy the infrastructure.

If you've ever created a Serverless project, you may get a base serverless.yml file like this created as part of the boilerplate:

service: testproj
provider:
  name: aws
  runtime: nodejs10.x
functions:
  hello:
    handler: handler.hello

The great part about this was that you could deploy a serverless function in just a couple of steps from the command line. Once you became familiar with the framework and the cloud provider of your choice, you could also deploy other resources like databases, authentication, and storage.

The only drawback is that once you get past a "hello world" type of project you must dig into or be familiar with AWS / Azure / GCP a bit more in order to understand how things work.

AWS Cloud Development Kit (CDK)

While configuration in the form of YAML or JSON is definitely considered infrastructure as code, a new form of infra as code was introduced with CDK. CDK allows you to declare your infrastructure in actual programming languages like Typescript, Python, Java or .NET.

For instance, if you wanted to deploy an S3 bucket you could write the following code and deploy:

import core = require('@aws-cdk/core');
import s3 = require('@aws-cdk/aws-s3');

export class HelloCdkStack extends core.Stack {
  constructor(scope: core.App, id: string, props?: core.StackProps) {
    super(scope, id, props);

    new s3.Bucket(this, 'MyFirstBucket', {
      versioned: true
    });
  }
}

CDK is rapidly gaining adoption and has a very bright future. Again, like many other IAC tools, the drawback is that once you get past something basic you must be somewhat familiar with AWS.

The evolution of Infrastructure as Code

The industry is continuing to see an explosion in managed services and tools that facilitate cloud enabled and serverless computing. This new tooling is becoming more and more accessible and aimed at new developers and those that consider themselves as front-end developers.

This makes sense considering that developers already knowledgable and using the cloud may not be interested in learning "another way" to do things that they already are comfortable doing. Another reason this makes sense is that there is a massive number of developers who consider themselves front-end or even full-stack developers that have not yet adopted the cloud.

How can these developers get started adopting and taking advantage of IAC? In most areas of software engineering, things are simplified over time by better and more sophisticated abstractions.

In mobile development, we can now build cross platform applications using a single programming language with tools and frameworks like React Native, Flutter and Xamarin. With React, Vue, and Angular, we no longer have to deal directly with the DOM and can build complex apps directly in the browser. Cloud computing enables developers to provision and tear down countless servers without leaving their seat.

The same thing is happening with infrastructure as code. With tools like AWS Amplify, IAC is automatically provisioned for you as you are building your application without any extra work needed on your part. At any point you can then share and redeploy these resources yourself or share them with another developer to deploy in their account.

This opens the doors for a lot of interesting opportunities, including a new paradigm in code sharing and reuse, and an entry point to distributed systems development for front-end developers and developers new to cloud computing.

Category-based approach & Amplify IAC

One of the goals of AWS Amplify is that it allows developer to develop and build cloud applications without needing advanced knowledge of the underlying infrastructure that it created. Amplify works using a category-based approach: need authentication? amplify add auth. Need an API? amplify add api.

Nowhere in the setup or utilization of these services do you need to know or say anything about the underlying service name. What you might not have known? Once your project has been created and as you are building it, Amplify is generating this infrastructure as code behind the scenes. The amplify folder in your project is a current and reproducible snapshot of your cloud resources at any given time of your application lifecycle. At any time you could share and redeploy the current stack you are working (either your account, or if shared in another person's account).

Over the past year we have been developing open source projects that allow developers to deploy pre-built full-stack serverless applications that utilize Amplify IAC. Projects like Conference App in a Box, AWS AppSync Chat, Hype Beats and Speaker Chat can be deployed with either a single click (web) or a few commands from a command like (Mobile / React Native).

Using preconfigured Amplify IAC projects, you have can a starting point for common applications like chat apps, complex authentication with routing, and implementations of real-time like dashboards.

Many Amplify projects use GraphQL as the data provider, allowing you to easily modify the data structure by updating the GraphQL schema and redeploying with a single command.

Once you're finished with your app, you have a code representation of all of the resources available at your fingertips. You can then test, share, open source, or start a business using your code as you see fit.

GraphQL & IAC

Take for example a recent application I released, Conference App in a Box. This is a configurable, themeable, production-ready mobile application that can be deployed for events and conferences.

Let's take a look at the base GraphQL schema for a talk:

type Talk @model {
  id: ID!
  name: String!
  speakerName: String!
  speakerBio: String!
  time: String
  timeStamp: String
  date: String
  location: String
  summary: String!
  twitter: String
  github: String
  speakerAvatar: String
  comments: [Comment] @connection(name: "TalkComments")
}

When you clone and deploy this application, it is assuming the data structure will look like the above. But consider that you may also want to add a Dribbble profile for a design conference?

You could easily modify this entire application with 2 lines of code: one to update the schema to add the Dribbble field, and another to render this field in the mobile application.

The schema could be evolved to match other applications as well, meaning you could take this infrastructure out of the app and deploy it to another platform or for another application.

I've already talked with dozens of conference organizers who will be adopting this application because it is such a time and money saver. Many of the organizers have spent thousands of dollars and hundreds of dollars replicating the functionality they get from this app that can be deployed in a matter of minutes.

Trying this out

If you're interested in trying this out, check out one of the following projects and follow the steps in the documentation:

Future

In the future, I envision a new category of full stack serverless app repositories that take advantage of this type of IAC, not only from AWS but I predict other cloud providers and companies will follow suit.

As the lines between front end and back end development continue to blur, we will see more and more tools emerge that abstract away what used to be complex back end and cloud technologies.

My Name is Nader Dabit. I am a Developer Advocate at Amazon Web Services working with projects like AWS AppSync and AWS Amplify. I specialize in cross-platform & cloud-enabled application development.