Learn by practice, czyli mini-projekt oparty na usługach AWS

W ramach praktyki chcę poczynić niewielki i w miarę prosty (relatywnie) projekcik, który z założenia ma działać w 100% w oparciu o usługi AWS. Zacząłem sobie nad nim dumać i myśleć i doszedłem do wniosku, że potrzebuję wskazówek i wsparcia osób bardziej doświadczonych ode mnie - mój perfekcjonizm nie pozwala mi na zrobienie go w stylu “good enough”. Cel - przez naukę do finalnego rezultatu. Kody źródłowe wraz z dokumentacją, założeniami, itp. udostępnione na GitHub, tak by wypracowane rozwiązanie mogło przysłużyć się innym osobom, które chcą lepiej poznać AWSa :slight_smile:

Projekt

Dziennik korespondencji. Z poziomu przeglądarki można zarządzać korespondencją przychodzącą i wychodzącą - dodawanie, edycja, usuwanie. Potrzeba do tego front-endu, API, bazy danych, a wszystko to można zbudować w oparciu o usługi AWSa.

Wymagania funkcjonalne

  • Wyświetlanie listy całej korespondencji (przychodzącej i wychodzącej) + wsparcie stronicowania
  • Wyszukiwanie korespondencji po zadanych parametrach, np. numer korespondencji, nadawca/odbiorca, data odbioru/wysłania
  • Wyświetlanie informacji nt. konkretnej korespondencji,
  • Możliwość dodania/edycji/usunięcia korespondencji,
  • Każda korespondencja oznaczana jest automatycznie generowanym numerem - NUMER/MIESIĄC/ROK. Co ważne, kolejny numer w miesiącu musi zachowywać ciągłość, nie może być “gapów” pomiędzy nimi,

Tech-stack, usługi AWS

Moje wyobrażenie, założenia odnośnie stacku technologicznego, usług AWSa są następujące:

  • Front-end w React.js, serwowany z S3 via CloudFront,
  • API z użyciem API Gateway i Lambda,
  • DynamoDB,

No i teraz jakie trudności napotkałem do tej pory, na czym się zawiesiłem, by sensownie do tego podejść i ruszyć z tym:

  • Ponieważ kolejne numery korespondencji w miesiącu muszą zachować ciągłość, jak je generować?
  • Infrastructure as a Code - myślę o CloudFormation + Serverless Framework. Jak ugryźć CloudFormation? Robić wszystko w jednym template, rozbijać na kilka z podziałem na warstwy biznesowe/funkcjonalne czy architektoniczne?

Podsumowując - jak zacząć? To jest ściana mentalna, którą ciężko mi w tym momencie przeskoczyć. W przypadku gdybym miał to stawiać na VPSie to potrafię to poskładać sobie w głowie, zbudować odpowiednie klocki, tutaj jest trudniej.

Jakie jest wasze zdanie? Co możecie zasugerować? Od czego zacząć? Albo być może moje założenia, podejście są błędne i należałoby je wywrócić do góry nogami?


Developers. :rocket: Start your engines and may the :cloud: Cloud be with you!

Przemek,

Mam bardzo mało czasu, więc bardzo lakonicznie odpowiem.

Robisz fizycznie dwa projekty a) backend w Serverless Framework, b) frontend

W a) definiujesz wszystkie zasoby potrzebne dla backendu (funkcje, bazy, kolejki itp) - technicznie to moze byc jeden plik yaml lub kilka (SF to wspiera)

W b) robisz normalny projekt Reactowy + plik CloudFormation do hostowania statycznej apki w JS. Tak jak napisałeś S3 + CloudFront ode mnie jeszcze Route53 z domeną i Certificate Manger abyś miał HTTPS z certyfikatem swojej własnej domeny

Oba projekty sa w sumie niezależne i tylko spięte przez endpointy, ktore mozesz zrobic statyczne przez domene np. db-dev.domena.com itd. aby nie zmieniać kodu przy kazdym deploymencie. React moze sam ogranąć pod jaka domeną działa i na tej podstawie wybrać sobie endpointy.

Wszystko, wszystko z użyciem SF? Nawet jeśli byłaby sytuacja, że jakieś zasoby AWSa mogą nie być ściśle związane z tą częścią projektu?

Na razie z Twojego opisu nie widzę takich zasobów. No teoretycznie to HostedZone w Route53 dla domeny (moze tez byc kilka hostedzone, kazde per stage).

Projekt powinno sie dać wdrożyć minimalną liczbą kroków i tak aby równocześnie można było mieć wiele jego instancji.

Przykladowo zamiast hardkodować w S3 nazwę wiaderka jako dupa piszesz ${stage}-dupa (lub w ogole generujesz randomowa nazwę dla zasobu) i wtedy możesz deployować na różnych środowiskach ten sam projekt i nie ma konfliktu, że zasób już istnieje.