serwer WWW a serwer backendowy

Odpowiedz Nowy wątek
2019-08-23 19:06
0

Hej, realizuje jeden z projektów na studia, gdzie jednymi z wymagań sa:

- System sklada sie z dwoch procesow: serwera WWW i serwera backendowego, przetwarzajacego zlecenia. W ten sposob system powinien izolowac serwer www od przetwarzania bazodanowego za pomoca kolejek.
- Generalnie mozna wyroznic 2 rodzaje komunikacji zlecenia (komendy itd), wymagajace zmiany stanu bazy i zapytania(selecty), tj. np. selecty na potrzeby np. autoryzacji, wyswietlenia stanu inicjalnego.
- Zlecenia powinny oczekiwac w kolejce na przetworzenie, a wynik powinien byc zwracany przez kolejki do serwera WWW. Po wyslaniu zlecenia serwer sterowanie wraca do aplikacji WWW, a ta np. przy pomocy WebSocket aktualizuje swoj stan po przyjsciu odpowiedzi

Czy moglby mi ktos wytlumaczyc co powieniem rozumiec jako serwer www? chodzi o to, ze serwer www to backend A, do ktorego bedzie sie komunikowal frontend, a ten backend A bedzie korzystał z backendu B(nazwanego serwerem backendowym) gdzie bedzie odbywac sie cala "logika"?

edytowany 2x, ostatnio: temporarus, 2019-08-23 19:08

Pozostało 580 znaków

2019-08-23 19:15
1

Dla autora serwer WWW to "frontend" który komunikuje sie z backendem asynchronicznie przez kolejki. W sensie masz normalną aplikacje webową, która komunikuje się pod spodem z jakimś innym serwisem, który tutaj nazywa się serwerem backendowym.


Masz problem? Pisz na forum, nie do mnie. Nie masz problemów? Kup komputer...
edytowany 1x, ostatnio: Shalom, 2019-08-23 19:16

Pozostało 580 znaków

2019-08-24 12:18
0

hmm, ok ale chyba nie rozumiem ogolnego koncpetu. Zalozmy, ze wołam endpoint A, który wrzuca działanie X do kolejki(zalozmy, ze jest to rabbitMQ ale to chyba nie powinno miec znaczenia) i jak zwracamy wynik tego działania do osoby, która wołała? Jesli dzialanie bedzie w kolejce to nie wiemy kiedy sie wykona dlatego nie czekamy na wynik wiec inna opcja to uzycie webhooków zeby poinformowac o wyniku ale webhooki uzywamy na backendzie a nie na frontendzie wiec nie wiem.

edytowany 2x, ostatnio: temporarus, 2019-08-24 12:19

Pozostało 580 znaków

2019-08-24 12:32
0

bylbym wdzieczny za tytul jakiejs ksiazki/bloga gdzie moge znalezc informacje jak budowac systemy w oparciu o CQRS i kolejki bo chyba popelniam jakies bledne zalozenia w moim rozumowaniu

Pozostało 580 znaków

2019-08-24 13:06
1

Masz napisane że są tam websockety :) Nie czekasz aktywnie na wynik na froncie tylko masz websocket na który przyjdize odpowiedź.


Masz problem? Pisz na forum, nie do mnie. Nie masz problemów? Kup komputer...

Pozostało 580 znaków

2019-08-24 20:44
0

Ale gapa ze mnie :D dzieki!
w przypadku CQRS i kolejk to ma wygladac tak, ze kazda komenda(cqrs) trafia do kolejki i pozniej na wynik trzeba czekac w przypadku frontendu na websokecie? W przypadku zapytan(cqrs) nie wrzucamy tego do kolejki tylko synchronicznie zwracamy zasób?

tldr; czy to oznacza, ze kazdy event musi trafic do kolejki i wtedy ewentualny wynik dostaniemy przez websocket a w przypadku quries mozemy dostac wynik synchronicznie?

edytowany 2x, ostatnio: temporarus, 2019-08-24 21:28

Pozostało 580 znaków

2019-08-24 22:54
2

Musisz jeszcze jakoś zagwarantować, że widok zbudowany na froncie z danych przesłanych przez WS jest spójny z wynikiem synchronicznego zapytania, kiedy np. odświeżysz stronę. Możesz to zrobić stosując coś a la event sourcing, czyli query zwraca sekwencje zdarzeń od samego początku - wtedy na frontendzie masz jeden kod składający te eventy, nieważne czy pochodzą z WS czy z query. Możesz tez zrobić odwrotnie - po przetworzeniu komendy aktualizujesz model danych, a przez WS pchasz cały agregat zamiast zdarzeń/delt i frontend w ogóle nie zajmuje się składaniem eventów - tak bym chyba nawet proponował.

edytowany 1x, ostatnio: Charles_Ray, 2019-08-24 22:56

Pozostało 580 znaków

2019-09-04 19:40
0

Nie jestem pewien czy dobrze zrozumialem pierwszy komentarz - mam po stronie frontu wrzucac bezposrednio do kolejki commandy/queries? Nie powinno byc tak, ze najpierw robie request na backend i to backend wrzuca command/query do kolejki?

Pozostało 580 znaków

2019-09-05 08:55
2

Wysyłanie żądania z przeglądarki bezpośrednio do kolejki jest złym pomysłem. Powinieneś mieć wystawione API w formacie wygodnym dla klienta, czyli pewnie jakiś REST. Ten sam komponent może wystawiać inne API dla klienta, np. w celu pozyskiwania danych do wyświetlenia. W przeciwieństwie do @Charles_Ray nie uważam, żeby przesyłanie wszystkich rekordów do klienta i przerzucenie na niego odpowiedzialności ustalenia stanu wynikowego. CQRS zakłada, że masz od tego osobny serwis (część Q). Pchanie przez internet do przeglądarki całej historii np. konta klienta, tylko po to, żeby określić aktualne saldo zdecydowanie mi nie pasuje, chociażby ze względu na ilość danych przesyłanych przy każdym żądaniu.

„Możesz tez zrobić odwrotnie - po przetworzeniu komendy aktualizujesz model danych, a przez WS pchasz cały agregat zamiast zdarzeń/delt i frontend w ogóle nie zajmuje się składaniem eventów - tak bym chyba nawet proponował.” :) - Charles_Ray 2019-09-05 09:07
@Charles_Ray: masz mnie - nie doczytałem. - piotrpo 2019-09-05 09:09

Pozostało 580 znaków

2019-09-05 19:34
0

Dzieki! :)

Mam jeszcze bardziej ogolne pytanie - czy jest sens stosowania DDD lub nawet CQRS w projektach, które nie są wielkimi kobyłami tylko prostymi projektami skladajacymi sie z prostych CRUDów?

Pozostało 580 znaków

2019-09-05 19:44
2

Nie ma. Nawet w aplikacjach które nie są tylko CRUDami ale logika biznesowa jest w nich prosta. Chociaż akurat "logiczne" CQRS w takim przypadku warto stosować, w sensie stosowny podział na klasy przetwarzajace polecenia i zapytania. Nie oznacza to natomiast ze pewnych elementów DDD nie warto stosować w takim przypadku. Takie "lekkie" DDD jak najbardziej może mieć sens. Ale wiadomo- to zależy.


Na każdy złożony problem istnieje rozwiązanie które jest proste, szybkie i błędne.
edytowany 1x, ostatnio: Aventus, 2019-09-05 19:44

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0