Siemka. Szukam przykładu "większej" aplikacji wykorzystującej webfluxa. Chodzi mi o coś, co zawiera testy jednostkowe, integracyjne i chociaż robi cokolwiek więcej niż zapis/odczyt z bazy. Mam wrażenie, że wszystkie przykłady, jakie znalazłem to praktycznie to samo, czyli kontroler z repozytorium i tyle. A tak z ciekawości to możecie powiedzieć czy zdarzyło wam się wykorzystywać to w pracy ? Z góry dzięki :)
Spring 
Java 
- Rejestracja:ponad 10 lat
- Ostatnio:6 miesięcy
- Lokalizacja:Poznań
- Postów:797
1
A co dokładnie chcesz więcej? Cała logika aplikacji powinna być maksymalnie niezależna od tego czy korzystasz z springa czy czegoś innego.
U mnie się korzysta ;)
kixe52
Pamiętam, że jeszcze niedawno pisałeś, że przymierzasz sie do roboty i nawet dostałeś pochwałę bodajże od Jarka, że jesteś przykładem juniora, który jest juniorem tylko z nazwy :D Czyli coś załapałeś? Gratuluje :)
danek
dzięki ;)
- Rejestracja:prawie 6 lat
- Ostatnio:prawie 5 lat
- Postów:52
0
Np. serwis wykonujący jakieś mapowanie, łączenie dwóch strumieni w jeden, jakaś logika sprawdzająca coś i ewentualnie wykonująca jakieś inne asynchroniczne zadanie. Przede wszystkim z testami jednostkowymi by nauczyć się je pisać do poszczególnych operacji.
- Rejestracja:ponad 10 lat
- Ostatnio:6 miesięcy
- Lokalizacja:Poznań
- Postów:797
1
To już poczytaj o samej rxJavie
Chyba lepiej juz o projectreactor
oba implementują ten sam interface (inna nazwa klas tylko), a mam wrażenie do rx jest więcej materiałów i są bardziej uniwersalne. Nie mniej masz racje
z tego co pamietam to Spring WebFlux wlasnie korzysta z projectreactor, a nie z rx, dlatego taka sugestia ;)
tak jest jak mówisz
- Rejestracja:około 17 lat
- Ostatnio:dzień
- Postów:1873
6
Z 2 letniego doświadczenia, jakie mam z reaktywnymi usługami (obojętnie czy to rxJava czy Reactor) wynika, że wejście w reaktywny stack to trade off wydajności vs. koszt developmentu i utrzymania.
- Flowable/Fluxy i operatory zaśmiecają logikę biznesową. Nie da się od tego uciec, ponieważ z każdego repozytorium czy klienta HTTP wychodzi się strumieniem.
- Testy jednostkowe oraz integracyjne wiele nie różnią się od synchronicznego kodu - po prostu robisz „block()” na metodzie fasady/serwisu aplikacyjnego/handlera etc
- Mega trudno wychwycić, czy się nie skopało czegoś wydajnościowo - słynny flatMap() z subscribeOn() w złym miejscu czy gubienie eventów przy użyciu combineLast(). Trzeba pisać testy z testowym schedulerem, co jest czasochłonne. Ale to i tak mniejszy problem, ciężko w ogóle wyłapać problem. Pozostaje w zasadzie Grafana.
- W 99% w ogóle nie ma potrzeby pakowania się w reaktywny stack, czasem czasy odpowiedzi są nawet gorsze. Oczywiście jest ten 1%, ale mam hipotezę, że wtedy powinny być to wyspecjalizowane, chude usługi, gdzie warto zapłacić zwiększony koszt utrzymania.
- Często dopisanie „prostego ifa” wymaga nieintuicyjnego zipowania/flatmapowania strumieni. Jest to nieczytelne i kontrproduktywne.
- Biblioteki do security czy trace’ingu nie są gotowe na brak Thread Local, potrzeba czasu, aby dostosowały się do Reactora. RxJava ogrywa to za pomocą hooków (korzysta z Thread Local), więc jest lepiej.
- Podejście deklaratywne fajnie się sprawdza, jeśli chcemy punktowo zrównoleglić jakieś operacje. Punktowo, to znaczy, że na koniec i tak czekamy na wątki. Nie jest to reaktywne, a po prostu asynchroniczne.
W zasadzie o wszystkich punktach powiedział Tomek Nurkiewicz w swoim talku .