Typy dla funkcji Lambda napisanych w JavaScript

Jeśli potrzebujesz dodać typy do swoich funkcji Lambda napisanych w JavaScript (node.js) to możesz zrobić to bardzo prosto, posługując się wbudowaną w VS Code obsługą JSDoc. Jak to działa w innych edytorach nie wiem, bo od wielu lat nie miałem potrzeby opuszczać VS Code 😃

Typy obejmują zdarzenia oraz inne obiekty, które występują w AWS. Przydają się przy definiowaniu zdarzenia, które wywołuje funkcje Lambda, czyli pierwszego parametru metody handler:

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

Instalując jako zależność deweloperską bibliotekę typów

npm i --save-dev @types/aws-lambda

Możemy dodać te informacje do naszego kodu:

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

Taka mała zmiana pozwala VS Code wyświetlić stosowną listę podpowiedzi, gdy będziemy pisali kod.

Tak to wygląda dla API Gateway HTTP:

Z kolei dla DynamoDB Stream definiujemy event jako DynamoDBStreamEvent i nawet w pętli na tablicy będziemy nadal mieli intellisense:

Taką definicje JSDoc można oczywiście dodać na dowolnej metodzie, nie tylko na handler wywołany przez usługę Lambda. W całej paczce @types/aws-lambda jest ogromna ilość typów, a nie tylko eventy. Do dyspozycji mamy też odpowiedzi i inne obiekty.

Za przykład niech posłuży obiekt context, którego czasem potrzebujemy w funkcji Lambda.

Mam nadzieję, że to małe udogodnienie okaże się dla Ciebie przydatne i złagodzi rozstanie z silnie typizowanymi językami. Artykuł, powstał na bazie tego krótkiego video opublikowanego przez Luciano Mammino.

W tym miejscu chyba warto się powtórzyć (bo dawno temu już o tym pisałem) i odpowiedzieć na poniższe pytanie.

Dlaczego piszę w JavaScript a nie TypeScript?

Przejście z Javy na JavaScript nie było dla mnie ani proste ani przyjemne. Brak typów nie pomagał. Ale to było lata temu i teraz bym już do Javy nie wrócił za skarby świata.

Ale jak to mówią

co boskie księdzu, a resztę wojewodzie…
albo jakoś inaczej mówią ;-)

chodzi mi o to, że nawet dla Javy jest (jeszcze) miejsce na świecie.

Natomiast w funkcjach Lambda zakres problemu i ilość kodu jest tak mała, że typy nie są nam potrzebne, aby się w tym połapać. Zupełnie przypadkowo w ostatnich dniach Yan Cui - AWS Serverless Hero - też o tym pisał, a ja tutaj wklejam jego grafikę i komentarz:

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.
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.

Źródło: Yan Cui na LinkedIn

Podsumowując, lepiej się przełamać i implementować funkcje w JavaScript, niż zaprzęgać TypeScript, tylko po to, aby mieć typy wszędzie. Tym bardziej, że TypeScript pociąga za sobą pewne niedogodności.

Brak definiowania typów explicit jest bardzo wygodny, ponieważ kod jest krótszy i lepiej się go czyta, a czasem nawet można sobie pozwolić na małą dozę szaleństwa 😉