Quick review of the changes in Apex v0.5.0 for managing AWS Lambda functions, and thanks to the team for the contributions!
The first little improvement we’ve made is that newer releases of Apex can upgrade themselves via `apex upgrade`:
Run commands with hooks
Hooks may be defined in project.json, or individual function.json files, and allow you to execute arbitrary commands at different points in the Apex life-cycle. Currently we have “build”,“clean”, and “deploy” hooks.
Here’s an example of using a transpiler (CoffeeScript) on “build” so that it is re-compiled for every deploy (or `apex build` command). The “deploy” hook by contrast is only executed for deploys, and may be better suited for running tests for example.
Internally we’ve refactored Apex to utilize these hooks in order to implement the runtimes previously supported. For example when you use runtime “golang” it simply injects a “build” and “clean” command for you.
Omitting files with .apexignore
Maciej Winnicki implemented .apexignore support. The .apexignore file can be used in the project root, or function directories. This file is analogous to .gitignore which you’re probably familiar with, but allows you to specify patterns which will be used to omit files from the Lambda zip file.
For example you may want to omit all of your Go source, since only the binary is required for deployments:
Log output and tailing
Pilwon Huh refactored the CLI to use Cobra instead of Docopt which scales better, and adjusted logging so that tailing is no longer the default. You may use `apex logs <name>` to return recent logs, and `apex logs -f <name>` to follow.
It’s worth noting Apex also supports filtering log output with `-F` which I forgot to mention in the last post.
We added support for setting environment variables via the flag`-e` (can be used multiple times), and within project.json or function.json files:
Because Lambda doesn’t natively support enviromment variables, a .env.json file into your Lambda function’s zip file which is later loaded by the runtime. Run with debug level logging to see how this works:
Johannes Boyne implemented a new metrics command which outputs CloudWatch metrics for a function within a given duration (24hr by default).
Invoke with optional context
Previously Apex required that you specify the “event” object, along with optional “context” object. This tripped a lot of people up (including myself) that just wanted to pipe in an event.
Now we detect both cases and you can just stream the event object directly.
You may now also specify the concurrency used for deploys, which defaults to 5:
$ apex deploy --concurrency 10
$ apex deploy -c 1
Boilerplate with Terraform
We don’t have any concept of project scaffolding yet, and while we aren’t coupled to Terraform at all, I do recommend using it for configuring AWS resources. I’ve started the apex/boilerplate repo that you can clone to get started, which will likely include a more complex example at some point.
We now also have a Slack channel!