Yes, I know it looks quite trendy at this time to talk about Serverless architecture and the framework of the same name. Instead of spending time explaining to you what they are, I invite you to read the following articles describing what serverless architecture (https://martinfowler.com/articles/serverless.html) and what the Serverless framework (https://serverless.com/framework) are all about.

Our use case

Our company works with the Google Cloud platform. We are an international business built around a bunch of branded websites. Each brand operates in one or more countries.

All brands use the same core source code but with different features. All of these features can be activated/deactivated whenever we want. Some features are for all websites. Others are more specific to one website.

Technically, it means that you are building all your brands as soon as you are bringing a new feature to your core bundle. Even if your code is composed of multiple apps — such as what Frint, a framework that we use and maintain at Travix, proposes, whenever you merge something to your master branch you have to be sure that your core bundle will have all the necessary features available at any time after deployment.

Each build runs in a Docker image in Google Cloud Container Engine.

If you draw what I have just explained it looks more or less like this:

Now if you are thinking about how it’s maintained in terms of CI / CD, it does get quite tedious and expensive to perform multiple builds throughout the day. In the traditional approach, the applications would be your ancestors. When the build of one of the application happens, it triggers the build of the core website. After the core website is built, all other related builds for the sites are triggered out.

Another issue that you can have with such approach is about the speed of your websites. If you are making everything to be available at any time it means that you are loading lots of unused scripts. And that’s bad.

So how to build the right website when required without having to rebuild the whole thing?

An alternative approach

Such as what the title suggests we will explore how we could solve this problem using Google Cloud Functions. And because we want to be the best hipsters ever let’s bring in to it the Serverless framework for managing our functions and Google Cloud Pubsub.

Google Cloud Functions is the answer of Google Cloud regarding the Serverless architecture. The Serverless framework was briefly introduced at the beginning of the article. In our case, we will see a basic usage of the framework. However, the framework provides a complete set of commands such as rollback, delete and others which can be quite useful when you integrate a new service in your infrastructure.

Pubsub is a message pattern. It means Publish — Subscribe. All the messages are published to “topics”, which are in turn distributing them to the “subscribers”. Google Cloud Pubsub is one solution you can use for triggering your functions. In our case it is adapted because we need to be able to queue the requests and we cannot directly trigger the API (on-going builds).

The Pubsub API lets you decide if a message must be re-sent for a certain period of time. It is called acknowledgment deadline (ackDeadline). For managing your queue when a build is ongoing you can return an error for postponing the message X minutes later. Here we will use the default value, 80 seconds.

The aim is to be able to build ‘site A’ when ‘application A’ is built instead of rebuilding everything because only ‘site A’ uses ‘application A’ at this time.

We need to be able to keep track of the build status of ‘application A’. The application is built in a CI, so when it’s complete, it triggers the ‘core website’ build.

Instead of triggering the ‘core website’ directly, we send a Pubsub message if the build was successful.

The code blocks bellow assume you’re using a *nix OS and has NodeJS 6.11+ with NPM available in your path.

We will also assume that your CI has an API available for triggering builds and this API manages the authentication using HTTP basic authentication.

First step, install the “gcloud” binary. Here is a guide on how to do it: https://cloud.google.com/sdk/downloads

Create a service account from the Google Cloud console. It must have access to the following resources: Google Cloud Functions, Google Cloud Deployment Manager, Google Cloud Storage, Stackdriver Logging and Google Cloud KMS. Here also a link for installing it: https://serverless.com/framework/docs/providers/google/guide/credentials

Now let’s create our directory project and run the following commands in a terminal:

$> mkdir build-trigger
$> cd build-trigger
$> npm init
$> npm install --save serverless
$> $(npm bin)/serverless create --template google-nodejs --path success-handler

Here we installed the Serverless NPM module in our project “build-trigger”. The next step is to create the “success-handler” function using the template for the Google Cloud Functions.

Let’s move into the directory and install everything:

$> cd success-handler
$> npm install
$> npm install --save gcloud-kms-helper

Here we installed the dependencies for the function. We installed as well gcloud-kms-helper . gcloud-kms-helper is a small NPM package I released for encrypting / decrypting secrets using Google Cloud KMS. Go to the Google Cloud Console. Select “IAM & Admin > Encryption keys”. Create a new keyring then create a new key in this keyring.

Now go into your favourite IDE and open the “success-handler” directory.

Edit the “serverless.yaml” as follows:

Here we are using the variables capability of the Serverless framework. Awesome !

Your “env.js” file should look like that:

In this file, we are defining a function which returns an object. The returned object has all the environment variables you use in both your script and your configuration file.

When Serverless deploys your functions it copies the files specified in the “package” property into a zip file which is uploaded in the Google Cloud Storage Bucket. If the “include” property is not defined then everything not defined in “exclude” is uploaded.

Having an environment management solution allows you to deploy your functions in other clusters as well following your workflow.

Let’s now create a small script named “env-generator” in “success-handler/bin” which will generate for us the environment before the upload:

Now open your “package.json” file and add the following script:

{
  // your package.json
  "scripts": {
    "postinstall": "./bin/env-generator"

  }

}

Each time you will run the command “npm install” it automatically generate the “env.json” file for you.

Let’s implement our function. Open the “index.js” file and perform the following modifications:

Our function expects a message with the following format:

{  
  "targets": [

    "site-a"
  ]

}

If the message has the correct format then we decrypt our key and trigger our build using the CI API.

Now let’s deploy our function:

$> rm -rf node_modules && npm i
$> serverless deploy

At first we reinstall the NPM modules to make sure that we have a clean state and our environment config and secrets for communicating with the CI API are properly generated

The framework will take care of creating and uploading the zip file to the Google Cloud servers. Also it will create the Pubsub topic if required.

The next step is to synchronise your system for managing your website settings with your Pubsub topic. This way your build reacts to both builds of your applications and to any modification of your settings.

Let’s assume that you are building your website using a bash script. Let’s create a file named “pubsub.sh”:

Include this bash script in your main build script:

. pubsub.sh

When your build is done and successful just call the method “publish_event”

publish_event "{ target: [ \"site-a\" ]}"

It will publish a message to your topic which in turn will trigger your function.

I hope this article will help you build an even more exciting infrastructure using the Serverless framework. I plan to update to the module gcloud-kms-helper so that it can also handle the keyring and key’s creation automatically for you.

The entire template you can use to get started can be found here: https://github.com/jackTheRipper/gcf-template-env

Enjoy !

In this first article of a serie of 3 we are going to write a test for the root component of the counter-app in the kitchensink example available in the Frint repository on Github.

The sources can be found here: https://github.com/Travix-International/frint/tree/master/examples/kitchensink

I assume that everybody is already aware of what Frint is so let’s start coding.

First, clone the Frint repository. Go to the counter-app directory in examples → kitchensink. Run npm i.

The root component can be found here: https://github.com/Travix-International/frint/blob/master/examples/kitchensink/app-counter/components/Root.js

In our case we will focus on what the component renders.

What do we want to test?

We want to check that our component is correctly rendering. For checking this let’s assert that it contains “<strong>Services:</strong>” and it calls getAppName from the ‘Foo’ and ‘Bar’ providers.

What do we need for the test?

We have to mount the component to have access to its DOM, so we can verify if it contains the elements mentioned before.

To do this, we will use the framework mocha with enzyme.

Here is a basic setup for the “mocha.opts” file:

--colors
--compilers js:babel-register
--require frint-test-utils/register
--require ./test/config/bootstrap.js
--recursive

In the bootstrap file we define all the test utilities.

Now that we are done with the setup, let’s write the first test.

We need to mock the Frint application for mounting the root component :

In our mock, the first item of the providers list is the counter-app’s Root component. Foo and Bar are spies. We will use them for verifying that they have been called. The store defines the initial state of the component.

Writing the test

Now that the mock is created, let’s write the code to test the expected behaviour.

Frint-React function getMountableComponent takes as argument the instance of the mock App we created. It returns a mountable React component that we can mount using Enzyme mount function.

Now that our test is ready, run the following command:

npm test

You should see the test passing.

The sources for the article are available here: https://github.com/Travix-International/frint/tree/master/examples/kitchensink/app-counter

Don’t hesitate to leave a comment if you have any questions regarding the article.

Enjoy !

Frint is a JavaScript framework developed by Travix International.

Better than describing what Frint is I suggest you to take a look at some articles written by Fahad Ibnay Heylaal such as the ‘Introduction to Frint’.

This article is an introduction to a “how-to” guide of 3 articles explaining how to write your unit tests for a Frint application.

Here is the list of articles:

1. Writing a unit test for a Frint-React component
2. Writing a unit test for a Frint application (under construction)
3. Using the Time Travel Debugging with Frint (under construction)

I hope the bunch of articles will help you.

Feel free to suggest some topics if you think that something is missing.