Create a Cloud Native API from Scratch

Create a Cloud Native API from Scratch

May 2, 2016

SERIES OVERVIEW

Welcome to the most helpful blog series in the world. Here, we’ll build up a modern web-scale Application Program Interface (API) together. Over the years, I’ve had the privilege to help multiple companies modernize their workflows, take advantage of modern development practices, and help improve the pace of innovation. Now, I want to help you for the low low price of totally free.

As the series progresses, together we’ll develop a modern API that will eventually take advantage of Continuous Integration (CI) and Continuous Delivery (CD). Along the way, we’ll introduce new technology and development best practices that will help achieve our goal, and we may just become best friends. Not really. Unless you’re into that.

Let’s have fun, keep it casual, and build something technically, awesome. To the cloud!

PREMISE

You’re a senior developer working at the market-leading “Fictitious Established Corporation” (FEC). You’ve been maintaining the company’s flagship product line, but over the years the application’s organic growth has made the application very difficult to maintain and scale to meet customer demands. Development of new functionality has been reduced to a crawl – even minor changes require a herculean effort to release to production.

Meanwhile, a new startup has started eating into your market share, as they are much more efficient at innovating and delighting customers. There is a very real need to innovate for the sake of the company.

Late one Thursday evening, your boss comes to you with a solution. The company would like to transform FEC from an installable product and adopt a Software as a Service (SaaS) delivery model.

Functional requirements are nebulous at best, other than the mantra from product management to maintain feature parity with the legacy application.

You are tasked with creating a MVP (Minimal Viable Product) that meets the following current technical requirements as outlined by the FEC senior architect:

API must use existing company maintained information data set

API must follow 12-factor application practices

Must follow Restful principles

Must be deployed on Amazon Web Services

Must be well documented

Must run on Ubuntu Linux

Must scale easily

Must be developer friendly

Must must be coded in Node.js because of in-house expertise

The Restful API should use the Restify Framework because some Senior Architect fell in love with it

Must must be well tested and easy to deploy

Must be secure

As you embark on your development adventure, you decide the best place to start is to spend some time researching the 12-factor application methodology, a set of best practices proven to increase the quality of Software as a Service (SaaS) applications. Lucky for you, this trail has already been blazed.

The first principle outlined is to always have one codebase per application (http://12factor.net/codebase), and this is where we’ll start our journey together.

SETTING UP THE REPOSITORY

Your company uses GitHub (http://www.github.com) for source code management, and you login and create the repository for your new application. At this point, you are faced with your first of many decisions. What should I call this application? After a quick conversation with management, you discover that this application is top-secret and has only been given the code name “12-factor-app.” No points for creativity, but it’s as good a name as any.

You click a few buttons in GitHub and your repository springs to life.

For the purposes of this series, we’ll be working right off the master branch to keep things simple. It is required that you have Git (git-scm.com) installed in your local environment. Once installed, you can clone the repository by running the following command in the directory where you would like to work:

At this point you have basically satisfied the first factor that each application belongs to one repository (https://github.com/redapt/12-factor-app). We have a long way to go to finish this POC, but together we can sculpt a developer friendly, scalable, and secure API that will be maintainable over time.

CONFIGURING YOUR DEVELOPMENT ENVIRONMENT

To prepare your development environment you decide to rely on Docker (https://www.docker.com/) container technology. You’ve heard this is an easy way to spin up a development environment. Using Docker enables us to begin to satisfy factor two, which recommends to “explicitly declare and isolate dependencies” as well as factor ten, which states that development, staging, and production environments should be as similar as possible.

I like to develop on my Mac using JetBrains Integrated Development Environments (IDE). For this blog series, I’ll be using WebStorm as it has great support for developing Node.js applications. You are in no way required to mimic this environment to follow along with this series. Just one of the many advantages of using Docker.

Recap

In this first entry, we introduced the general premise of the API POC project, and outlined some of the technical requirements that we must adhere to as we build out the API. To help ensure that best practices are followed, the Twelve Factor App methodology was introduced. So far we’ve touched on three of the factors as we set up our repository, and configured the basic development environment using Docker technology. We’re crushin’ it, guys.

New Technologies and Practices Introduced

For a more detailed understanding of some of the technologies introduced in this blog please visit the following:

Stay Tuned

In the next entry, we’ll add the Restify framework to our Dockerfile, and spin up our new development using the Docker Toolbox. We’ll then create some unit tests to start to achieve parity with the existing product. Test Driven Development (TDD) will also be introduced and explored. So whatever you do, don’t change the channel.