Zaprojektować architekturę aplikacji

[mpfmorawski]

TODO

• [x] Przygotować diagram systemu https://github.com/mpfmorawski/git-to-know-me/issues/1#issuecomment-1098813687
  • [x] Wydzielić podstawowe serwisy
• [x] Wypisać podstawowe endpointy

[pktiuk]

Wstępny diagram architektury systemu

Spis elementów

• Auth Service - serwis służący do zarządzania użytkownikami. Rejestruje i usuwa on użytkowników. Służy on także do obsługi logowania i sprawdzania zapytań wymagających logowania. Korzysta on z bazy danych user_db Endpointy:
  • /auth/login (POST)
  • /auth/signup (POST)
  • /auth/logout (POST) - kończy on obecną sesję i przekierowuje na stronę domyślną
  • pozostałe-dla pozostałych zapytań będzie on sprawdzać, czy dany użytkownik ma dostęp do danego zasobu oraz czy jest zalogowany. Jeśli nie zwraca kod 403
• Github/Gitlab Fetcher - Dostarczają danych w formie gotowej do wyświetlenia z wykorzystaniem API REST-owego. Dane te są przez niego agregowane z serwerów GitHuba lub Gitlaba.
• Repository stats server - pozwala na wyciąganie zagregowanych danych z bazy

[pktiuk]

Jest to wstępny projekt, jeszcze nie uwzględnia decyzji projektowych, które muszą być podjęte w ramach #3 #4 oraz #2

[mpfmorawski]

Na ten moment nie mam uwag.

[pktiuk]

Projekt architektury poprawiony.
Naniosłem poprawki dotyczące serwowania frontendu.

Oraz uszczegółowiłem agregację i serwowanie danych. Mam tutaj jednak pewien dylemat.

Czy w kontekście zdobywania i agregowania danych lepiej jest:

I zbierać interesujące nas dane do bazy, z której są potem pobierane i agregowane.

II pobierać dane z githuba i gitlaba na bieżąco i od razu je agregować

Wydaje mi się, że podejście I jest lepsze, bo te zagregowane dane nie tracą zbyt szybko na świeżości i nic się nie stanie jeśli nie uwzględniają dzisiejszego dnia.
@jprokopczuk warto, żebyś ty się wypowiedział, bo dotyczy to twojej części.

[mpfmorawski]

Odpowiadając na Twój dylemat:

Przyznam, że ciekawiło mnie, jakie podejście wybierzesz i trochę już na ten temat myślałem.

Również uważam, że podejście numer I bardziej pasuje do naszej aplikacji. W razie ewentualnych problemów z pobieraniem danych "na żywo" mamy backup w postaci zagregowanych danych. W związku z tym zabezpieczamy się przed niezależnymi od nas błędami - wyświetlając po prostu mniej aktualne dane.

[pktiuk]

Możliwe jest jeszcze trzecie podejście. łączące 2 poprzednie.

Mikroserwis agregujący wysyła zapytania do serwisów fetchujących dane, te sprawdzają, czy są w bazie świee dane na ten temat i jeśli nie ma to sobie je pobiera.
To podejście byłoby chyba najlepsze, bo łączyłoby zalety obu podejść i zapewniało dużą niezależność usług. Agregator nie musi wiedzieć czy te dane są w bazie, czy w repo etc.

[mpfmorawski]

Bardzo mi się podoba to podejście!

[jprokopczuk]

tl;dr Po wczorajszej rozmowie z @pktiuk, doszliśmy do wniosku, że najlepsze będzie podejście trzecie, czyli połączenie dwóch poprzednich.

Podczas zabawy z GitHubowym API okazało się, że część informacji trzeba wyciągać "na około", czyli nie ma podanych bezpośrednio danych dotyczących któregoś z elementów. Z tego powodu, czas agregacji danych znacząco się wydłuża. Podejście pierwsze ma tą wadę, że za każdym razem nie sprawdzamy tego, czy w pewnym ustalonym czasie użytkownik wykazał się aktywnością. natomiast drugie podejście ma tą wadę, że czas agregacji danych może być bardzo długi. W trzecim podejściu, pobieramy dane do bazy danych, ale przed każdą aktualizacją sprawdzana jest aktywność użytkownika np. poprzez endpoint /events. Wtedy w razie potrzeby, aktualizujemy dane w bazie danych, ale nie pobieramy tych danych, które nadal są aktualne (np. aktualizujemy informacje nt. jednego repozytorium).

[pktiuk]

Ostateczny diagram architektury systemu

Spis elementów

• Auth Service - serwis służący do zarządzania użytkownikami. Rejestruje i usuwa on użytkowników. Służy on także do obsługi logowania i sprawdzania zapytań wymagających logowania. Korzysta on z bazy danych user_db Endpointy:
  • /api/auth/logout (POST) - kończy on obecną sesję i przekierowuje na stronę domyślną (HTML kod 3xx)
  • /auth/user - pozwala wyciągnąć loginy/id użytkownikana podstawie jego ID (na githubie i gitlabie może mieć różne nazwy)
  • pozostałe-dla pozostałych zapytań będzie on sprawdzać, czy dany użytkownik ma dostęp do danego zasobu oraz czy jest zalogowany. Jeśli nie zwraca kod 403
• Github/Gitlab Fetcher - Dostarczają danych w formie gotowej do wyświetlenia z wykorzystaniem API REST-owego. Dane te są przez niego agregowane z serwerów GitHuba lub Gitlaba.
  • /github/stats/general_user/ - ogólne statystyki dla użytkownika, jego gwiazdki, login, endpoind dla profilowego etc
  • /github/stats/top_repos - najpopularniejsze repozytoria użytkownika
  • /github/stats/languages - statystyki dotyczące języków używanych przez użytkownika

• Aggregation service - serwis agregujący dane n't aktywności z różnych źródeł i przedstawiający je w formie dostosowanej do serwowania przez frontend

  • /api/stats/general_user/ - ogólne statystyki dla użytkownika, jego gwiazdki, login, endpoind dla profilowego etc
  • /api/stats/top_repos - najpopularniejsze repozytoria użytkownika
  • /api/stats/languages - statystyki dotyczące języków używanych przez użytkownika

  Endpointy zaczynające się na /api/ powinny być dostępne z zewnątrz, pozostałe są tylko na użytek komunikacji między mikroserwisami

[mpfmorawski]

Spotkanie 14.04.2022 - Plan:

W tym issue wypisane będą wszystkie endpointy pod każdym serwisem (Spis elementów). Potem zamykamy issue.

[pktiuk]

Issue https://github.com/mpfmorawski/git-to-know-me/issues/7 można traktować jako praktyczną realizację tego, co tu zostało przedstawione