Kiedy lepiej jest stosować REST a kiedy menadżera kolejek?
Możecie podać jakieś case study? Jakie są zalety i wady obu tych podejść?
0
3
Stosowanie REST (Representational State Transfer) lub menadżera kolejek zależy od konkretnych wymagań i charakterystyki projektu. Oto kilka przypadków, które pomogą zrozumieć, kiedy lepiej jest stosować jedno podejście lub drugie, wraz z zaletami i wadami obu tych rozwiązań:
REST:
Synchroniczna komunikacja: REST jest najlepszy, gdy potrzebujesz synchronicznej komunikacji między klientem a serwerem. Na przykład, gdy użytkownik wysyła żądanie HTTP do pobrania danych i oczekuje na natychmiastową odpowiedź.
Proste API: REST jest stosunkowo prosty do zrozumienia i używania. Działa dobrze, gdy tworzysz publiczne API, które inni deweloperzy będą konsumować.
Statelessness: REST jest bezstanowy, co oznacza, że każde żądanie jest niezależne od poprzednich. To może być zaletą w przypadku aplikacji, które nie wymagają przechowywania stanu między żądaniami.
Niski narzut: REST wykorzystuje protokół HTTP, co oznacza, że jest łatwy do wdrożenia w przeglądarkach internetowych i wielu językach programowania.
Przykład case study dla REST:
Załóżmy, że tworzysz prostą aplikację internetową do zarządzania zadaniami. Kiedy użytkownik tworzy nowe zadanie, aplikacja natychmiast przesyła żądanie POST do serwera REST API, który dodaje to zadanie do bazy danych i zwraca odpowiedź potwierdzającą.
Menadżer kolejek:
Asynchroniczna komunikacja: Menadżer kolejek jest idealny, gdy potrzebujesz asynchronicznej komunikacji, gdzie zadania są wysyłane do kolejki do przetworzenia w tle. To przydatne, gdy operacje są czasochłonne lub mogą być przetwarzane niezależnie od żądających je klientów.
Odporność na awarie: Menadżer kolejek zapewnia wyższą odporność na awarie, ponieważ zadania są przetwarzane niezależnie od serwera, który je dodał do kolejki. Jeśli serwer przerwie działanie, zadania pozostaną w kolejce i mogą być przetwarzane po ponownym uruchomieniu.
Rozproszenie obciążenia: Kolejki pozwalają równomiernie rozprowadzać obciążenie między wieloma pracownikami (workerami), co jest przydatne w przypadku dużego obciążenia lub potrzeby skalowania.
Przykład case study dla menadżera kolejek:
Załóżmy, że tworzysz system przetwarzania zamówień online. Kiedy klient składa zamówienie, serwer może umieścić to zamówienie w kolejce do przetworzenia. Pracownicy kolejki mogą przetwarzać zamówienia w tle, co pozwala na szybką odpowiedź na klienta i skalowalność w przypadku wzrostu liczby zamówień.
Podsumowanie:
Ostateczny wybór między REST a menadżerem kolejek zależy od konkretnych wymagań projektu. REST jest odpowiedni do synchronicznej komunikacji i prostych interakcji, podczas gdy menadżer kolejek sprawdza się w przypadku asynchronicznych, rozproszonych i bardziej odpornych na awarie operacji. Często też stosuje się oba podejścia w jednym projekcie, gdy mają różne zastosowania.
1
TLDR;
REST - synchroniczna komunikacja
kolejka - asynchroniczna komunikacja
1
Commander300 napisał(a):
Kiedy lepiej jest stosować REST a kiedy menadżera kolejek?
Możecie podać jakieś case study? Jakie są zalety i wady obu tych podejść?
Czym się rózni widelec od schabowego
Po pierwsze dwa dalece odmienne rodzaje komunikacji (plus dla @Dregorio ) - albo @Commander300 masz podkład z tego i wyjaśnienie zbędne - albo jesteś takim świeżakiem, że tłumaczenia w jednym poście nie zrozumiesz
Po drugie serializacja danych do tekstu (w praktyce w REST zawsze) vs protokoly binarne (znacznie częstsze na styku z kolejkami, choc nie wyłącznie)
Po trzecie tytuł wątku pyta o coś jednak innego niz tresć
0
Dregorio napisał(a):
TLDR;
REST - synchroniczna komunikacja
kolejka - asynchroniczna komunikacja
REST czy bardziej precyzyjnie HTTP też może być asynchroniczny. Rożnica jest taka że żądania HTTP są z natury blokujące (request/response) czyli klient musi czekać na odpowiedź serwera, a kolejki nie blokujące, czyli wrzucam wiadomość na kolejkę i YOLO.
1
REST jak wynik ma być natychmiast i nic się nie stanie, jak się nie powiedzie.
Przykłady:
- search request, pobranie danych
- odpalenie akcji, która wykonuje się szybko np. kup coś w sklepie
Kolejki jak coś dzieje się długo i bardzo zależy nam na tym, żeby coś się wykonało. Przykłady:
- obsługa callbacka z zewnętrznego API (nie chcemy stracić takiego zapytania)
- wykonanie zapytania REST do zewnętrznego serwisu (jak coś się zepsuje po którejś ze stron to chcemy to ogarnąć za jakiś czas a nie obsługiwać błąd synchronicznie)
- wykonanie ważnej akcji w tle np. zawołanie API do wykonania przelewu
- coś po prostu dzieje się długo np. wygeneruj raport i wyślij link mailem
Często łączy się komunikację synchroniczną i asynchroniczną w taki sposób, że REST zaczyna cały proces a większość logiki dzieje się asynchronicznie. Np. kliknięcie kup teraz w sklepie może wykonać walidację i całą logikę związaną ze stworzeniem informacji o zamówieniu, ale kolejne kroki (wysłanie wiadomości do hurtowni, wygenerowanie faktury) dzieją się asynchronicznie
0
@markone_dev: Ok, mam system, który produkuje dla mnie dane, które mam przetworzyć jak najszybciej, niestety w nieregularnych odstępach czasu. Więc sugerujesz, że dobrym rozwiązaniem jest w pętli co jakiś czas robić request? Jeśli nie, to podaj proszę use case bo ciekaw jestem.
0
Dregorio napisał(a):
@markone_dev: Ok, mam system, który produkuje dla mnie dane, które mam przetworzyć jak najszybciej, niestety w nieregularnych odstępach czasu. Więc sugerujesz, że dobrym rozwiązaniem jest w pętli co jakiś czas robić request? Jeśli nie, to podaj proszę use case bo ciekaw jestem.
Ale gdzie ja cokolwiek sugeruję. Doprecyzowałem twoją odpowiedź na temat różnicy między HTTP i kolejkami wiadomości. Nic nie pisałem o pętlach czy use case'ach kiedy użyć jednego a kiedy drugiego.
1
Commander300 napisał(a):
Kiedy lepiej jest stosować REST a kiedy menadżera kolejek?
Możecie podać jakieś case study? Jakie są zalety i wady obu tych podejść?
Pomieszałeś dwie zupełnie różne koncepcje. REST, to architektura, w której zasoby są reprezentowane przez swoje unikalne identyfikatory i operujemy na nich za pomocą „czasowników”. Ze względu na takie podejście REST bardzo ładnie „spiął się” z HTTP, ale nie ma przeciwwskazań, żeby korzystać z REST przez „gołe” TCP, czy za pomocą FTP. Formalnie REST nie jest przypięty do żadnego protokołu.
Kolejki pozwalają na trochę inny design. Zamiast zasobów masz wiadomości, które umieszczasz czy to w kolejce właśnie, czy rozgłaszasz w ramach topicu (tematu). W takim podejściu wszyscy zainteresowani reagują na zaistnienie pewnego zdarzenia – wiadomości i na tej podstawie mogą podjąć określone działania.
Inaczej
REST stosujesz tam, gdzie chcesz bezpośrednio manipulować określonym zasobem.
AMQP stosujesz tam, gdzie chcesz powiadamiać, że zaistniało jakieś zdarzenie, a reakcja na nie pozostawiona jest zainteresowanym klientom.
1
Pomijając pomieszaniepojęć z kompletnie innych bajek, to endpoint http (czyli to co chyba nazywasz REST) stosujesz wtedy, gdy to klient ma zainicjować sekwencję zdarzeń. AMQP (zakłądając, że pytasz o komunikację asynchroniczną), wtedy kiedy klient chce być poinformowany przez serwer, o tym, że nastąiło jakieś zdarzenie.
Przykład z życia. Integracja systemów. System A, pobiera dane (zdarzenia) z systemu B, gdzie są one wprowadzane przez użytkowników. Można to zrealizować za pomocą endpointu po stronie systemu B i odpytywania go co kilka sekund/minut/godzin. Większość tych zapytań niepotrzebnie obciąży system B, nie zwracając danych. Jednocześnie wprowadzamy opóźnienie w przekazywaniu danych, tym większe im rzadsze jest odpytywanie.
Inną opcją jest użycie kolejek i AMQP. B w momencie powstania rekordu, produkuje wiadomość i umieszcza ją w kolejce. Poprzez AMQP A zostaje poinformowany o nowych danych, pobiera je i potwierdza pobranie.
Jeżeli budujesz aplikację web, to pobiranie danych po akcji użytkownika powinno być robione synchronicznie (REST), pokazywanie użytkownikowi zdarzeń asynchronicznie (chociaż AMQP to raczej nie ten przypadek, bardziej się sprawdzą np. WebSockets).