Posted by Minął już 5 rok odkąd pracuję na stanowisku programisty. Największa zmiana od poprzedniego podsumowania to zmiana technologii, w jakiej pracuję, a mianowicie z PHP przeszedłem na NodeJS.
Tradycyjnie zacznę od tego co udało się zrealizować z planów z poprzedniego roku.
Moja infrastruktura inteligentnego domu rozwija się powoli, ale, za to sukcesywnie na przód. Niestety koszt rozwoju i utrzymywania poprzednich urządzeń zabiera trochę czasu i ogranicza tworzenie nowych, ale nie ma co narzekać, póki widać postęp 😉
Na ML oraz AI jak zwykle nie starczyło czasu, więc zobaczymy co przyniesie ten rok. Za to udało się ruszyć z Pythonem, gdyż miałem go na studiach u musiałem poznać podstawy oraz wiele więcej, jak budowanie aplikacji webowej opartej o framework Flask, uwierzytelnianie oparte o Googla i wiele innych.
Z asynchroniczną komunikacją miałem już do czynienia, szczególnie z MQTT oraz NATS’em, niestety Rabbit’a nie skonfigurowałem jeszcze na własne potrzeby, ale mam cel w tym roku się tym zająć.
Co nowego się nauczyłem:
Kubernetes
W obecnej pracy cały deployment na środowiska mamy skonfigurowany na kubernetesie, więc poznanie go przyszło samo. O ile nie konfigurowałem jeszcze nic na nim, o tyle miałem doświadczenie w pracy z nim. Rozumiem pojęcia node, pod, helm, template, chart, deployment i wiele innych. Mniej więcej wiem jak działa deployment oparty o niego i jakie ma to zalety, szczególnie, kiedy mamy architekturę mikroserwisową w monorepo.
NestJS
Jest to naprawdę bardzo dobrze napisany framework dla NodeJS. Zawiera w sobie dużo gotowych modułów, np. dla mechanizmu DependencyInjection, CQRS, WebSocketa. Działa to sprawnie i szybko. Wspiera również podejście architektoniczne bazujące na modularnym monolicie i całkiem dobrze sobie z tym radzi. Dla mnie osobiście jest to póki co najlepsze rozwiązanie, jeżeli planujemy programować aplikację w NodeJS z użyciem TypeScripta.
Monorepo
Podejście mikroserowisów wiąże ze sobą duże obciążenie infrastrukturalne, osobne popeliny, deploye, zbieranie logów itd. Jeżeli mamy ich kilka i są one w tej samej technologi (chociaż to nie jest wymóg) to zauważymy, że bardzo dużo rzeczy się powtarza jak np. skrypty deployu, budowania, testowania itd. Pomocne może się okazać tutaj mono repo, gdzie wszystkie mikroserwisy trzymamy w jednym repozytorium, co sprawia, że część rzeczy możemy uspójnić, dzięki czemu mamy mniej elementów do utrzymania. Uruchomienie całego środowiska jest prostsze, wystarczy jeden docker-compose.
Wady tego rozwiązania są np., długo trwające CI oraz CD, aby wykonywać osobny deploy każdego mikroserwisu trzeba się namęczyć. Również wersjonowanie na gicie jest utrudnione, gdyż nie można użyć drugi raz tego samego taga.
Osobiście nie jestem zwolennikiem monorepo, wolę jednak każdy mikroserwis trzymać w osobnym repozytorium 😉
Forking workflow
Jest to ciekawe podejście do pracowania nad aplikacją, gdzie każdy programista posiada forka jednego głównego repo, gdzie znajduję się tylko jeden główny branch. Kiedy chcemy dokonać jakichś zmian, pobieramy zmiany z głównego repo, do naszego, albo wychodzimy branchem od razu z niego, ale na własnym forku. Pracujemy i tworzymy branche jak chcemy. Potem robimy commita i MR do głównego repo. Zaletą tego porządek w głównym repozytorium, ponieważ wszystkie branche, jakie zrobimy zostają w naszym forku. Osobiście wolę jednak pracę na jednym repozytorium.
Grafana & Prometeusz
Są to dwa narzędzia bardzo ułatwiające monitoring i dbanie o aplikację. Prometeusz jest mechanizmem, który zbiera statystyki na temat aplikacji, liczbę requestow, błędów, 500 i wszystkiego, co tylko chcemy. Dzięki bibliotekom do języków możemy pompować do niego własne statystyki, np. o liczbie rejestracji itd. Grafana natomiast jest GUI umożliwiającym prezentację statystyk np. właśnie z Prometeusza. Wpinamy sie odpowiednim endpointem pod ktorym dostępne są dane i Grafana pokaże nam je wszystkie na wykresach. Możliwości tego są bardzo duże. Jak tylko znajdę czas wdrożę te dwa narzędzia do swoich aplikacji.
Eventsourcing
Bardzo spodobało mi się to podejście do planowania, gdzie na początku wypisujemy wszystkie eventy, które dzieją się w naszej aplikacji, jakie przyjdą nam do głowy. Potem zaczynajmy je grupować szukając wspolnych kontekstów i na końcu dzięki temu możemy zobaczyć jak tak naprawdę podzielić nasz system na serwisy oraz utworzyć odpowiednie historyjki użytkownika. Pewnie uprościłem bardzo ten proces, ale moim celem było tylko z grubsza opisanie jak to działa.
Nats
Poznałem kolejny bardzo ciekawy system kolejkowy, szczególnie zalecany do świata IoT. Oferuje kilka rozwiązań, jakimi są NATS Streaming (STAN), JetStream oraz zwykły Nats. To pierwsze jest już deprecated i jego miejsce zajął JetStream. Poza tym, że potrafię go skonfigurować oraz obsłużyć w aplikacji to wiem tyle, że ma bardzo szybki czas RPC (Remote Procedure Call), w porównaniu z AMQP, poza tym osobiście nie zauważyłem żadnych różnic w działaniu.
OAuth2
W tym roku na potrzeby pracy przestudiowałem bardzo konkretnie metody autoryzacji i uwierzytelniania, które z grubsza opisałem w tym artykule. Poznałem również wiele narzędzi oferujących to, jak ORY Hydra, Kreatos, KeyCloak, Auth0, Amazon Cognito i jeszcze kilka innych.
Plany na kolejny rok:
- AI i ML jak zwykle zajmują swoje miejsce w kolejce do nauki i mam nadzieje, że starczy mi czasu, aby się wdrożyć w ten temat.
- Zastosowanie Grafany oraz Prometeusza do własnych aplikacji.
- Wykorzystanie ElasticSearch oraz Kibany do scentralizowania logów z moich aplikacji w infrastrukturze inteligentnego domu.
- Prace nad infrastruktura oraz urządzeniami inteligentnego domu.