Add type definitions to your Lambda functions
Tags: serverless, aws, lambda, typescript
Published: 2020-03-20 08:36:48

---
title: Add type definitions to your Lambda functions
canonical_url: https://winterwindsoftware.com/fff-aws-lambda-type-definitions/
tags: Serverless, AWS, Lambda, TypeScript
description: Quick tip on how to use TypeScript to help you write Lambda function handlers faster and safer
cover_image: https://winterwindsoftware.com/img/blog-images/api-gateway-handler-types.png
published: true
---
_Every Friday, I will share a small tip with you on something Lambda/FaaS-related. Because Fridays are fun, and so are functions._ 🥳

Early last year, I tried out TypeScript in place of JavaScript after several years of holding off. Now I couldn’t go back to plain JS! I’ll save going into all the reasons why I think you should strongly consider TypeScript for Lambda-based apps for a future article, but for today’s tip I want to show you the [`@types/aws-lambda`](https://www.npmjs.com/package/@types/aws-lambda) type definitions library.

## What problem does this solve?
Lambda functions can have loads of different trigger sources. Each source has its own unique event parameter and response payload schema. Having to look up the docs for each one can be a PITA.

![Long list of Lambda event triggers from AWS Console](https://winterwindsoftware.com/img/blog-images/aws-console-lambda-event-sources.gif)

The `@types/aws-lambda` library gives you handler, event, context and response definitions for most of the major services that can trigger a Lambda function invocation.

By using type definitions, you get autocomplete and type checking built into your IDE. As well as making your initial authoring faster, this also helps you uncover stupid mistakes as you type them instead of having to wait until your code is run.

## Some examples
Let’s look at a few different event trigger handlers to see how we can add type definitions to them.

Before we do, install the NPM package:

```bash
npm install @types/aws-lambda --save-dev
```

Here’s how you add type defs to your API Gateway proxy handler function:

```ts
import { APIGatewayProxyHandler } from 'aws-lambda';

export const handler: APIGatewayProxyHandler = async (event) => {
  console.log('Received event', event);
  return {
    statusCode: 200,
    body: JSON.stringify({ message: 'Success' }),
  };
};
```

No longer will you forget to `JSON.stringify` the `body` field in your API Gateway proxy response as you’ll now get a compiler error if you don’t assign a string to it.

![API Gateway handler type error](https://winterwindsoftware.com/img/blog-images/apigw-handler-type-error.gif)

Wiring up type definitions to an SNS handler is similar:
```ts
import { SNSHandler } from 'aws-lambda';

export const handler: SNSHandler = async (event) => {
  const message = JSON.stringify(event.Records[0].Sns.Message);
  console.log('received message', message);
};

```

No longer will you have to remember or google for the deep selector path to get at the body of your SNS or SQS message as you can easily navigate the `event` object inside your IDE:

![SNS handler type autocomplete](https://winterwindsoftware.com/img/blog-images/sns-handler-type-autocomplete.gif)

It’s important to note that this is a purely compile-time library and emits no run-time Javascript after transpilation. For example, unlike fully static typed languages like C# and Java, you won’t get a casting error if you happen to specify the wrong type on your event parameter.

💌 _If you enjoyed this article, you can [sign up to my newsletter](https://winterwindsoftware.com/newsletter/). I send emails every weekday where I share my guides and deep dives on building serverless solutions on AWS with hundreds of developers and architects._

_Originally published at **[winterwindsoftware.com](https://winterwindsoftware.com/fff-aws-lambda-type-definitions/)**_.