Wpis ten jest kontynuacją artykułu poświęconego na wprowadzenie do świata serverless na platformie AWS. Celem jest zbudowanie usługi obsługującej formularz kontaktowy. W pierwszej części pod tym linkiem, przygotowaliśmy już usługi takie jak SNS i DynamoDb. W tej części zajmiemy się konfiguracją samej funkcji Lambda oraz usługi API Gateway.
Konfiguracja funkcji Lambda
Przyszedł czas na konfiguracje najważniejszej rzeczy w naszym systemie, czyli funkcji Lambda. Tak jak zawsze, wyszukujemy usługę Lambda w konsoli AWS, a następnie przechodzimy do zakładki Functions i klikamy Create function.
W pierwszym kroku konfiguracji deklarujemy nazwę funkcji oraz wybieramy jej środowisku uruchomieniowe. Ja wybrałem tutaj Node.js 12. Jak pokazują statystyki jest to najczęściej wybierane środowisko. W przypadku Lambdy charakteryzuje się ono bardzo szybkim czasem uruchomienia oraz posiada niezliczoną liczbę bibliotek, które możemy zaadaptować do kodu naszej funkcji. Na samym dole, przypisujemy Role IAM dla funkcji. Odnajdujemy tutaj tą rolę, którą w poprzednim kroku tworzyliśmy. Przechodzimy dalej.
Trafimy teraz na główne okno kreatora naszej funkcji. Nie będę się rozwodził tutaj na temat wszystkich opcji jakie mamy tutaj dostępne bo jest tego całkiem sporo. Na początku potrzebujemy kodu naszej funkcji. Do pobrania jest on z mojego Githuba TUTAJ. W folderze lambda-function znajduje się plik lambda.js. To właśnie ten kod JS kopiujemy do naszego edytora funkcji Lambda. Nie wchodząc w szczegóły w kodzie wykorzystane jest SDK dostarczone przez AWS, które pozwala w pełnoprawny sposób wykorzystywać API takich usług jak m.in. DynamoDB czy SNS.
Okno konfiguracji Basic settings jest jeszcze tutaj wartym uwagi. Możemy tutaj zadeklarować jaka wielkość pamięci ma zostać przydzielone naszej funkcji oraz jaki ma być maksymalny czas jej wykonania. Lambda jest efemeryczna, więc jak wiemy nie może się ona wykonywać w nieskończoność. Im krótsze jej wykonywanie tym lepiej. Dla tak prostej funkcji jak nasz w zupełności powinno wystarczyć 128MB RAM oraz timeout na poziomie 5 sekund.
Przed definitywnym utworzeniem naszej funkcji, na tym samym ekranie konfiguracyjnym mamy możliwość przetestowania naszej Lambdy. Na samej górze ekranu klikamy w Configure test events i tworzymy nasz mokowy input danych. Będzie to przykładowo JSON, w podobnej strukturze, tylko uboższy, który później będziemy przesyłać poprzez nasz formularz kontaktowy.
JSON, którego należy tutaj wkleić również znajduje się w repozytorium Github w pliku lambda-test-req.txt
Gdy wszystko już mamy skonfigurowane, klikamy w pierwszej kolejność Save aby zapisać zmiany, które wprowadziliśmy a następnie możemy przetestować działanie naszej Lambdy poprzez przycisk Test. Jeśli wszystko skonfigurowaliśmy poprawnie powinniśmy uzyskac efekt taki jak na powyższym obrazku. Zielony komunikat pokazuje nam, że nasz funkcja wykonała się bez błędów i zwróciła nam kod 200. Dodatkowo widzimy też tutaj logi oraz statystyki, jak długie było wykonanie oraz ile funkcja wykorzystała pamięci. W tym momencie również powinniśmy dostać powiadomienie na adres email, który skonfigurowaliśmy jako subskrybenta topicu SNS. Również w naszej bazie DynamoDB powinien pojawić się pierwszy rekord.
Konfiguracja AWS API Gateway
Mamy już przygotowany prawie cały backend naszej usługi pora na warstwę finalną, czyli wystawienie naszej Lambdy na świat. Do tego celu użyjemy usługi API Gateway. Za jej pomocą jesteśmy w stanie budować interfejsy dla naszych usług np. REST API bądź Websocket API. API GW będzie w naszym przypadku bramą – proxy do naszej funkcji Lambda. Wystawimy sobie za jego pomocą endpoint HTTP, który będzie nasłuchiwał na żądanie typu POST z naszego formularza. Przechodząc do ekranu APi Gateway w celu tworzenia nowego interfejsu klikamy Create API
Mamy tutaj do wyboru kilka opcji. Dla nas najbardziej optymalnym rozwiązaniem będzie wybranie HTTP API, jest to najprostsza i najtańsza opcja, która idealnie pasuje do takich rozwiązań jak nasze. Stosunkowo niedawno AWS wprowadził HTTP API. Wcześniej jedyną możliwością budowania interfejsów opartych o protokół HTTP było REST API, które umożliwia zaawansowaną konfigurację. Jest również przez to droższym rozwiązaniem.
Pierwszy krok to podanie nazwy naszego API i zdefiniowanie integracji z naszą funkcją Lambda
Kolejny krok to zdefiniowanie patha dla endpointu, który będzie nasłuchiwał na nasz wysłany formularz a następnie wykona integrację z funkcją Lambda. W naszym przypadku będzie to zasób /contact obsługujący metodę POST.
Ostatni krok to zdefiniowanie Stage. Każdą zmianę, którą wprowadzamy do naszego API np dodanie nowego zasobu HTTP musimy wdrożyć na Stage aby była on dostępny publicznie. Możemy mieć więcej niż jeden Stage i dzięki czemu np. zdefiniować sobie środowisko testowe i produkcyjne. Zaznaczając opcję Auto-deploy wszystkie zmiany będą automatycznie deployować się do Stage, przez co będą natychmiastowo publikowane w internecie.
Ok, nasz endpoint do odbierania formularza gotowy. Na zakładce Stage powinniśmy zobaczyć pod jakim URL endpoint został wystawiony. Możemy przetestować czy wszystko na tym etapie mamy poprawnie spięte i skonfigurowane. Używaj do tego jakiegokolwiek klienta REST bądź nawet zwykłego curla. Pamiętaj jednak o tym aby do powyższego URL dokleić jeszcze ścieżkę naszego zasoby czyli w tym przypadku /contact
Prawidłowa odpowiedź z naszego serwisu z kodem 200 powinna po poskutkować pojawieniem się kolejnego rekordu w DynamoDB oraz notyfikacją mailową z SNS.
Konfiguracja formularza
W repozytorium Github które załączałem wcześniej znajduje się przykładowy formularz HTML, który możemy spiąć z naszym endpointem aby uzyskać końcowy efekt i przetestować nasz system end-to-end. W pliku index.html w linii 25 należy podmienić parametr action na adres URL z API GW. Plik index.html możemy uruchomić z naszej lokalnej maszyny. Ostatnią rzeczą z jaką prawdopodobnie będziemy się musieli zmierzyć to konfiguracja CORS dla naszego API GW. Domyślna konfiguracja blokuje bowiem żądanie takie jak POST w z domen obcych, aby zapobiec atakom typu CSRF.
Aby tej konfiguracji dokonać wystarczy w ustawieniach API Gateway wejść w zakładkę CORS i dodać możliwość wysyłania żądań typu POST z wszystkich domen. Po tej konfiguracji żądanie z naszego formularza powinna zostać wysłane z sukcesem. Możesz zauważyć jednak, że mimo tego, że wypełniasz w formularzu wszystkie 4 pola, to do DynamoDB trafiają tylko 2 pola. Determinuje to właśnie kod Lambdy. Jako ćwiczenie spróbuj tak zmienić kod funkcji aby zapisywał on wszystkie pola wysłane z formularza. Zachęcam Cię również do upublicznienia formularza HTML w usłudze AWS S3. Instrukcje krok po kroku znajdziesz na moim blogu pod tym linkiem.
To tylko jeśli chodzi o nas praktyczny przykład z zastosowaniem Lambdy. Mam nadzieję, że przykład pomógł Ci lepiej zrozumieć świat Serverless na platformie AWS. Jeśli chcesz być na bieżąco z tego typu materiałami zapraszam na mój Newsletter.
