• CloudPouch NEW!
  • Akademia
  • Blog
  • O Serverless
  • O stronie

Typy dla funkcji Lambda napisanych w JavaScript


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:

1
2
3
4
5
const handler = async (event) => {
// extract data from event
const response = '...'
return response
}

Instaluj膮c jako zale偶no艣膰 dewelopersk膮 bibliotek臋 typ贸w

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

Mo偶emy doda膰 te informacje do naszego kodu:

1
2
3
4
5
6
7
8
9
10
/**
*
* @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:
Typy dla funkcji Lambda napisanych w JavaScript
Z kolei dla DynamoDB Stream definiujemy event jako DynamoDBStreamEvent i nawet w p臋tli na tablicy b臋dziemy nadal mieli intellisense:
Typy dla funkcji Lambda napisanych w JavaScript

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.
Typy dla funkcji Lambda napisanych w JavaScript

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:

Yan Cui wie偶owiec

In a Node.js app, say, an Express.js API, the complexity ceiling is really high - multiple abstraction layers, lots of modules and a 鈥渦ser鈥 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鈥檛 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 馃槈