Alfian Losari
Oct 23, 2018 · 8 min read
Application Architecture with Google App Engine Flexible Custom Runtime

Google App Engine is a Platform as a Service (PaaS) solution provided by Google Cloud for customer to build scalable backend service without managing server deployment, load balancing, and scaling the infrastructure. As developers, we just need to focus on writing the code and deploy the code to the Cloud. App Engine handles all the process of infrastructure deployment automatically such as virtual machine instantiation, load balancing, autoscaling, Google Global DNS network, task queue, memcache, health check, Stackdriver Logging, and even traffic splitting different version of our backend application. The equivalent services of App Engine are AWS Beanstalk and Salesforce Heroku.

A brief history and current state of Google App Engine

App Engine is the first PaaS solution provided by GCP when it was started in 2008. It had many limitations such as java only runtime language support, Google Datastore to store the application structured data, 1 minute timeout between request & response, and sandboxing with limited access to install custom dependencies into the virtual machine environment.

As of end of 2018, Google Cloud provides 2 environments to use App Engine, one is standard environment with constrained environments and support for languages such as Python, Go, node.js. The other one is the Flexible Environment where developers have more freedom such as running custom runtimes using docker, longer request & response timeout, and ability to install custom dependencies/software, and SSH into the virtual machine. The pricing between standard and flexible environment is also different, you can see how the pricing works by visiting the pricing documentation of each environment.

In this article, we will use Google App Engine Flexible Custom Runtime to build a Swift Vapor Backend Web Framework server using Docker and deploy it live in the Cloud using Google Cloud SDK. It will also connect to Google Cloud SQL to store the todo app data of the application.

Requirements

  • Google Cloud Account
  • Google Cloud SDK and Authentication in local machine

What we will build:

  • Vapor Swift Application providing Todo CRUD API
  • Custom Dockerfile based on Ubuntu and preinstalled Swift runtime language
  • Cloud SQL instance in Google Cloud Configuration
  • Deploy to App Engine using Google Cloud SDK
  • Test the App
  • Monitor Application Log in Stackdriver monitor

Cloning Swift Vapor 3 Todo App from GitHub Repository

We are going to deploy a web API using Swift Vapor 3 Web Framework. Vapor 3 has several main features that are really awesome such as:

  • Using Apple SwiftNIO to handle non blocking event driven architecture to achieve high performance low latency server.
  • It’s written in Swift, the powerful multi paradigm programming language.
  • Expressive protocol oriented design with type safety and high maintainability.

The performance of Vapor is also very promising by looking at the average latency performance using Plaintext benchmark from the graph below (taken from VAPOR medium article).

Average Latency of Vapor 3 (Lower is better). VAPOR

Clone or download the app from GitHub repository into your local machine by clicking on the link below.

The app consists of many different components, inside Sources/App directory. Several of the key parts are:

  • routes.swift. The routing setup of the app, here it uses the todo path to group the request into a CRUD structure. You can see the expressive request custom path parameter that uses Swift codable and parameter under the hood to convert the request into Swift object.
  • configure.swift. Configuration of the Application before it runs, inside here we get the environment variables from the system and using it to connect with MySQL database server and perform migration of the table using the Swift struct. (For testing purpose, we connect to Cloud SQL using tcp instead of App Engine Cloud SQL proxy Unix Socket because Vapor FluentSQL currently does not support Unix Socket for connection to MySQL server).
  • todo.swift. A Swift struct that conforms to MySQLModel and migration so the database can perform migration from the object to the row in MySQL table. It also conforms to Content, which is like codable so Vapor can just return the object from the response and automatically convert it as JSON.
  • Future object. To handle asynchronous operation and non blocking operation, Vapor uses Future that works like Promise in Javascript.

You can run the app locally, but before that you need to install and run MySQL server in your local machine, then create user, password, and database named todo. Make sure to export all the environment variables inside the configure.swift into your shell. Then run swift build and the compiled app inside the .build directory. Use cURL to perform the CRUD operation (see README.md for API specification inside the cloned project directory).

Using Dockerfile to build custom runtime in App Engine Flexible Environment

To deploy our app to Google App Engine Flexible custom runtime, we need to provide Dockerfile containing the docker image that we want to run inside the container. The Dockerfile is located in the cloned repository root directory. Open it and take a peek.

Inside, we tell docker to use the IBM Swift image running latest Ubuntu from docker repository. Expose the port 8080 of the container to the host machine 8080 app engine default port. Copy the current folder into the app directory and set it as working directory. It also build the Swift package using the configuration release. Lastly, as the entry point of the container, it runs the application server from the build directory.

Create Cloud SQL Instance in Google Cloud Platform

For the MySQL server hosting, we are going to use GCP Cloud SQL managed database solution. It provides 2 SQL database to use, MySQL and PostgreSQL. Our app is using the MySQL to store the todo list data. You need to create Google Cloud SQL instance by using either Google Cloud Console or using the SDK.

Here are the instructions if you prefer using the console to setup the instance:

  1. Go to Cloud SQL Console.
  2. Click create an instance.
  3. Choose MySQL as database engine.
  4. Choose MySQL Second Generation.
  5. Set the name and strong password for the root access for the instance.
  6. Choose region (us-central1).
  7. Click on show configuration options and set connectivity, check the public ip and click add network. Set the name to all and the network to 0.0.0.0/0 (!!! This is unsafe and only used for testing purpose because currently Vapor’s Fluent MySQL does not support Unix Socket to connect to Cloud SQL Proxy in App Engine Environment, for production you should use connection only from SSL by generating client certificate to avoid access from unsafe client !!!)
  8. Click on Configure machine type and storage, change into db-f1-micro and HDD.
  9. Click Create.
  10. After the database has successfully created, click on the instance to view the details.
  11. Go to Users tab, click create user account, then set your username and strong password. Click create.
  12. Go to Database tab, click create databases, set database name to todo. Click create
  13. Copy the public ip address and instance connection name.

Deploy to App Engine using Google Cloud SDK

To deploy the app from our local machine, we need to install Google Cloud SDK. Before that, we need to set the configuration and environment variables for the App Engine. Go to the cloned repository project directory and open app.yaml.

Inside we tell the App Engine to use the custom runtime and flexible environment. We also set the manual scaling and just 1 instance for testing purpose. In production, you can set the automatic scaling with the maximum number of machine to upscale. In environment variables, set the MySQL user, password, database, ip, instance name to your Cloud SQL instance configuration. There are many customization that we can configure such as machine type, memory, disk, network. You can visit the documentation to view all the configurations parameter.

To deploy the app, just type:

gcloud app deploy

Grab a coffee and take your time, it will take about 5–10 minutes for the deployment starting from uploading our code to Google Cloud Build Repository and setup it in App Engine.

After it finished, type the command below to view the application http address. We are going to test the app using cURL in the next section.

gcloud app browse

Test the App with CRUD

Inside your shell, use cURL to perform following operations to test our API endpoint. Replace the ADDRESS placeholder with your app HTTP address.

Create a Todo

curl -X POST [ADDRESS]/todo \
-H "Content-Type: application/json" \
-d '{"title": "hello kitty", "content": "play it", "dueDate": "2018-10-28T12:39:00Z"}'

Get List of Todos

curl [ADDRESS]/todo

Get Single Todo

curl [ADDRESS]/todo/id

Update Todo

curl -X PUT [ADDRESS]/todo \
-H "Content-Type: application/json" \
-d '{"id": 1, "title": "hello world", "content": "hello Vapor X Swift X App Engine Flex", "dueDate": "2018-10-28T12:39:00Z"}'

Monitor Application Log in Stackdriver monitor

App Engine Flex uses Stackdriver Logging under the hood to provide realtime log for all the server request and response that we can view inside the dashboard in Google Cloud Console.

You can also view your App Engine instances by visiting the App Engine dashboard to monitor various metrics such as CPU utilization, memory, disk, latency, even SSH into your local machine using the dashboard.

!!! After finishing the project, make sure to disable the application from the App Engine Console and stop the Cloud SQL instance to avoid continuous billing.!!

Conclusion

Google App Engine Flexible Custom Runtime provides really powerful and also simple solution to deploy scalable backend sever without managing and worrying about the dev-ops configuration. We can even create microservices architecture by deploying different services of our application inside one project. While it’s very good for smaller startup that have limited human resources to manage the infrastructure, in longer term as our user base are growing, the computing cost can be quite high compared to using infrastructure as a service solution like Google Compute Engine.

In my personal opinion, when our application user base has become larger, company has more resources, and business logic become more complex, we can migrate to Google Kubernetes Engine or Google Compute Engine managed instance group for more flexibility and customization.

Swift2Go

a place where Swift Developers share knowledge.

Alfian Losari

Written by

Mobile, Web, a bit of backend Software Developer and Lifelong Learner. Currently building super app @ Go-Jek.

Swift2Go

Swift2Go

a place where Swift Developers share knowledge.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade