A presentation given by Scott Logic's Matt Searle at the JS Roundabout meetup in London on 9 July 2019, providing an introduction to building serverless APIs in JavaScript, with some tools, tips and best practices for getting started in this new environment.
4. THERE IS A SERVER!
When discussing serverless technologies, what
we’re really talking about is shifting more of
your operational responsibilities to a cloud
provider.
Serverless simply means that you the developer
or your friend the infrastructure engineer are no
longer responsible for grunt work like
provisioning and patching operating systems of
servers and scheduling downtime/failover.
There is a person somewhere in a data
centre managing that server for you
and you don’t need to know about it
7. Some of the Serverless tech on AWS
Lambda
Fargate
SNS
EFSAppSync
AuroraAthena
Kinesis
8. What is the gateway?
The gateway is an entry point for your
application, allowing you to create,
publish, maintain, monitor, and
secure APIs at any scale.
Client applications can use the
gateway to access backend services,
data or business logic by accessing a
RESTful or WebSocket API in Gateway.
API Gateway
9. Lambda
What is Lambda and what’s cool about it?
Lambdas are small independent units of code that literally are a single function.
They’re executed in an entirely managed runtime, meaning you simply upload the
executable and trigger them.
14. ● Separate the core logic of your function
from the boilerplate and other
dependencies
● Take advantage of Execution Context
reuse, limit the re-initialisation of
variables/objects on every invocation
● Minimise your package size
Additional reading:
DZONE Article
AWS Whitepaper
● Control the dependencies in your
function's deployment package. AWS
provides some, but updates them
periodically which could subtly change
your code
● Minimise the complexity of your
dependencies. Prefer simpler frameworks
that load quickly on Execution Context
startup
● There are concurrency limits to be aware
of and by default these are global in your
AWS account. Prefer function-specific
reserved resources
A few best practices when writing lambdas
15. ● Cold start versus warm start execution
performance
● Improving cold start performance is
looking at the runtime environment. JS
and other interpreted languages have
the advantage here
● Small executables for v8 optimisations.
Minify and uglify your code, removing
comments and anything unnecessary
Considerations
16. Shameless self-promotion
Other tools and libraries do exist
I have created a small lightweight tool
which leverages a middleware pattern
to abstract out boilerplate code from
your Lambdas.
Inspired by MiddyJS
Mambda
ChocPanda
20. const lambda = require('mambda');
const AWS = require('aws-sdk')
const myHandler = s3 => (event, context, callback) => {
var params = { Bucket: process.env.BUCKET_NAME, Key: process.env.BUCKET_KEY, Body: process.env.BODY };
// function code...
s3.putObject(params, function(err, data) {
if (err) {
callback(err)
} else {
callback(null, 'Put the body into the bucket! YAY!')
}
});
}
exports.handler = lambda({ init: () => new AWS.S3(), handler: myHandler });
21. Simple Recruitment tool
● 2 Javascript front ends hosted as
static websites within S3 buckets
● Uses a lambda to create signed
urls to upload CVs to another s3
bucket
● Uses lambda to send an SNS
notification to the hiring manager
when a new candidate applies for
a role
● Store the candidate’s name and
any other information in a
DynamoDb database
24. Some things I haven’t discussed
● Using swagger annotations in the JS code to
describe the handler functions and configure
the API gateway
● Setting up development stages and using
blue-green deployments API Gateway
● Increased testability of the modules for
lambda written with Mambda
● Infrastructure as code (Terraform, AWS CDK,
Cloudformation, etc...)