Nowa usługa websocket

Witam serdecznie,
mam do Was pytanie odnośnie architektury jaką mógłbym założyć w swojej aplikacji. Otóż jest to skill na alexe, która póki co działa na moim domowym serwerze (raspberry Pi), jednak chciałbym to wszystko przenieść na chmurę, i zastanawiam się jak to zrobić.

Część tego wygląda tak:

https://drive.google.com/file/d/1A3eCsCaVc7GrJeGiZXG-qrVHuyquhbOM/view

Jest to otwarty czat z Alexą gdzie możemy uczyć się angielskiego zakładając różne scenariusze.

I teraz, chciałbym aby klient mógł zalogować się na swoje konto i widzieć całą konwersację. Czyli czat na żywo.

Z usług jakie znam całkiem dobrze na AWS to Lambda i DynamoDB (choć obecnie wszystko jest wyszukiwane z pliku, ale finalnie ma znaleźć się na Dynamo).
Wykupiłem nawet ostatnio szkolenie z tworzenie czatu na AWS jednak zupełnie mnie zawiodło, bo wykorzystują tam REST API w API Gateway, jednak ja tutaj potrzebuję Websocket (a przynajmniej tak mi się wydaje)

Okazuję się, że AWS zaimplementował Websocket całkiem niedawno, i póki co próbuję się w tym wszystkim odnaleźć, jako że jest dość mało materiałów.

Moglibyście doradzić mi czy architektura jaką zakładam jest ok…

Do wywoływania funkcji Lambda wykorzystuję Alexa Skill, następnie tworzy ona odpowiedz, która wędruję do Alexa. Przy okazji generując websocket, który to spływa do strony internetowej.
Do plików statycznych strony będę potrzebował - S3, do czatu - Websocket w API Getaway, następnie do logowania się - Cognito, a baza danych to DynamoDB (w połączeniu z DAX).

Czyli w tym momencie powinienem mieć dwa triggery w funkcji Lambda - Alexa Skill i API Getaway? Czy dobrze to rozumiem?

Czy jest coś na co powinienem zwrócić uwagę, albo czy macie jakieś inne sugestie jak to mogłoby wyglądać? Z góry dzięki!

Paweł

Cześć Paweł,

Pomogę na tyle ile mogę bo ani z Alexą ani z Websocket’ami nie mam doświadczenia (na mojej liście ToDo są websockety od ostatniego re:Inventu).

Z tego, co wiem websockety będą najlepszym rozwiązaniem tutaj, wszelkiego typu czaty są zawsze używane jako przykłady zastosowań tej technologii. :grin:
Dla mnie Twoja architektura z grubsza ma sens. Natomiast porównaj ją z tą z artykułu poniżej.

Przeczytaj artykuł Using API Gateway WebSockets with the Serverless Framework - Jared wie co robi :smile: i przejrzyj kod, który udostępnił https://github.com/serverless/serverless-websockets-plugin/tree/master/example

Daj znać czy artykuł się na coś przydał?

Hej Paweł,

dzięki za odpowiedz, właśnie siedzę przed lekturą, i już widzę, że minie trochę czasu nim to sobie poukładam w głowie :slight_smile:

A nim to nastąpi, byłbym wdzięczny gdybyś mi coś wytłumaczył. Tak łopatologicznie :slight_smile:

Otóż AWS Lambda jest kontenerem do wykonywania logiki aplikacji - jednak nie generuje własnego URL, dlatego w pojedynkę nie może stworzyć frontu aplikacji. Do tego potrzebujemy np. API Gateway.

I tutaj możemy je wykorzystać do zbudowania REST API.

Jednak stworzenie takiego REST API np. wykorzystując express nie jest trudne - dlatego możemy to zrobić sami, nie angażując kolejnej usług AWS.

Jednak wciąż potrzebujemy tego URL - i tutaj przychodzi nam z pomocą AWS Elastic Beanstalk. Choć wciąż mało o nim wiem, i stąd moje pytanie.

Czy różni się wdrożenie aplikacji przez API Gateway a AWS Elastic Beanstalk. I czy idąc tym tropem, czyli jeśli sam mogę wdrożyć REST API, to tak samo, sam mogę wdrożyć websocket, a następnie połączyć to w AWS Elastic Beanstalk…czy takie coś jest możliwe?

Z góry dzięki! :slight_smile:

Hej,

Pewnie :slight_smile:

Do tego własnie zostało stworzone API Gateway :+1:

W rozwiązaniach serwerowych tak, ale w serverless nie potrzebujesz express do tego. Co więcej, nawet Ci to skomplikuje rozwiązanie. Generalnie masz pryncypium separacji zagadnień (separation of concerns) - czyli jedno rozwiązanie robi jedną rzecz. Tutaj lambda jest odpowiedzialna za logikę, a API Gateway za wejście i wyjście z funkcji. Jak dodasz express do lambdy to ona nagle tez będzie odpowiedzialna za wyjście.

Tutaj się mylisz. Beanstalk nie przychodzi z pomocą. To jest taka usługa AWS, która łączy w sobie inne usługi (wrapper, fasada?) i służy do “prostego” uruchamiania aplikacji serwerowych napisanych w np. java, php, ruby. Beanstalk jest tak samo nie serverless jak wirtualna maszyna EC2 z których on korzysta.

Jak zrobić API endpoint opisałem w Lekcji 4 ale możliwe, że zbyt lakonicznie.

Opisz dokładniej proszę, co ma robić Twój webserwis, jakie metody ma mieć. Może mnie to zainspiruje do zrobienia bardziej konkretnego przykładu w kolejnej lekcji (serio, wymyślanie przykładów jest czasem trudniejsze niż ich programowanie).

Ok poddaję się, najpierw przeczytam wszystkie Twoje lekcje na blogu, a następnie zacznę zadawać pytania :slight_smile:

Tutaj się mylisz. Beanstalk nie przychodzi z pomocą. To jest taka usługa AWS, która łączy w sobie inne usługi (wrapper, fasada?) i służy do “ prostego ” uruchamiania aplikacji serwerowych napisanych w np. java, php, ruby. Beanstalk jest tak samo nie serverless jak wirtualna maszyna EC2 z których on korzysta.

Jak wcześniej wspomniałem, skorzystałem ostatnio z kursów na Udemy gdzie prowadzący użył AWS Beanstalk do uruchomienia aplikacji przez URL publiczny… jednak tak jak mówisz, użyłem tam instancji EC2… Dodatkowo był to kurs odnośnie DynamoDB, a nie “Jak optymalnie wdrożyć aplikację”, stąd chyba takie proste podejście do tego.

A może mógłbyś stworzyć lekcję, gdzie wyszedłbyś z założenia, że mamy prostą aplikację z prostym API, napisaną wykorzystując express (możemy tam dodawać listy TO DO) - i jednocześnie korzystamy z MongoDB.

I teraz jak to przenieść na chmurę aby wszystko optymalnie działało. Czyli czy pozostać przy express, a jeśli nie to dlaczego? Czy pozostać przy MangoDb, czy przenieść wszystko do DynamoDB, dlaczego, i jak to najlepiej zrobić…

Opisz dokładniej proszę, co ma robić Twój webserwis, jakie metody ma mieć. Może mnie to zainspiruje do zrobienia bardziej konkretnego przykładu w kolejnej lekcji (serio, wymyślanie przykładów jest czasem trudniejsze niż ich programowanie).

W mojej aplikacji, użytkownicy (przynajmniej początkowo) będą mogli (poprzez Alexę) jedynie czytać z bazy danych - i to jest jedyna metoda jakiej potrzebuję + ten websocket.

Jednak jeśli opisałbyś powyższy wspomniany przykład, to już by mi pewnie było łatwiej aby to wszystko zrozumieć.

Cześć Paweł,
Postanowiłem wykorzystać Twoją prośbę w taki sposób, aby również pomogła innym osobom. Omówiłem ten projekt w dwudziestominutowym wideo dostępnym na youtube.

To moje pierwsze wideo instruktażowe dlatego będę wdzięczny za konstruktywną krytykę. Niemniej jednak mam nadzieję, że cel udało mi się osiągnąć i ułatwić Ci zrozumienie tego przykładu.

Miłego dnia!

Dzięki wielkie Paweł!

przed ogladaniem musiałem jeszcze przeczytać całego Twojego Bloga, bo wcześniej nie miałem do czynienia z Serverless Framework, ale widze, że faktycznie przyspiesza pracę. Mam jeszcze dwa pytania odnośnie właśnie WS ale to już na YT aby więcej osób skorzystalo…

Pozdrawiam i miłego!