Welcome! I'm a passionate software engineer specialising in cloud and serverless technologies such as AWS and GCP. My blog is mismash of things I have found useful over the years. When I'm not working I can usually be found swimming, cycling or running.

Hey, I’m Ash! A software engineer and keen triathlete.

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.

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:

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

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

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:

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:

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

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.

Then our updated function will look like this:

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

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

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.

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:

To run your function locally you can just run this:

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

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.

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:

Then here's a basic example with the bare minimum to get logs appearing in the right place:

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

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

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 

 standard to describe events in a consistent manner.

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

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

Now we can deploy the function with the following:

Once thats deployed we can publish a message:

And we can check the logs of our function:

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:

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 

, it's for AWS Lambda. It uses the serverless framework and a custom Lambda Layer to provide the PHP runtime.

Cloud Functions and PHP

In this post I'll show you how you can configure SSH keys for your custom Bitbucket Pipe. This requires a tiny bit of setup, as there is no ~/.ssh directory on the docker container. This makes using SSH a little more tricky, especially when you're using tools like git or other deployment tools that hide the actual SSH configuration.

Quick rant: who the heck named custom pipeline tasks "pipes". It's pretty much impossible to Google! I just get pipeline results.

In your shell script you'll just need to add the following:

It's important to copy the id_rsa_tmp AND known_hosts. Without the known hosts file you'll be unable to connect to remote origins. The id_rsa_tmp represents the custom private SSH key that is added into bitbucket pipelines when you follow their guide here: 

https://support.atlassian.com/bitbucket-cloud/docs/variables-and-secrets/#Use-SSH-keys-in-Bitbucket-Pipelines

Make sure ssh is installed on your docker image of course too!

Setting up SSH on custom Bitbucket Pipes

. The reason for doing is so that you can declaritively define certain aspects of BigCommerce configuration in code. At the moment the provider only supports managing webhooks.

Why define webhooks as terraform resources?

This allows us to declaratively define what events are are being consumed, which makes it easy for us to reason our applications infrastructure and it's dependencies. Additionally this terraform code can be applied to multiple environments so that we can ensure they are setup exactly the same.

We can take this a step further when combined with other terraform resources. For example, we can define the destination of our webhook to map directly to a HTTP-triggered GCP Cloud Function that will consume the webhook events:

Just like that we'll have all order events sent to a newly provisioned Cloud Function. This is repeatable, and as mentioned before can be applied to multiple environment to ensure consistency in our configuration.

https://github.com/ashsmith/terraform-provider-bigcommerce/

https://github.com/ashsmith/bigcommerce-api-go/

And the Terraform provider is available in the registry here:

https://registry.terraform.io/providers/ashsmith/bigcommerce/latest

Terraform provider for BigCommerce

Today I created a small CLI utility called ssl-gen. When developing sites or APIs locally, having a trusted SSL certificate locally is always difficult. I can never remember all the parameters, and usually write some horrid bash script. To solve this problem I've created ssl-gen. It will generate your certificate and add it to Keychain so that it is registered as a trusted certificate (getting around those annoying invalid cert errors in your browser!).

Then, to use it you provide your desired certificate name followed by the domains you wish to be on the certificate. The first domain will be the used as the common name.

This will generate ashs-awesome-cert.crt and ashs-awesome-cert.key. These can be used on your webserver such as nginx or apache to serve your local development site on HTTPS.

ssl-gen new also accepts -o / --output which allows you to specify where the certificate will be saved:

Now your certificate will be saved to: ~/.certs/ashs-cert.crt.

Introducing ssl-gen a CLI utility for generating self-signed certificates for macOS

Typescript can be really powerful way of enhancing your react components to ensure the correct props are provided with expected values. Sometimes however you may want some props to required based on what other props have been provided!

Now, our layout prop here might only be able to accept certain values. For example: responsive or fill. So let's convert this example into Typescript:

So now we have correct typed the correct values, what if we wanted to enforce a rule that when layout="fill" is provided you are NOT allowed to define the width or height props. But when layout="responsive" is provided you MUST set them.

Well, to do that we can change our ImageProps type to support exactly this.

Using the Omit utility type we are retrieving all the props that an img element can have, then omitting the src, width and height props. This allows us to redefine them in our type.

Next up we define the src prop as a required string value. The & will merge this with the previous type.

Next up is where the magic happens. We're defining a conditional type, where we're saying that when layout is provided with the 'fill' value it will use the first. Otherwise it'll use the second type.

The Exclude utility type is similar to Omit.

Below is the completed example. You'll notice there is also the toInt function in order to catch when width or height is the never type instead of passing it directly into the img component.

I found this pattern whilst exploring NextJS' Image component: 

https://github.com/vercel/next.js/blob/canary/packages/next/client/image.tsx

, I have attempted to simplify the example here for demonstration purposes.

In this post I also touched on Utility Types (Exclude and Omit specifically). If you'd like to learn more about them you can see the Typescript documentation: 

https://www.typescriptlang.org/docs/handbook/utility-types.html

Conditionally required props with Typescript in React

One of the things I like from other languages like PHP is how you can throw and catch specific exceptions. Replicating this in JS/TS however requires a little extra work.

Now over in JS/TS environments the try/catch block doesn't support handling different instances of errors. Instead we'd need to add if/else or switch conditions inside the body of the catch in order to handle different cases.

However, in Typescript you cannot simply extend Error and expect to be able to use: if (error instanceof MyError) { }... Since Typescript 2.1 extending built-ins like Error, Array and Map may not work as you'd expect.

The workaround for this is to call: Object.setPrototypeOf(this, MyError.prototype) from within your consructor. Like so:

Previously you would have received an instance of Error instead of MyError.

Typescript handles generating the constructor

This approach to handling errors can produce a bit of nesting in your catch block, however it allows to handle each error differently. I find this useful when you're handling multiple scenarios where an error could be thrown, in some instances you may wish to ignore it or hide it.

The above example shows us how we can better control error messages that could be displayed to an end user. Furthermore I'm still exposing the same API you'd expect from Error. Axios in this case adds the response property where we can access the response from the call that was made, if our code could throw two different errors we'd have the muddy our application logic with checks if certain properties exist. However, I've tucked this away within a function that can be used for making those api calls. Our client that is rendering the error only needs to care about accessing error.message.

Ash Smith