Add types to your JavaScript Lambda functions
Tags: aws, serverless, lambd, javascript
Published: 2022-10-29 15:48:01

If you need to add types to your Lambda functions written in JavaScript (Node.js) then you can do it very easily, using VS Code's built-in JSDoc support. How it works in other editors I don't know, because I haven't had the need to leave VS Code for many years 😃

Types library includes events and other objects that occur in AWS. They come in handy when defining an `event` that calls Lambda functions, which is the first parameter of the `handler` method:

```JavaScript
const handler = async (event) => {
  // extract data from event
  const response = '...'
  return response
}
```

By installing this library as a dev dependency
```
npm i --save-dev @types/aws-lambda
```
we can add this information to our code:

```JavaScript
/**
 *
 * @param {import('aws-lambda').APIGatewayProxyEventV2} event
 * @returns
 */
const handler = async (event) => {
  // extract data from event
  const response = '...'
  return response
}
```

Such a small change allows VS Code to display a relevant list of prompts as we write code. 

This is what it looks like for the API Gateway HTTP API:
![Types in JavaScript](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/tir0ki51d1etb3me0ldy.png)

My next Lambda function is triggered by DynamoDB Stream, so we define `event` as `DynamoDBStreamEvent`. Please notice that even inside the loop editor prompts valid types in sub-properties:

![Types in JavaScript](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/har8p0h824sc14xukpuj.png)

Of course, JSDoc definition can be added on any method, not just on the `handler` called by the Lambda service. You can annotate any JavaScript function that process AWS type with this method to have better *intellisense*. 

There is a huge number of types in the whole package [`@types/aws-lambda`](https://www.npmjs.com/package/@types/aws-lambda), and not just *events*. We also have *responses* and other objects available.

As an example, consider the `context` object, which we sometimes need in a Lambda function.

![Types in JavaScript](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/5x74vxb62v19ljr4edho.png)

I'm sure you will find this small convenience useful.  I hope it would ease switching from strongly typed languages to JavaScript. This article, was based on this [short video](https://www.youtube.com/shorts/60zUEc_vs1o) published by [Luciano Mammino](https://loige.co/).

At this point, it's probably worth repeating myself (since I wrote about it a long time ago) and answer the following question.

## Why am I writing in JavaScript and not TypeScript?

The transition from Java to JavaScript was neither easy nor pleasant for me. The lack of types didn't help. But that was years ago and now I wouldn't go back to Java for the world's sake.

Of course, there is still (for some time) place for Java in this world. 😉

However, **in Lambda functions the scope of the problem and the amount of code is so small that we don't need types** to understand what's going on. By complete coincidence, in recent days Yan Cui - AWS Serverless Hero - also wrote about this, and I paste his graphic and comment here:


![Yan Cui's skyscraper](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/4q2ikbzkz1prl3wbz5tw.png)

> In a Node.js app, say, an Express.js API, the complexity ceiling is really high - multiple abstraction layers, lots of modules and a "user" variable can mean different things every time you see one. Types are crucial for managing that complexity and communicating intent.<br/>But the complexity ceiling of a Lambda function is much much lower. I only need to look at 2/3 modules to understand what the function does. To the point that the (relatively small) overhead of bringing in TypeScript just doesn't feel necessary in most cases.

Source: [Yan Cui in LinkedIn](https://www.linkedin.com/feed/update/urn:li:activity:6986994844820725760/)

The bottom line is that it's better to break through and implement functions in JavaScript than to harness TypeScript, just to have types everywhere. Especially since TypeScript entails some inconveniences.

The lack of defining *explicit* types is very convenient because the code is shorter and easier to read, and sometimes you can even go a little bit crazy with it... 😉