PrzemekBancerowski / PZ

System monitorowania rozproszonych zasobów komputerowych - projekt na programowanie zespołowe 2016
0 stars 0 forks source link

Poprawki API + spotkanie #8

Open PrzemekBancerowski opened 8 years ago

PrzemekBancerowski commented 8 years ago

Najważniejsze uwagi: Web server ma być odpowiedzialny za autoryzacje i to on ma się komunikować z monitorami. Czyli baza użytkowników będzie na web serwerze. Z RESTa wylatuje wtedy wszystko co dotyczyło użytkowników. Inaczej będzie zatem wyglądała komunikacja użytkownika z monitorem. Będzie ona przechodziła przez web server. Z tego powodu chcę trochę inaczej porozdzielać zadania.

Chciałbym zrobić jakieś małe spotkanie, potrzebuje na nim @dbaczek @piotrsoltysiak @slipnicki, termin do ustalenia, najlepiej jutro, a może nawet dziś. Poprawimy API i omówimy nową organizację pracy.

Uwaga do wszystkich: Udzielajcie się na githubie, bo od tego zależy wasza ocena.

slipnicki commented 8 years ago

Mialem spotkanie z @dbaczek i doszlismy do paru wnioskow:

Flow

Klient wchodzi na adres www.server-address.com na ktorym stoi web-server i serwuje frontend. Serwowane javascripty dobijaja sie o dane do serwera (autoryzacje - logowanie, resjestracje, dane do wyswietlania) z tego samego z ktorego zostaly wyslane czyli www.server-address.com. WSZYSTKIE requesty z frontendu dobijaja sie do web-servera. Klient nie powinien znac URL'i do wystawionych REST'ow monitorow (o ktorych mowa pozniej).

Serwer www.server-address.com, oprocz serwowania frontendu posiada wystawione API do REST'a do ktorego dobijaja sie wszystkie requesty z frontendu (dotyczace samego uzytkownika jak i danych dotyczacych monitorow).

Requesty dotyczace autoryzacji, sa obslugiwane bezposrednio na web-serverze. Tj. ma on swoja baze ktora przetrzymuje wszystkich uzytkownikow. Web-server potarfi zarejestrowac uzytkownika, zalogowac. Wszystkie pozostale requesty sa przekierowywane do monitorow (o ile oczywiscie dany uzytkownik ma dostep do konkretnych monitorow, dostep do resourcow kontorluje sam web-server). Logika dostepu do monitorow dla danego uzytkownika jest obslugiwana przez web-server.

Web-server komunikuje sie z monitorami przed REST'a a dokladniej przekierowuje zapytanie z frontendu do konkretnego monitora z zapytaniem o przeslanie odpowiednich danych. REST'y po stronie monitora zawsze odpowiadaja web-serverowi - nie posiadaja sprawdzania czy dany user ma do nich dostep poniewaz jest to robione po stronie web-servera. Monitory zwracaja dane ktore dostaje web-server a nastepnie one sa przeslane do frontendu, ktory odpowiednio je interpretuje i prezentuje.

Monitory (jak wyzej wymienione) rowniez posiadaja wystawionie REST'y (kazdy ma osobny) ktore serwuja dane z bazy danych. REST monitora nie posiada zadnej komunikacji z sensorami. Serwuje on dane na podstawie tylko i wylacznie bazy danych.

Monitor sklada sie z 2 aplikacji (zupelnie odzielnych) ktore komunikuja sie za pomoca bazy danych. Jedna to jest wyminony juz REST ktory serwije z bazy danych dane do web-servera. Druga to aplikacja ktora caly czas nasluchuje czy jakis sensor nie chce wyslac nowych danych i ewentualnie przetwarza je i wrzuca do bazy danych.

Sensory posiadaj wlasna logike ktora mowi kiedy jakie dane powinny byc wyslane do monitora. Monitor tylko pobiera, przetwarza i wrzuca do bazy.

Bazy danych

Web-server z uzytkownikami Kazdy monitor z danymi z sensorow

Dostep do baz danych powinny miec tylko aplikacje do nich przeznaczone, nikt inny. Web-server nie powinien wiedziec o bazie monitorow i na odwrot. Srodowisko web-servera powinno byc calkowicie odizolowane od srodowiska monitora i powinny widziec tylko API (i to tylko w przypadku web-servera poniewaz monitor nie powinien w ogole wiedziec o istnieniu web-servera).

REST

Web-server - jedyny REST widoczny po stronie frontendu, ma za zadanie autoryzacje lub przekierowywanie requesty dalej jezeli user posiada uprawnienia do wyswietlania danego resourca

Monitory - kazdy monitor ma swoj REST ktory serwuje dane

REST'y komunikacji web-server <-> monitor powinny miec odpowiednio ustawione HEADERY aby nikt z zewnatrz nie mogl wywolac REST'a monitoru (pomimo faktu ze nie udostepniamy hostow API monitorow).

Przekierowania REST'ow z web-servera do monitorow powinny byc logowane po stronie web-servera (jak rowniez kontrolowane).

More

Architektura jest do dyskusji, jezeli widzicie jakis luki lub cos to dawajcie znac :) :8ball:

dbaczek commented 8 years ago

Doszliśmy jeszcze do wniosku z @slipnicki że trzymanie informacji o pomiarach złożonych ma dużo większy sens w bazie danych web-servera, a nie w monitorach, gdyż są to dane ściśle powiązane z konkretnymi użytkownikami. Dlatego równiez wszystkie zasoby (i ich obsługa) związane z zarządzaniem tymi pomiarami przeniesione zostaną do Webservera. Na wiki utworzyłem nową podstronę dotycząca API webservera. @slipnicki niedługo doprecyzuje zaś API Monitora. @piotrsoltysiak Czy masz zastrzeżenia do takiej architektury?