1. Używacie "zwykłego" Springa (tzn. servletowego) czy w wersji Reactive? Gdzieś na produkcji jest używany? Prawie w ogóle nie widać tutoriali i książek do tej wersji Reactive. 2. Co to jest Spring Reactor(Project Reactor)? Myślałem, że są dwie ścieżki: wersja "zwykła" servletowa, albo reaktywna Reactive (tak jak na obrazku poniżej). A tu wychodzi, że jest jeszcze jakiś Reactor (i z obrazka wychodzi, że może być używany w obu ścieżkach). Do czego to tak naprawdę potrzebne? 3. Czy używacie tego Reactora? O nim to już w ogóle jest mało materiałów. Ktoś tego używa na produkcji?
@mk321 raczej nie ma możliwości by gdziekolwiek system był całkowicie asynchroniczny, niemniej trzeba oddać że wsparcie dla SSE ze strony web fluxa jest bardzo elegancką alternatywą dla web socketów przy jednokierunkowej komunikacji i tu widzę główną siłę tego rozwiązania :)
@mk321: wersja reactive jest stosunkowo swieza i dopiero gdzies tak od roku ja "reklamuja". Zalecam sprawdzic na YouTube wideo z roznych konferencji o tematyce "reactive spring boot", jest ich juz dosc sporo. Josh Long sporo takich wykladow/warsztatow prowadzil.
WebSockety to asynchroniczny zamiennik synchronicznego HTTP. Idzie bezpośrednio po TCP, bo po HTTP jest z definicji synchroniczny (pomijając różne sztuczki jak long polling czyli trzymanie połączenia lub odpytywanie co x ms). Czyli całkiem inny
1. Servletowy stack w zupelnosci wystarczy dla wiekszosci zastosowan. Reactive pozwala optymalniej wykorzystac zasoby, ale imho jest mniej czytelny i trudniejszy do debugowania. Z drugiej strony, jesli masz do czynienia ze strumieniami asynchronicznych zdarzen, to moze to byc calkiem przyjemny model programowania.
2. Reactor to implementacja silnika reaktywnego - bardzo ogolnie mowiac to taki scheduler majacy pule watkow do ktorych delegowana jest cala praca. Roznica jest taka, ze gdy
@mk321 generalnie polecam doczytać, wprowadzenie webfluxa do Springa umożliwiło zwracanie w kontrolerach restowych obiektów flux, co konwertowanie jest do json+stream lub text/event-stream, co oznacza w praktyce operowanie właśnie na api reactora w celu asynchroniczniej komunikacji, i generalnie pomijając internale praktyczna różnica między web socketami sprowadza się jedynie do tego że że nie mamy możliwości wysłania informacji zwrotnej
z resztą nie biorę tego przykładu z nikąd bo w aktualnym projekcie w którym
1., 3. Czyli w normalnych zastosowaniach Servletowy. Ale z użyciem np. WebSocket, kolejek RabbitMQ, Kafka Stream, Akka, NoSQL (MongoDb, Neo4j, Redis) to już ma sens Reactive.
zwracanie w kontrolerach restowych objektów flux i mono, co konwertowanie jest do json+stream lub text/event-stream, co oznacza w praktyce operowanie właśnie na api reactora w celu asynchroniczniej komunikacji
@witajswiecie: zwracanie w kontrolerach jakiegoś typu to tylko cukier składniowy. Pod spodem do czegoś to jest konwertowane. W Servletowych aplikacjach jest to JSON w HTTP.
Tutaj mówisz, że jest to json+stream lub text/event-stream, czyli wychodzi, że Server-Sent Events to kolejna technologia transportu. Coś na miarę Ajax,
bo w aktualnym projekcie w którym jestem własnie do tego wykorzystuje się web fluxa, do asynchronicznego wysyłania informacji o zmianach w systemie właśnie poprzez SSE
@witajswiecie: nie lepiej było to zrobić, którymś z tych sposobów (zakładam, ze to backend-backend):
1. W drugim systemie wystawić endpoint, do którego strzelałaby aplikacja, w której zmienia się stan. W ten sposób by ją powiadamiała (a byłoby synchroniczne, asynchroniczność nic tu nie przenosi). Co prawda w drugiej aplikacji trzeba wystawić endpoint, ale i tak trzeba tam zaimplementować SSE, wiec na jedno wychodzi. 2. Jeśli potrzebujemy grubszego rozwiązania to kolejki
@mk321 z tym że ta cała konwersja jest jedynie cukrem skladniowym akurat jasna sprawa, ale po coś w końcu te wysokopoziomowe api są, by nie rzeźbić wszystkiego od podstaw
I fakt faktem nie jest to wymysł Springa, z mojej codziennej praktyki za pomocą tej technologii jest wykonywana komunikacja z frontendem napisanym w react'cie (jak by to wyglądało przy komunikacji BE to BE nie mam pojęcia), i generalnie największym problemem jest w jej przypadku Internet Explorer (jak zawsze ;) ) ale to jest akurat do obejścia
I generalnie pewnie się da z tego zrezygnować i ręcznie integrować biblioteki, pytanie po co skoro ktoś całą integrację wykonał za nas i wystarczy tylko z tego
@mk321: Tak, Reactor to po prostu biblioteka, ktora wykorzystuje Spring. Reactor siedzi w zaleznosciach spring-webflux i nie da sie go pominac. Wspierane sa tez inne biblioteki, ale dziala to na tej zasadzie, ze typy z np. RxJava sa po prostu tlumaczone na typy z Reactora przez jakis springowy adapter. Tak wiec wszystkie operacje na reaktywnym streamie przeporwadza ostatecznie Reactor.
cukrem skladniowym akurat jasna sprawa, ale po coś w końcu te wysokopoziomowe api są, by nie rzeźbić wszystkiego od podstaw
@witajswiecie: racja, obecnie cukier składniowy to konwersja obiektów do JSON-a, a tutaj konwersja całego streama do Mono/Flux. Duży krok naprzód. I dlatego, że weszła tutaj logika (flow), to musiała być zmiana we frameworku.
tej technologii jest wykonywana komunikacja z frontendem napisanym w
@Kresse: czyli Reactor jest wymagany dla WebFluxa czyli dla całego Reactive stack. A dla Servlet stack jest opcjonalny. Już miałem pytać dlaczego na obrazku jest zaznaczone jako opcjonalny dla wszystkiego. Dopiero teraz po twoim komentarzu zobaczyłem, że jest inny kolor i opcjonalny rzeczywiście zaznaczony tylko dla Servlet, a dla Reactive obowiązkowy. Ech, obrazek mnie zmylił :D Dziękuję :)
zajmuję się na co dzień ściśle backendem wiec nie odpowiem na to pytanie szczegółowo, pewnie jakimś polyfillem, od frontendu mamy osobny zespół, wystarczy mi wiedza ze działa i zostało ogarnięte szybko :)
@witajswiecie: z tego co kojarzę to SockJS trzeba też zaimplementować na backendzie. Ale może u was był wystarczający tylko polyfill na IE na froncie (to już mnie nie obchodzi, bo też na froncie dużo nie siedzę).
Wspierane sa tez inne biblioteki, ale dziala to na tej zasadzie, ze typy z np. RxJava sa po prostu tlumaczone na typy z Reactora przez jakis springowy adapter.
@mk321: Ogółem polecam stack reaktywny, fajnie się w tym pisze jak ogarnie się podstawy RxJava, chociaż na początku zabawa z mapami, flatmapami, observablami i innymi daje w kość :D. Dodatkowo 2 różne podejścia do tworzenia RESTów mogą na początku namieszać. Warto wspomnieć, że podejście "klasyczne" trochę ciężej się testuje.
1. Używacie "zwykłego" Springa (tzn. servletowego) czy w wersji Reactive? Gdzieś na produkcji jest używany? Prawie w ogóle nie widać tutoriali i książek do tej wersji Reactive.
2. Co to jest Spring Reactor(Project Reactor)? Myślałem, że są dwie ścieżki: wersja "zwykła" servletowa, albo reaktywna Reactive (tak jak na obrazku poniżej). A tu wychodzi, że jest jeszcze jakiś Reactor (i z obrazka wychodzi, że może być używany w obu ścieżkach). Do czego to tak naprawdę potrzebne?
3. Czy używacie tego Reactora? O nim to już w ogóle jest mało materiałów. Ktoś tego używa na produkcji?
https://spring.io/ (obrazek stąd)
https://projectreactor.io/
źródło: comment_Xp2GwlQvk5m4h7MVRx5IINK5RaWCZq2j.jpg
PobierzUżywam stacka Springa:
@witajswiecie: SSE to Server-Sent Events?
WebSockety to asynchroniczny zamiennik synchronicznego HTTP. Idzie bezpośrednio po TCP, bo po HTTP jest z definicji synchroniczny (pomijając różne sztuczki jak long polling czyli trzymanie połączenia lub odpytywanie co x ms). Czyli całkiem inny
@UberRam: dzięki, przyda się. Ale to właśnie Spring Reactive. Tutaj widać, że coś się rusza. Ale co ze Spring Reactor?
1. Servletowy stack w zupelnosci wystarczy dla wiekszosci zastosowan. Reactive pozwala optymalniej wykorzystac zasoby, ale imho jest mniej czytelny i trudniejszy do debugowania. Z drugiej strony, jesli masz do czynienia ze strumieniami asynchronicznych zdarzen, to moze to byc calkiem przyjemny model programowania.
2. Reactor to implementacja silnika reaktywnego - bardzo ogolnie mowiac to taki scheduler majacy pule watkow do ktorych delegowana jest cala praca. Roznica jest taka, ze gdy
z resztą nie biorę tego przykładu z nikąd bo w aktualnym projekcie w którym
1., 3. Czyli w normalnych zastosowaniach Servletowy. Ale z użyciem np. WebSocket, kolejek RabbitMQ, Kafka Stream, Akka, NoSQL (MongoDb, Neo4j, Redis) to już ma sens Reactive.
2. Chyba nie do końca
@witajswiecie: zwracanie w kontrolerach jakiegoś typu to tylko cukier składniowy. Pod spodem do czegoś to jest konwertowane. W Servletowych aplikacjach jest to JSON w HTTP.
Tutaj mówisz, że jest to json+stream lub text/event-stream, czyli wychodzi, że Server-Sent Events to kolejna technologia transportu. Coś na miarę Ajax,
@witajswiecie: nie lepiej było to zrobić, którymś z tych sposobów (zakładam, ze to backend-backend):
1. W drugim systemie wystawić endpoint, do którego strzelałaby aplikacja, w której zmienia się stan. W ten sposób by ją powiadamiała (a byłoby synchroniczne, asynchroniczność nic tu nie przenosi). Co prawda w drugiej aplikacji trzeba wystawić endpoint, ale i tak trzeba tam zaimplementować SSE, wiec na jedno wychodzi.
2. Jeśli potrzebujemy grubszego rozwiązania to kolejki
z tym że ta cała konwersja jest jedynie cukrem skladniowym akurat jasna sprawa, ale po coś w końcu te wysokopoziomowe api są, by nie rzeźbić wszystkiego od podstaw
I fakt faktem nie jest to wymysł Springa, z mojej codziennej praktyki za pomocą tej technologii jest wykonywana komunikacja z frontendem napisanym w react'cie (jak by to wyglądało przy komunikacji BE to BE nie mam pojęcia), i generalnie największym problemem jest w jej przypadku Internet Explorer (jak zawsze ;) ) ale to jest akurat do obejścia
I generalnie pewnie się da z tego zrezygnować i ręcznie integrować biblioteki, pytanie po co skoro ktoś całą integrację wykonał za nas i wystarczy tylko z tego
@witajswiecie: racja, obecnie cukier składniowy to konwersja obiektów do JSON-a, a tutaj konwersja całego streama do Mono/Flux. Duży krok naprzód. I dlatego, że weszła tutaj logika (flow), to musiała być zmiana we frameworku.
zajmuję się na co dzień ściśle backendem wiec nie odpowiem na to pytanie szczegółowo, pewnie jakimś polyfillem, od frontendu mamy osobny zespół, wystarczy mi wiedza ze działa i zostało ogarnięte szybko :)
@mk321: ok, chyba znalazłem:
@witajswiecie: z tego co kojarzę to SockJS trzeba też zaimplementować na backendzie. Ale może u was był wystarczający tylko polyfill na IE na froncie (to już mnie nie obchodzi, bo też na froncie dużo nie siedzę).
@Kresse: masz rację, chyba znalazłem:
@witajswiecie: jeszcze to podsumuję jakby ktoś kiedyś czytał.
SSE (Server-Sent Events), to jest właśnie taka specyfikacja. W dokumentacji jest nawet o
Ale nie mogę znaleźć żadnego porządnego źródła do nauki (╯︵╰,)