GCP has recently added support for PHP 7.4 in Cloud Functions. This post will give you a quick introduction to how it works, and a few pasisng thoughts.

## Prerequisites

If you haven't setup a GCP project before you'll need to go through the sign up process and configure a billing account.

Additionally you'll need to install the `gcloud` CLI: https://cloud.google.com/sdk/docs/install

Once the gcloud cli is installed you'll be able to authenticate with the following command:
```
gcloud auth login
```

## Your first function

Let's start by creating a file named `index.php` with the following:

```php
<?php
use Psr\Http\Message\ServerRequestInterface;

function helloHttp(ServerRequestInterface $request): string
{
    $queryString = $request->getQueryParams();
    $name = $queryString['name'] ?? $name;

    return sprintf('Hello, %s!', $name);
}
```

Hit save. Then open up a terminal in the same directory. To deploy this function we'll run the following:

```
gcloud functions deploy http-php-function \
  --runtime php74 \
  --trigger-http \
  --entry-point helloHttp
```

Feel free to replace `http-php-function` with a suitable name for your test function. It needs to be unique within your GCP project.

As this is a HTTP invoked function the first time you deploy a function it will ask you if you want to allow unauthenticated invocations of the functions. Say yes here for this example.

The command above will output various details, including the trigger url. This will look a little like this:

```
https://us-central1-[your-gcp-project-id].cloudfunctions.net/http-php-function
```

And there it is. Your first PHP function has been deployed on GCP!

If you want to view the logs after invoking the function you can do so with this command:

```
gcloud functions logs read http-php-function
```

> Note: It might take a minute for logs to appear, as there is a slight delay.

### Headers and response codes

By default, if your application code throws an exception then a 500 status code will be returned, otherwise it'll be treated as a 200.

To send different status codes, and headers we'll need our function to return an instance compatible with `Psr\Http\Message\ResponseInterface`. We can use Guzzle PSR7 response object for this.

```
composer require guzzlehttp/guzzle:^7.0
```

Then our updated function will look like this:

```php
use Psr\Http\Message\ResponseInterface;
use Psr\Http\Message\ServerRequestInterface;
use GuzzleHttp\Psr7\Response;

function helloHttp(ServerRequestInterface $request): ResponseInterface {
    $queryString = $request->getQueryParams();
    $name = $queryString['name'] ?? 'world';

    // Sending a 418 I'm a teapot response:
    return new Response(
      418,
      ['content-type' => 'application/json'],
      json_encode(["message" => sprintf('Hello, %s!', $name) ])
    );
}
```

### Third party packages

When your function is deployed if it contains a `composer.json` file then the dependencies will be installed within Cloud Build. If you use a private package registry, then credentials will need to be provided to that context using build environment variables. [https://cloud.google.com/functions/docs/env-var#using_build_environment_variables](https://cloud.google.com/functions/docs/env-var#using_build_environment_variables).

For this you'll want to use the `COMPOSER_AUTH` environment variable. [https://getcomposer.org/doc/articles/authentication-for-private-packages.md#authentication-using-the-composer-auth-environment-variable](https://getcomposer.org/doc/articles/authentication-for-private-packages.md#authentication-using-the-composer-auth-environment-variable)

If the package is listed on packagist then you don't need to do anything else.

Next up I'll touch on local development using GCP's Functions Framework, other ways to invoke functions, and handling application logging.

## Local development

The best way right now to get going locally is to run GCP's Functions Framework. Let's get started by installing the composer dependency into our existing project:

```
composer init -q --name ashsmith/cloudfunctions-php
composer require google/cloud-functions-framework
```

To run your function locally you can just run this:

```
export FUNCTION_TARGET=helloHttp
php -S localhost:8080 vendor/bin/router.php
```

Note that the `FUNCTION_TARGET` environment variable needs to be set, and this needs to match the function you wish to invoke.

You can find out more about the Functions Framework from GitHub: [https://github.com/GoogleCloudPlatform/functions-framework-php](https://github.com/GoogleCloudPlatform/functions-framework-php)

## Application Logging

When you're running serverless stacks you do not have access to the runtime, so it's best to instrument your code with logging to give you plenty of visibility.

GCP has a logging tool called Cloud Logging. In PHP we can write to `stderr` and the logs will appear in Cloud Logging. You can also use the Cloud Logging SDK.

### Writing logs to stderr

```php
<?php

$log = fopen('php://stderr', 'wb');

// Simple log entry.
fwrite($log, "Hello world\n");
```

### Using the Cloud Logging SDK

There are a few drawbacks to using the SDK, namely you need to instrument the invocation id of the function yourself and if you want support with Cloud Trace then you'll also need to include the trace id, as well as specifying the function name and region. Writing to stderr will include all of these attributes automatically. Without them, you'll need to write custom queries to retrieve them from Cloud Logging and they won't appear when viewing logs for your function (it'll need the resource type, function name, and region at the very least).

First up you'll need to install the SDK with composer like so:

```
composer require google/cloud-logging
```

Then here's a basic example with the bare minimum to get logs appearing in the right place:
```php
use Google\Cloud\Logging\LoggingClient;
$logging = new LoggingClient();
$logger = $logging->psrLogger('app', [
  'resource' => [
    'type' => 'cloud_function',
    'labels' => [
      'function_name' => 'your-function-name',
      'region' => 'some-region',
    ],
  ],
]);

$logger->error("hello world");
```

You can grab the function name using the `K_SERVICE` environment variable, but the region you'd need to configure yourself as GCP Cloud Functions do not expose an environment variable for this. You could add a custom environment variable to grab that value (instead of hard coding, as you might want to deploy to multiple regions).

More info on the logging SDK can be found here: [https://github.com/googleapis/google-cloud-php-logging](https://github.com/googleapis/google-cloud-php-logging)

If you want to see a complete example which shows you how to include the function invocation ID, and Cloud Trace ID then here's a gist for you: [https://gist.github.com/ashsmith/69541dc0e406d767e3fa3de978d66677](https://gist.github.com/ashsmith/69541dc0e406d767e3fa3de978d66677)

## Invoke functions using different events

At the time of writing Cloud Functions PHP 7.4 supports HTTP and CloudEvents. What are CloudEvents? In esence they allow us to respond to events trigger within GCP. For example Pub/Sub, Cloud Storage or Firestore. CloudEvents use the [cloudevents.io](https://cloudevents.io/) standard to describe events in a consistent manner.

Let's create a function that responds to messages from Pub/Sub:

First up, create your pubsub topic:
```
gcloud pubsub topics create ash-test
```

Then add to the following function to your existing `index.php` file:

```php
use Google\CloudFunctions\CloudEvent;
function helloEvent(CloudEvent $event): void {
  $log = fopen('php://stderr', 'wb');

  $cloudEventData = $event->getData();
  $pubSubData = base64_decode($cloudEventData['message']['data']);

  $name = 'World';
  if ($pubSubData) {
      $name = htmlspecialchars($pubSubData);
  }

  $result = 'Hello, ' . $name . '!';
  fwrite($log, $result . PHP_EOL);
}
```

Now we can deploy the function with the following:

```
gcloud functions deploy ash-test-event \
  --runtime php74 \
  --trigger-topic ash-test \
  --entry-point helloEvent
```

Once thats deployed we can publish a message:

```
gcloud pubsub topics publish ash-test --message="ash"
```

And we can check the logs of our function:

```
gcloud functions logs read ash-test-event
```

## My thoughts...

Having first-class support for PHP is fantastic. So far you have only been able to run PHP in serverless functions on AWS and Azure, so support coming to GCP is a good thing!

It seems odd to me that they have added PHP 7.4 support and not PHP 8.0 considering thats the latest release. But this has happened with other runtimes in the past. My guess is we'll have support before 7.4 is deprecated..

The logging leaves a lot to be desired right now too. Documentation suggests that structured logs are possible, but I've not been able to get this to work. I think this is due PHP adding additional text to the output:

```
[25-Apr-2021 17:03:09] WARNING: [pool app] child 19 said into stderr: "{"message":"Structured log with error severity","severity":"ERROR"}" 
```

The json string should have been parsed by Cloud Logging, but it still treated it as a plain string. Without being able to at least control the severity in this way makes logging and log-based metrics pretty much useless in a production application.

The alternative is to use to logging SDK I mentioned earlier, but this has drawbacks as I mentioned, and would require significant work to get it where you need it to be useful.

I recongise that PHP 7.4 support is in preview, so hopefully these problems will be resolved in the future.

If you want to use PHP and serverless infrastructure I recommend [bref.sh](https://bref.sh/), it's for AWS Lambda. It uses the serverless framework and a custom Lambda Layer to provide the PHP runtime.

Cloud Functions and PHP

I recently posted about [developing cloud functions with typescript locally](https://www.ashsmith.io/developing-gcp-cloud-functions-locally-with-typescript). This post is a follow where I've tackled a few other issues you might have when developing multiple functions from a single repo.

For example, as dependencies grow you won't want to include all dependencies for all functions as they may not make use of them. Large dependency lists will slow down the deployment of your functions, and can impact cold start times. I've addressed this using yarn workspaces and following a mono-repo pattern that is common when developing node packages.

This approach means we can develop shared libraries that can be packaged and deployed to a private NPM registry. These can then be be included as dependencies on your functions. Whilst developing locally you won't notice much of a difference.

By using this pattern each function can be packaged with it's own package.json and deployed separately. This brought up a new problem. My previous solution used a `src/index.ts` file which imported and exported all functions and was also used as an entrypoint for all requests when developing locally.

To solve this, I have introduced Docker and Docker Compose. Now each function runs in a standalone container. Each container is mapped to a single nginx container which is how you can trigger your functions. I find this approach a lot nicer. Introducing more technologies into this does complicate a bit though, but I believe this has created a more accurate environment.

Let's get started.

## Initial repo structure:
First up, we'll need to setup our initial repo structure like so:
```
docker/
  functions/
    Dockerfile
    start.sh
src/
  functions/
    http/
      helloWorld/
        index.ts
        index.test.ts
        package.json
  packages/
    lib/
      index.ts
      package.json
.eslintrc.json
.gitignore
docker-compose.yml
package.json
tsconfig.json
```

To create those files form the command line:

```bash
mkdir -p docker/functions
touch docker/functions/{Dockerfile,start.sh}
mkdir -p src/{functions/packages}
mkdir -p src/functions/{event,http}
mkdir -p src/functions/http/helloWorld/{index.ts,package.json}
mkdir -p src/packages/lib/{index.ts,package.json}
touch .eslintrc.json docker-compose.yml package.json tsconfig.json
```

So let's quickly talk about this structure. I've tried to keep a logical structure, so all functions are in the `src/functions/{event-type}/{function-name}/index.ts` format. Supported event-types include: `http` and `event`. This just determines which function signature is used `(req, res) => {}` for http, and `(event, context) => {}` for event.

The `packages` directory is where you can add specific packages that will act as your shared code library. Each directory within here must have it's own `package.json` file which a unique package name. These packages will be scoped, but we'll touch on that more later.

Finally the `docker` and any docker named files all relate to how we'll build and run our docker containers locally. If you don't currently have docker installed now would be a good time to do so. Docker for Mac is recommended if you're on a Mac. Docker for Windows for Windows, and you can just install Docker if you're on linux. If you're not familiar with docker, I won't be going into very much detail here, so I'm sorry if I glaze over it!

## Setting up our package.json files.

Currently we have three `package.json` files: `./package.json`, `src/functions/http/helloWorld/package.json` and `src/packages/lib/package.json`. To get these to work with Yarn Workspaces we'll need to first of all make sure we're running yarn 2 from within our project root:

```bash
yarn set version berry
```
(berry is the code name for yarn 2 at the time of writing)

Note that yarn 2 now uses a different binary for each project rather than a global yarn. There are a number of differences in how yarn 2 works.

With that done, let's create our root package.json with the following:
```json
{
  "name": "functions",
  "version": "0.0.0",
  "description": "",
  "license": "Apache-2.0",
  "keywords": [],
  "private": true,
  "workspaces": [
    "src/packages/*",
    "src/functions/http/*",
    "src/functions/event/*"
  ],
  "scripts": {
    "dev": "yarn install && docker-compose up",
    "test": "mocha -r ts-node/register ./**/*.test.ts",
    "lint": "eslint '**/*.ts'",
    "compile": "tsc",
    "fix": "eslint --fix '**/*.ts'"
  },
  "devDependencies": {
    "@google-cloud/functions-framework": "^1.7.1",
    "@types/chai": "^4.2.14",
    "@types/eslint": "^7.2.4",
    "@types/express": "^4.17.8",
    "@types/mocha": "^8.0.3",
    "@types/node": "^14.11.2",
    "@types/prettier": "^2.1.5",
    "@typescript-eslint/eslint-plugin": "^4.5.0",
    "@typescript-eslint/parser": "^4.5.0",
    "chai": "^4.2.0",
    "chai-http": "^4.3.0",
    "eslint": "^7.11.0",
    "eslint-config-prettier": "^6.13.0",
    "eslint-plugin-node": "^11.1.0",
    "eslint-plugin-prettier": "^3.1.4",
    "express": "^4.17.1",
    "mocha": "^8.2.0",
    "nodemon": "^2.0.4",
    "prettier": "^2.1.2",
    "ts-node": "^9.0.0",
    "typescript": "^4.0.3"
  }
}
```

In your `src/functions/http/helloWorld/package.json` add:

```json
{
  "name": "functions-http-hello-name",
  "version": "0.0.0",
  "description": "",
  "license": "Apache-2.0",
  "keywords": [],
  "main": "build/index.js",
  "rootDir": ".",
  "scripts": {
    "start": "functions-framework",
    "test": "mocha -r ts-node/register ./**/*.test.ts",
    "build": "tsc",
    "tsc:watch": "tsc --watch",
    "prezip": "cp package.json build",
    "zip": "cd build && zip -r ../function.zip ."
  },
  "devDependencies": {
    "@google-cloud/functions-framework": "^1.7.1",
    "@types/chai": "^4.2.14",
    "@types/eslint": "^7.2.4",
    "@types/express": "^4.17.8",
    "@types/mocha": "^8.0.3",
    "chai": "^4.2.0",
    "chai-http": "^4.3.0",
    "eslint": "^7.11.0",
    "express": "^4.17.1",
    "mocha": "^8.2.0",
    "typescript": "^4.0.3"
  }
}
```

You'll notice I have duplicated a number of the devDependencies here. This is because each workspace must declare all of their dependencies explicitly.

Then in our `src/packages/lib/package.json`:
```json
{
  "name": "@ashsmith-funcs/lib",
  "version": "1.0.0",
  "license": "MIT",
  "main": "build/index.js",
  "files": [
    "build/**/*"
  ],
  "types": "build/index.d.ts",
  "scripts": {
    "build": "tsc",
    "tsc:watch": "tsc --watch"
  },
  "devDependencies": {
    "@types/chai": "^4.2.14",
    "@types/eslint": "^7.2.4",
    "@types/express": "^4.17.8",
    "@types/mocha": "^8.0.3",
    "chai": "^4.2.0",
    "chai-http": "^4.3.0",
    "eslint": "^7.11.0",
    "express": "^4.17.1",
    "mocha": "^8.2.0",
    "typescript": "^4.0.3"
  }
}
```

With that done we can now run `yarn install`. You'll notice that there is no longer a `node_modules` directory. This is expected, and part of the new functionality provided by yarn 2.

## Setting up Typescript and linting

Previously I was using `gts` for base Typescript and linting. However using yarn 2 these seemed to break as they depend on the node_modules directory existing. Instead of working around it, I decided to remove it. So lets setup eslint and typescript from scratch this time (using the same configs as gts though for now).

Your `eslintrc.json` will look like this:
```json
{
  "extends": [
    "eslint:recommended",
    "plugin:node/recommended",
    "prettier"
  ],
  "plugins": [
    "node",
    "prettier"
  ],
  "rules": {
    "prettier/prettier": "error",
    "block-scoped-var": "error",
    "eqeqeq": "error",
    "no-var": "error",
    "prefer-const": "error",
    "eol-last": "error",
    "prefer-arrow-callback": "error",
    "no-trailing-spaces": "error",
    "quotes": ["warn", "single", { "avoidEscape": true }],
    "no-restricted-properties": [
      "error",
      {
        "object": "describe",
        "property": "only"
      },
      {
        "object": "it",
        "property": "only"
      }
    ],
    "node/no-unpublished-import": ["error", {
      "allowModules": ["@google-cloud/functions-framework"]
    }]
  },
  "overrides": [
    {
      "files": ["**/*.ts", "**/*.tsx"],
      "parser": "@typescript-eslint/parser",
      "extends": [
        "plugin:@typescript-eslint/recommended"
      ],
      "rules": {
        "@typescript-eslint/no-non-null-assertion": "off",
        "@typescript-eslint/no-use-before-define": "off",
        "@typescript-eslint/no-warning-comments": "off",
        "@typescript-eslint/no-empty-function": "off",
        "@typescript-eslint/no-var-requires": "off",
        "@typescript-eslint/explicit-function-return-type": "off",
        "@typescript-eslint/explicit-module-boundary-types": "off",
        "@typescript-eslint/ban-types": "off",
        "@typescript-eslint/camelcase": "off",
        "node/no-missing-import": "off",
        "node/no-empty-function": "off",
        "node/no-unsupported-features/es-syntax": "off",
        "node/no-missing-require": "off",
        "node/shebang": "off",
        "no-dupe-class-members": "off",
        "require-atomic-updates": "off"
      },
      "parserOptions": {
        "ecmaVersion": 2018,
        "sourceType": "module"
      }
    }
  ]
}
```

I won't deep dive into these rules. The only one I want to note is the `node/no-unpublished-import` rule, where I have explicitly allowed the `@google-cloud/functions-framework`. This is to prevent errors from attempting to load type definitions.

`prettier.json`
```json
{
  "bracketSpacing": false,
  "singleQuote": true,
  "trailingComma": "es5",
  "arrowParens": "avoid"
}
```

Next up, our `tsconfig.json`
```json
{
  "compilerOptions": {
    "lib": ["es2018", "dom"],
    "allowUnreachableCode": false,
    "allowUnusedLabels": false,
    "declaration": true,
    "forceConsistentCasingInFileNames": true,
    "module": "commonjs",
    "noEmitOnError": true,
    "noFallthroughCasesInSwitch": true,
    "noImplicitReturns": true,
    "pretty": true,
    "sourceMap": true,
    "strict": true,
    "target": "es2018",

    "esModuleInterop": true,
    "baseUrl": "src",
    "paths": {
        "@ashsmith-funcs/*": [
          "packages/*"
        ],
    }
  },
  "exclude": ["node_modules", "./**/*.test.ts"]
}
```

Now the important part here is the `compilerOptions.paths` section. Here I have stated that all directories within `src/packages` will be mapped to `@ashsmith-funcs/*` so our packages/lib would be referenced in another package as `@ashsmith-funcs/lib`. You'll notice that this is the same name given in the corresponding package.json. This ensures typescript will look for that directory instead of erroring with an unresolved dependency issue.

## Setting up our first function

Ok, let's get into it with our first http function. In `src/functions/http/helloWorld/index.ts` lets add:

```typescript
import type {HttpFunction} from '@google-cloud/functions-framework/build/src/functions';

export const helloWorld: HttpFunction = (req, res) => {
  res.send('Hello, World!');
};
```

In our test file `index.test.ts`
```typescript
/* eslint-disable node/no-extraneous-import */
import chai from 'chai';
import chaiHttp from 'chai-http';
import express from 'express';
import {helloName} from './';

chai.use(chaiHttp);
chai.should();

const app = express();
app.all('*', helloName);

describe('helloName function', () => {
  describe('GET /', () => {
    it('should get return Hello, World! when no query is provided ', done => {
      chai
        .request(app)
        .get('/')
        .end((err, res) => {
          res.should.have.status(200);
          res.text.should.be.a('string');
          res.text.should.equal('Hello, World!');
          done();
        });
    });
    it('should get return Hello, ash! when the query string is added: ?name=ash', done => {
      chai
        .request(app)
        .get('/?name=ash')
        .end((err, res) => {
          res.should.have.status(200);
          res.text.should.be.a('string');
          res.text.should.equal('Hello, ash!');
          done();
        });
    });
  });
});

```

Now run `yarn test` and make sure it all works!

To test the function locally right now we could also run:
```bash
yarn workspaces functions-http-hello-world run start --target=helloWorld
```

This will start up localhost:8080.

This is great, but what about reloading when file changes happen, and what about developing multiple functions?

Lets dive into docker.

## Docker setup.

For this we'll be using docker-compose to configure our different containers. Let's start by creating our docker images.

`docker/functions/Dockerfile`:
```dockerfile
FROM node:12

COPY ./start.sh /usr/bin/start.sh
RUN chmod +x /usr/bin/start.sh

EXPOSE 8080

USER node
WORKDIR /home/node

RUN yarn set version berry

CMD /usr/bin/start.sh

```

Then our `docker/start.sh` script will look like this:
```bash
#!/bin/bash

npx nodemon \
  --watch src/functions/${EVENT}/${FUNCTION} \
  --exec yarn workspace ${WORKSPACE} run start \
    --signature_type=${EVENT} \
    --source=./build \
    --target=${FUNCTION}

```

The `start.sh` script will run as the main command in the container. This will use nodemon to watch for changes to our project, and reload the functions-framework command. Note the environment variables used here. I'm following a strict naming convention here where by: `src/functions/{event}/{functionName}/index.ts` must exist, and must export a function called `{functionName}`.

With this convention we can reuse this docker image for each of our functions, and it helps with deployment processes too.

With our docker images defined. Let's create the `docker-compose.yml` file:

```yaml
version: '2'

services:
  function-proxy:
    image: ashsmith/function-proxy
    ports:
      - "80:80"
    volumes:
      - /var/run/docker.sock:/tmp/docker.sock:ro
    environment:
      - DEFAULT_HOST=functions.local

  tsc-watch:
    image: ashsmith/functions-framework
    build:
      context: ./docker/functions
    working_dir: /home/node
    volumes:
      - ./:/home/node
    command: ["yarn", "workspaces", "foreach", "-ipa", "run", "tsc:watch"]

  hello-world:
    image: ashsmith/functions-framework
    build:
      context: ./docker/functions
    volumes:
      - ./:/home/node
    environment:
      - FUNCTION=helloWorld
      - EVENT=http
      - WORKSPACE=functions-http-hello-world

```

This file defines three services (or containers):

- `function-proxy` which is a custom nginx server.
- `tsc-watch` this will watch all ts files and compile when they change.
- `hello-world` which is our function.

To get this running:
```bash
docker-compose up [-d]
```

If the images don't exist, it will build them and then boot them up.

The `-d` will run in detached mode, so it runs in the background.

The last thing to do is configure your hosts file so that `127.0.0.1` is mapped to `functions.local`:

On mac / linux:

```bash
echo "127.0.0.1 functions.local" | sudo tee -a /etc/hosts
```

Then go ahead and open `http://functions.local/helloWorld` in your browser.

It's worth noting here the ashsmith/function-proxy image uses jwilder/nginx-proxy docker image as a base. This docker image by default allows you to expose containers via this image onto multiple domains (at least 1 domain per container, no shared domains) for each `VIRTUAL_HOST` environment variable that is defined against a given container.

I have customised the nginx.tmpl file so that we have a single server directive and a single domain, but it generates unique `location` directives per container. Instead of using `VIRTUAL_HOST` I use the `FUNCTION` environment variable to achieve this.

That is how our function `helloWorld` will be available on: `/helloWorld`. Nice!

## Adding a dependency...

Now we have a function working. Let's create some shared code...

`src/packages/lib/index.ts`

```typescript
class Logger {
  public static info(...params: any[]) {
    console.info(...params);
  }
  public static warn(...params: any[]) {
    console.warn(...params);
  }
  public static error(...params: any[]) {
    console.error(...params);
  }
}
export { Logger };

```

Ok.. it's kind of useless, but provides a useful example!

Now let's modify our function to use it:

`src/functions/http/helloWorld/index.ts`

```typescript
import type {HttpFunction} from '@google-cloud/functions-framework/build/src/functions';
import {Logger} from '@ashsmith-funcs/lib';

export const helloWorld: HttpFunction = (req, res) => {
  Logger.info('hello world!');
  res.send('Hello, World!');
};

```

Then add it to your functions package.json:
```
yarn workspace functions-http-hello-world add @ashsmith-funcs/lib
```

Now reload the browser, hopefully the page loads successfully. You can also check the logs output from the `docker-compose up` command. To see if our console.log made it. If you used the `-d` parameter then try: `docker-compose logs -f hello-world` to attach and follow the logs for the helloWorld function.

## Final thoughts.

This approach makes managing dependencies on a per function basis possible. I highly doubt this is the last iteration of the cloud function project for me.

This might be overkill for smaller projects, but it's worth keeping in mind if you wish to keep cold start times down and keep deployments lean.

Combined with the terraform deployment process you'll have a capable environment that has best practices at its core.

With this we also have developed some packages that will need to be published to a private NPM repository. I'll cover this step in a future post! As well as how we will need to modify the deployment strategy (if you've seen my post on [using terraform to deploy cloud functions](https://www.ashsmith.io/provisioning-gcp-cloud-functions-with-terraform) then that will serve as a reasonable starting point.


Improved mono-repo for Typescript + Cloud Function development

In this post my goal is to show you how to provision and deploy your GCP Cloud Functions by using Terraform. Infrastructure as Code is a great way to define and keep track of all cloud services you put together. My favourite reasons for IaC is it opens up the ability for peer review, and to ability to have the exact same infrastructure defined in multiple environment without issue.

This post follows on from my previous on [developing GCP Cloud Functions locally with TypeScript](https://www.ashsmith.io/developing-gcp-cloud-functions-locally-with-typescript). It'll be useful to have the same project setup if you're following along, if you want to skip that post you can also [clone down this repo](https://github.com/ashsmith/local-dev-gcp-cloud-functions/tree/developing-cloud-functions) and be sure to use the `developing-cloud-functions` branch (`trunk` includes all the code referenced in this post!).

We'll start by installing Terraform. You can use Homebrew, or download a binary from the Terraform website. However, you may overtime find you're running multiple projects on different versions. For this I recommend [tfenv](https://github.com/tfutils/tfenv). This can also be installed via homebrew if you're on MacOS with: `brew install tfenv`. Check the repo out for additional installation instructions.

Next up let's create the directories and files where we'll be keeping our infrastructure:

```bash
mkdir infra/projects
touch infra/{functions,providers,variables}.tf infra/tf infra/project/{production,test}.tfvars
```

There are a fair few files here. It's worth stating now that terraform is fairly free-form, all files are merged together ultimately so you can organise these as you please.

I have defined three core files: `functions.tf`, `providers.tf` and `variables.tf`.

`functions.tf` is where we'll define our cloud function, along with the storage bucket (for deployment) and the service account the function will use.

`providers.tf` this is where we will configure settings for our terraform providers. This allows us to set the GCP project id for the google provider. In here I have also locked terraform to specific version to prevent people using a different one (to avoid unexpected breaking changes).

`variables.tf` is where we will define global variables.

Next up we have the `projects` directory containing two files: `production.tfvars` and `test.tfvars`. This is where we will define the values of global variables. When we execute terraform we can tell it to use correct tfvars file, so we can have specific settings per project (and change to different gcp projects more importantly!).

Finally we have the `tf` file. This will become an executable that will reduce the verbosity of some the commands we need to run, and helps idiot proof it slightly.

Let's get into it. Starting with our tfvars.

Editing: `infra/projects/production.tfvars`
```
environment = "prod"
project     = "[YOUR-GCP-PROJECT-ID-HERE]"
```

Editing: `infra/projects/test.tfvars`
```
environment = "test"
project     = "[YOUR-GCP-PROJECT-ID-HERE]"
```

Now we need to define this variable in our `infra/variables.tf` file:
```
variable "environment" {}
variable "project" {}
```

So, what we've done above is define two variables, one called `environment` the other `project`. `environment` represents whether we're running in production or another env. This is handy if you want to deploy multiple versions of the same function to the same GCP project. Additionally we have the `project` variable which defines our GCP Project ID. You could make this different between `production` and `test` to truly separate your architecture.

Now let's configure our `infra/providers.tf` file:
```
locals {
  region = "europe-west1"
}

provider "google-beta" {
  project = var.project
  region  = local.region
}

provider "google" {
  project = var.project
  region  = local.region
}

terraform {
  required_version = "0.13.4"
}
```

In this file we have defined a local variable for `region` this configures both the `google-beta` and `google` providers to use the `europe-west1` region. Additionally you can see we're referencing the `project` variable we defined using the `var.project` syntax. Finally you can also see I have locked the version of terraform down to exactly match 0.13.4 (latest at the time of writing).

Ok, let's move onto the beefy file... `infra/functions.tf`.

```
# GCS bucket for storing our uploaded function zip.
# @see https://www.terraform.io/docs/providers/google/r/storage_bucket.html
resource "google_storage_bucket" "function_artifacts" {
  name = "${var.project}-function-artifacts"
}

# GCS Object for our hello_world function zip.
# @see https://www.terraform.io/docs/providers/google/r/storage_bucket_object.html
resource "google_storage_bucket_object" "hello_world_gcf" {
  name   = "${var.environment}_hello_world_gcf/${timestamp()}.zip"
  bucket = google_storage_bucket.function_artifacts.name
  source = "functions.zip"
}

# Define our function
# @see https://www.terraform.io/docs/providers/google/r/cloudfunctions_function.html
resource "google_cloudfunctions_function" "hello_world" {
  # Make the name unique per environment!
  name    = "${var.environment}-helloWorld"
  runtime = "nodejs10"

  # The exported function we wish to execute from within build/src/index.js
  entry_point = "helloWorld"

  source_archive_bucket = google_storage_bucket.function_artifacts.id
  source_archive_object = google_storage_bucket_object.hello_world_gcf.output_name

  # Our service account that only allows this function to write to logs and metrics.
  service_account_email = google_service_account.hello_world_gcf.email

  # Allow our function to be triggered via http requests.
  trigger_http = true

}

# Allow our cloud function to invoked by all users - WARNING this make your cloud function public.
# be sure to check the docs and consider if this is really what you want.
# @see https://www.terraform.io/docs/providers/google/r/cloudfunctions_cloud_function_iam.html
resource "google_cloudfunctions_function_iam_member" "hello_world" {
  cloud_function = google_cloudfunctions_function.hello_world.name
  role           = "roles/cloudfunctions.invoker"
  member         = "allUsers"
}

# A service account just for our helloWorld function.
# this ensures our cloud function only has the absolute minimum needed permissions.
# @see https://www.terraform.io/docs/providers/google/r/google_service_account.html
resource "google_service_account" "hello_world_gcf" {
  provider     = google-beta
  account_id   = "${var.environment}-gcf-helloworld"
  display_name = "${var.environment}-gcf-helloworld"
}

# Add the monitoring.metricWriter role to our service account.
# @see https://www.terraform.io/docs/providers/google/r/google_project_iam.html#google_project_iam_member
resource "google_project_iam_member" "hello_world_gcf_monitoring_writer" {
  provider = google-beta
  role     = "roles/monitoring.metricWriter"
  member   = "serviceAccount:${google_service_account.hello_world_gcf.email}"
}

# Add the logging.logWriter role to our service account.
# @see https://www.terraform.io/docs/providers/google/r/google_project_iam.html#google_project_iam_member
resource "google_project_iam_member" "hello_world_gcf_logging_writer" {
  provider = google-beta
  role     = "roles/logging.logWriter"
  member   = "serviceAccount:${google_service_account.hello_world_gcf.email}"
}

```

Now, there is a lot going on here. So let's break the steps:

1. First of all we define a Cloud Storage Bucket. This is where we will upload our packaged function code.
2. We define the storage object, this will handle uploading our zip that contains the function code. Note that it references `function.zip`. We'll make this zip later on (outside of terraform)!
3. We define our Cloud Function. We're referencing where the function is stored, and the service account we create for it. Additionally we have defined the function to have a http trigger. 
4. Next up we've made sure the function can be executed publicly. By default you won't be able execute the function! Be mindful for your application if you actually need this.
5. Then the next 3 sections define a service account, and then associate the logging.logWriter and monitoring.metricWriter roles to the service account. This SA is assigned to our function, and therefore our function will not be able to interact with any other services other than the above mentioned.

That's quite a lot to take in. I'll break down the terraform syntax below. It's really taken some time to get use to this myself...

Let's go over one of the resources defined line by line to explain:

```
# First we define a resource with: 
# resource "resource_name_from_provider_docs" "my_unique_name"
# the "my_unique_name" will be stored in the terraform state file, and will map to the resources created within GCP.
resource "google_storage_bucket_object" "hello_world_gcf" {
  # Different resources have different properties. The docs are the best place to find out what these fields do.
  # here we've set a name with some string interpolation, this will create a new object called: test_hello_world_gcf/2020-10-12T21:54:44Z.zip
  name   = "${var.environment}_hello_world_gcf/${timestamp()}.zip"

  # Here we're referencing the resource above, and accessing the name property.
  bucket = google_storage_bucket.function_artifacts.name
  source = "functions.zip"
}
```

Hopefully that gives you a little guidance on how terraform resources are defined. As I said before, the docs are the absolute best place to go!

Next up let's set our `infra/tf` file, this will be need to be executable:

```bash
chmod +x infra/tf
```

Then the contents will look like so:

```
#!/bin/bash

VERB=$1
PROJECT=$2

terraform init -reconfigure infra

terraform $VERB -var-file=./infra/projects/${PROJECT}.tfvars -state=./infra/state/${PROJECT}-terraform.tfstate infra

```

What we're doing here initialising terraform and installing the providers. Then the second command is variable it could run `terraform apply`, `terraform plan` or `terraform destroy`. The `$VERB` variable is the first argument we accept from the `tf` script. 

Then we define which variable file will be loaded with the `-var-file` flag. This consumes our second argument `PROJECT` which could be in this case `test` or `production`. Finally the `-state` option allows us to define where the terraform state will be stored, and we'll keep a two different state files based on the project.

When using multiple state files like this you have to ensure all your resources are defined with this in mind. Terraform will not know if a resource already exists and will attempt to recreate. This is why we prefix our terraform resources where possible with the current environment.

> Note: The Terraform state file shouldn't be kept on your local machine. It can contain sensitive values, and if you lose the state file you will have to recreate your infrastructure. In a future post I'll cover managing your state using a remote storage option: https://www.terraform.io/docs/state/remote.html

With this all in place, let's modify our `package.json` to include the commands for running terraform:

```diff
-   "compile": "tsc",
+   "compile": "tsc && yarn tf:format",
    "fix": "gts fix",
-   "prepare": "yarn compile"
+   "prepare": "yarn compile && zip -r functions.zip build && zip -g functions.zip {package.json,yarn.lock}",
+   "tf:format": "terraform fmt -recursive infra",
+   "tf:plan": "yarn prepare && ./infra/tf plan",
+   "tf:plan:test": "yarn tf:plan test",
+   "tf:plan:prod": "yarn tf:plan production",
+   "tf:deploy": "yarn prepare && ./infra/tf apply",
+   "tf:deploy:test": "yarn tf:deploy test",
+   "tf:deploy:prod": "yarn tf:deploy production",
+   "tf:destroy:test": "./infra/tf destroy test",
+   "tf:destroy:prod": "./infra/tf destroy production"
```

That's a lot of commands... However the goal here is to make it obvious which commands are being run. When you run `yarn tf:deploy:test` it will compile your code, and format your terraform code (they have their own standard format), next up we'll package the build dir and package.json + yarn.lock files into a zip. Then finally we run `./infra/tf apply production` this will instruct terraform to create the resources.

Additionally we have an option for `tf:plan:{ENV}` too, this will show a diff of what will change if you run apply. This can be handy for sanity checking and testing changes without applying.

With a little luck you'll be able to run `yarn tf:deploy:test` and you'll have your newly provisioned infrastructure in no time!

> Note: I have assumed you have setup a GCP Project, linked to a billing account.
> You will also need to configure the [gcloud cli and authenticated](https://cloud.google.com/sdk/docs/install)
> You may also need to enable the [Cloud Build API](https://console.developers.google.com/apis/api/cloudbuild.googleapis.com/overview)

Provisioning GCP Cloud Functions with Terraform

In this post I'll show you how I develop Cloud Functions locally using Typescript! I assume you already have some familiarity with Typescript, so we'll dive straight in with getting our project setup.

For this we're going to use Google's typescript style guide tool, [gts](https://github.com/google/gts).

> `gts` provides us with an no fuss, opinionated, TypeScript setup. It includes a style-guide with linting and auto-fixing. For me this just gets rid of the pain of configuring new projects! `gts` is extendable, so if you disagree with the style guide then you're more than welcome to customise away to suit your team / project.

```bash
mkdir my-cf-project
cd my-cf-project
# use --yarn if you want to use yarn as your package manager, omit for npm.
npx gts init -y --yarn
```

If you run a quick `ls` of the current directory you'll see that `gts` has setup your TS project. Excellent!

> Note: You can use the `yarn lint` and `yarn fix` commands to lint and automatically fix most formatting problems in your code. You can also configure your IDE to do this too.

Next up, we need a way of running Cloud Functions locally. For this we can use Google's Functions Framework. Over on their github you'll see various run times for NodeJS, PHP, Python and more. For us, we're using their NodeJS library.

We can add that as a dev dependency, along with the `@types/express` to include the express packages TypeScript definitions (without this you may get an error from `tsc` saying it couldn't find the type definitions).

```bash
yarn add -D @google-cloud/functions-framework @types/express
# or if using npm:
npm install --save-dev @google-cloud/functions-framework @types/express
```

In addition to this we'll need the following packages too: `concurrently` and `nodemon`. This will allow us to use nodemon to restart our functions framework CLI tool whenever files change, and continuously watch and recompile our TypeScript code.

```bash
yarn add -D concurrently nodemon
# or if using npm:
npm install --save-dev concurrently nodemon
```

Then we'll need to modify our `package.json` to add our new scripts:

```json
{
  ...
  "scripts": {
    "start": "functions-framework --source=build/src/ --target=helloWorld",
    "watch": "concurrently \"tsc -w\" \"nodemon --watch ./build/ --exec npm run start\"",
    ...
  },
}
```

So here our `start` script will define the `build/src` directory as the source for our function and then `--target=helloWorld` defines our function which will be executed when requests come into the functions framework (via http requests).

Next up, lets create replace `src/index.ts` with the following:

```typescript
import type {HttpFunction} from '@google-cloud/functions-framework/build/src/functions';

export const helloWorld: HttpFunction = (req, res) => {
  res.send('Hello, World!');
};
```

With that done, we're ready to test! You can use the `watch` command to compile and run your application for development.

```bash
yarn watch
# or:
npm watch
```

And, with a little luck, you can open up http://localhost:8080/ and you'll see `Hello, World!` in your browser!

### But wait, what about developing multiple functions!?

This solution is great if you want one repo per function, or to manage each function with it's own configuration per directory. Over time however this will become more cumbersome to manage. So let's refactor this a little and get it working for multiple functions.

It's worth saying that at the time of writing Google's Function Framework does not currently support developing multiple functions. Therefore, we need a little hack.

The best way I've found is to have a single entrypoint function, which then based on the URL path will route through to your individual functions. This works perfectly for any HTTP functions you have. I'll cover other functions in another post.

So with that in mind, rename your `src/index.ts` to `src/helloWorld.ts` and create a new `src/index.ts`

In the newly created `src/index.ts` you'll want to receive the request then route it through to your `helloWorld.ts` function. Like so:

```typescript
import type {HttpFunction} from '@google-cloud/functions-framework/build/src/functions';
import {helloWorld} from './helloWorld';

const ROUTES = [
  {
    pathRegex: /^\/helloWorld/,
    function: helloWorld,
  },
];

export const index: HttpFunction = (req, res) => {
  const routes = ROUTES.filter(route => req.path.match(route.pathRegex));
  if (routes.length === 0) {
    throw new Error(
      'Unknown path, have you defined your function in src/index.ts?'
    );
  }

  const [entrypoint] = routes;
  return entrypoint.function(req, res);
};

export {helloWorld};

```

> You may noticed the last line: `export {helloWorld};`, why am I doing this? Well GCP Cloud Functions don't allow you specify which file and which function to execute. By default it will look for either `index.js` or `function.js`. Therefore to deploy any of our functions they will need to be exported from our `index.ts` file too.

You'll then need to modify your `package.json` start script to point to your exported `index` function:

```diff
+   "start": "functions-framework --source=build/src/ --target=index",
-   "start": "functions-framework --source=build/src/ --target=helloWorld",
```

Now with this solution you can add a new object into the `ROUTES` constant any time you wish to add a new function to be triggered, along with a path regex to match. I also throw an error when no routes are matched with a handy message to help guide the developer as to what might be wrong.

It isn't perfect. But we can make additional modifications along the way if we need. For example, you may expect the request path (`req.path`) for your function to be empty (i.e. routing to the index `/` of the cloud function domain). That can be achieved by adding `req.path.replace(entrypoint.pathRegex, '');` before you execute the function on line 20. So our new `index.ts` will look like this:

```diff
  const [entrypoint] = routes;
+ req.path.replace(entrypoint.pathRegex, '');
  return entrypoint.function(req, res);
```

### What about testing?

For testing we'll use mocha, chai and chai-http. However, before we can install these dependencies we will need to make a small change to our `tsconfig.json`. Due to a dependency on `chai-http` that expects some browser based types/interfaces to be defined. So, under the `compilerOptions` object we'll add `"lib": ["es2018", "dom"]`, and we also need to add `"esModuleInterop": true,` so that `chai` and `chai-http` can be imported using es6 import syntax.

```diff
{
  "extends": "./node_modules/gts/tsconfig-google.json",
  "compilerOptions": {
    "rootDir": ".",
    "outDir": "build",
+   "lib": ["es2018", "dom"],
+   "esModuleInterop": true,
  },
  "include": [
    "src/**/*.ts",
    "test/**/*.ts"
  ]
}

```

Next up, let's add our dependencies for testing:

```bash
yarn add -D express ts-node chai chai-http mocha @types/chai @types/mocha
```

Next modify our `package.json` to include our test script:

```diff
-    "test": "echo \"Error: no test specified\" && exit 1",
+    "test": "mocha -r ts-node/register test/**/*.test.ts",
```

Then let's create a simple test for our `helloWorld` function:

```
mkdir test
touch test/helloWorld.test.ts
```
For our `test/helloWorld.test.ts` file:
```typescript
import chai from 'chai';
import chaiHttp from 'chai-http';
import express from 'express';
import {helloWorld} from '../src/helloWorld';

chai.use(chaiHttp);
chai.should();

const app = express();
app.all('/', helloWorld);

describe('helloWorld function', () => {
  describe('GET /', () => {
    it('should get return hello world', done => {
      chai
        .request(app)
        .get('/')
        .end((err, res) => {
          res.should.have.status(200);
          res.text.should.be.a('string');
          res.text.should.equal('Hello, World!');
          done();
        });
    });
  });
});
```

Now you can run `yarn test` and see that our tests are working wonderfully!

![tests passing!](//images.ctfassets.net/hoagspxz8z3s/3i2ffM1orrfeAkFJbNIlE3/30a360b60b08b9b8abbeae3c299d909c/image.png)

### Any other considerations?

This approach works well for small http based functions. There are a few other things you may want to think about for your project:

- What about other events which trigger your cloud functions (PubSub events perhaps?)
- Will your dependencies grow larger overtime? You may need to split functions up to keep dependency sizes down (however, don't run before you can walk.). Dependencies may have a negative impact on your function cold start times.
- How does this impact your deployment strategy? You package the `build/src` directory along with your `package.json` and `yarn.lock`/`package-lock.json`

### Conclusion

There you have it, a simple way to develop your HTTP based cloud functions locally using Typescript! Hopefully this has helped you setup a new project, or reconsider the way you're currently developing cloud functions.

Ash Smith

Cloud & Serverless Developer

Serverless Posts

Cloud Functions and PHP

Improved mono-repo for Typescript + Cloud Function development

Provisioning GCP Cloud Functions with Terraform

Developing GCP Cloud Functions locally with Typescript