Spring 5 i reactive

https://spring.io/blog/2016/09/22/new-in-spring-5-functional-web-framework

Moje pytanie: czy to jest fajne (zakladamze tak), ale jesli tak to dlaczego?

Jak dla mnie jest fajne bo:

• nie zużywa 1 wątku na 1 request (mniej zasobów OS pożera)
• Spring MVC bez tuningu wygląda jak wymiociny
• programowanie reaktywne generalnie nie blokuje, czyli klient dostaje future i odpowiedź wtedy gdy jest rzeczywiście gotowa
• jest dołączony sensowny klient (nie tylko RestTemplate, który piękny nie jest)
• standardowe wsparcie ze Springiem, co oznacza bezproblemową i darmową integrację z najpopularniejszą platformą javową: spora szansa na użycie w pracy
• będzie wsparcie dla Kotlina out-of-box

Dla mnie to nie jest dobre, teraz wszyscy są modni i chcą być reaktywni, ale jakoś w backendzie średnio reaktywne programowanie mi pasuje. Np. na androida jest doskonałe, ale tutaj jakoś mi po prostu nie pasuje, zwykły Spring mi bardziej leży. No i co z zarządzaniem transakcjami?

@scibi92 Dla mnie asynchroniczne programowanie zdarzeniowe to nie jest jakaś moda i hype to było od zawsze API nie zawsze było super przyjemne. Jak dla mnie nie wszędzie potrzebujesz transakcji. Poza tym dochodzi CAP i transakcyjność nie zawsze się przydaje (coś kosztem czegoś: transakcje się nie skalują). Jak ktoś pisze jakieś ERP to raczej nie potrzebuje takich zabawek. Nowoczesny frontend aż się prosi, aby pracować z róznymi future'ami / promisami.

Co to CAP? No według mnie bez transakcji to sobie to cięzko wyobrazić programowanie, również w systemach ERP.

Nie każdy system to ERP czy przerzucanie kasy z jednego konta na drugie. Czasem system wymaga zachowania wysokiej dostępności (często auto-skalowalności) i i bezawaryjnej pracy kosztem spójności danych (aplikacje typu Amazon albo Netflix). Zależy od wymagań.

Mi Spring 5 reactive przypomina mocno Spark Java (co jest na + oczywiście: nie trzeba integrować technolgii dostawców spoza Spring, mniej roboty, mniej problemów, lepsze wsparcie, mniej błędów, mniejsze ryzyko).

https://en.wikipedia.org/wiki/CAP_theorem

No tak, jeśli wysoka dostępnośc jest ważniejsza od spójności danych to ok, akurat Java to często e-commerce i banki więc na ogół spójność danych jest dosyć istotna ;)

Non blocking to tylko miła rzecz dla wydajności. Tu chodzi o czystość kodu. Pożyjecie - docenicie.

Ale o jakiej wydajności tutaj piszemy, wydajniej co to znaczy konkretnie. Mamy systemu na których pracuje 100 tys użytkowników i obsługuje to dwa tomcat(8core,16GB) + apache w load balancerze.
Nie każdy z nas pisze ogromne systemy..w zasadzie mniejszość, niestety ta mniejszość to ogromne firmy które dużo krzyczą, że reaktywność, że wydajność, że microservice itp. ale 95% softu tego nie potrzebuje

Jarek mój ulubiony hype-drive developer :) No tak reaktywnośc bardzo zwiększa czytelność backendu. No bo jak mamy mapowanie URL i wywołanie po kolei metod z innych obiektów to jest bardzo nie czytelne :D

@RequestMapping(value = "/rest/users/",method = RequestMethod.Post)
public void registerUser(UserRegisterForm userRegisterForm){
 userAccountService.registerUser(userRegisterForm);
}

Nikt nie domyśli się o co chodzi, najlepiej wszędzie dawać lambdy subsciption i obervable :D

Myśle że @jarekr000000 chodzi raczej o to że wszystko masz w swoim kodzie i to jest pewna różnica czasami. Jeśli masz @RequestMapping to liczysz na to ze Spring magicznie tą adnotacje ogarnie ładując sobie ten @Controller. Jak się pomylisz w konfiguracji kontekstu to może się okazać ze wstanie ci 99 kontrolerów a jeden nie, bo nazwa pakietu się zmieniła i nagle nie wiadomo czemu nie działa kawałek API aplikacji ;)
Kiedy masz to w swoim kodzie, to możesz zawsze postawić breakpoint i zobaczyć co się dzieje i dlaczego coś nie chce działać.

Z życia wzięte kiedy ostatnio takie "magiczne" rozwiązanie trochę mnie zabolało: mamy w jednym projekcie Spring Data i jakieśtam repozytorium extendujace CRUDRepository które czyta sobie z MongoDB. No i okazało sie ze raz na jakiś czas pewne dane w Mongo ulegają zmianie a nie powinny i nie wiadomo skąd ta zmiana przychodzi. Normalnym pomysłem byloby odpalić remote debug, postawić breakpoint w miejscu gdzie mamy metodę do komunikacji z Mongo i czekać aż sie triggeruje. Tylko ze takiej metody nie ma, bo mamy tylko ten interfejs z którego Spring Data w locie generuje kod. Można dać breakpoint na metodę interfejsu, ale wtedy znow lekki hardkor bo nagle mamy breakpoint na kilkuset klasach w classpath które ten interfejs rozszerzają i na kilkunastu faktycznych repozytoriach w naszym kodzie, co powoduje że aplikacja nagle zwalnia ze 100 razy...

scibi92 napisał(a):

Co to CAP? No według mnie bez transakcji to sobie to cięzko wyobrazić programowanie, również w systemach ERP.

Trend jest raczej taki, że gdzie się da to się ludzie pozbywają transakcji czy relacyjnych baz danych. Zwłaszcza w distributed world, twierdząc, że tylko "eventually consistent" jest możliwe w takim świecie. A z reactive oczywiscie jest problem z brakiem async driverow.

Pierwszy raz słyszysz o CAP ?

Biały Mleczarz napisał(a):

scibi92 napisał(a):

Co to CAP? No według mnie bez transakcji to sobie to cięzko wyobrazić programowanie, również w systemach ERP.

Trend jest raczej taki, że gdzie się da to się ludzie pozbywają transakcji czy relacyjnych baz danych. Zwłaszcza w distributed world, twierdząc, że tylko "eventually consistent" jest możliwe w takim świecie. A z reactive oczywiscie jest problem z brakiem async driverow.

Pierwszy raz słyszysz o CAP ?

Trend jest raczej taki, że gdzie się da to się ludzie pozbywają transakcji czy relacyjnych baz danych - tam gdzie to możliwe. * (poprawka)

@Szczery
Myślę, że tutaj chodzi o zrzucenie kosztów utrzymania infrastruktury. Jeśli środowisko jest stabilne i stać nas na duży zapas mocy, mamy własnych adminów to może nie jest to super krytyczne. Coraz częściej szybko rosnący (i szybko zdychający w 95% przypadków) biznes w przypadku startupów chce płacić za serwery, hosting, środowiska, bazy whatever dokładnie tyle ile potrzebuje, wtedy gdy dany core jest potrzebny. Chce też, aby aplikacja nie padła nagle, jak będzie szybki przyrost użytkowników (przykład, gdy padają np. serwery PKW albo serwery uczelniane, gdy wiele osób nagle sprawdza wyniki). Jak dla mnie auto-scaling itp. to jest coś za co biznes może chcieć płacić (bo pozwala np. oszczędzać na kosztach hostingu chmurowego i przy okazji zapewnia dostępność). Nie zawsze firma chce mieć własną infrastrukturę. Liczba użytkowników ma tutaj znaczenie drugorzędne.

Wydaje mi się, że takich aplikacji (dużo użytkowników, wymagana skalowalność) nie ma tak mało. Przykłady to wszelkie duże portale internetowe (np. Allegro, WP).

Zgadzam się w zupełności, że klasyczne aplikacje na JEE 5 czy Springu działają dla 80% aplikacji zamawianych przez biznes. I nie ma sensu pchać się wszędzie z mikrousługami. Ale warto mieć w miarę możliwości bezstanowy monolit: zawsze można podzielić w miarę potrzeby. Każde wymaganie to jednak coś za co klient musi zapłacić (a nikt za darmo nie zbuduje auto-skalującego się systemu).

Zgadzam się, że można robić skalowalne aplikacje blokująco (w końcu HTTP jest bezstanowy). Po prostu trzeba spalić więcej prądu.

margor90 napisał(a):

@scibi92 Dla mnie asynchroniczne programowanie zdarzeniowe to nie jest jakaś moda i hype to było od zawsze API nie zawsze było super przyjemne. Jak dla mnie nie wszędzie potrzebujesz transakcji. Poza tym dochodzi CAP i transakcyjność nie zawsze się przydaje (coś kosztem czegoś: transakcje się nie skalują). Jak ktoś pisze jakieś ERP to raczej nie potrzebuje takich zabawek. Nowoczesny frontend aż się prosi, aby pracować z róznymi future'ami / promisami.

Bo za reactive stoi obietnica lepszego zużycia zasobów przy pomocy tego całego NIO. - co w javie takie proste nie jest bo trzeba patrzec na implementacje clientow, kontenerów, połączeń do DB itp.
Sporo firm, które ma swoje usługi publicznie dostępne raczej o tym myśli by swoje zasoby odpowiednio wykorzystywać.

@Szczery -> mówimy o wydajności, kiedy w roku 2017 masz obsługiwać 100 tys. użytkowników, w roku 2018 - 1 milion użytkowników, a w roku 2019 - 10 milionów użytkowników :). Zgadzam się, że dla małych projektów "tradycyjne" podejście jest wystarczające, ale nawet takie małe projekty mogą nagle zmienić się w duże. Wg mnie fajnie, że powstają narzędzia, które pozwalają na przejście na wyższy poziom wtajemniczenia, gdy sytuacja tego zacznie wymagać.

Odróżniam przy tym stosowanie mikroserwisów od użycia programowania reaktywnego. Programowanie reaktywne można wykorzystać zarówno w małych, jak i w dużych aplikacjach i oba ich rodzaje mogą na tym skorzystać.

Powiedzmy, że chcę zbudować nową, nowoczesną aplikację javową w środowisku mikroserwisów.
Dajmy na to, że chce, żeby to byl Spring Boot 2.0 i Spring 5.

jak rozumiem chcemy w tym wszystkim w wiekszosci utrzymac gdzie sie da komunikację asynchroniczną, nie blokowac niepotrzebnie wątków, non blocking, backpressure, fail safe, lepszy throughput itp.? I to są cale zalety tego ambarasu, czy tak?

A zeby sobie ulatwic zycie z async IO to potrzebne są nam rzeczy jak Reactor/RxJava2.0 ? I teraz bedzie jakby to dzialalo out of the box w Springu?
Bo wczesniiej tez mozna bylo uzyc np. RJavy ale byla troche malo zintegrowanym bytem z frameworkiem ? A teraz zarowno rest client, endpointy czy obiekty z bazy danych moga nam zwracac wszedzie Observable i calosc przetwarzania jest taka... reaktywna?

Czy rzutuje to w jakis sposob na strukture aplikacji ?
jak rozumiem pewnie tez inaczej obslugujemy error handling, czy tak?

Spring 5 WebFlux + project reactor działa razem dobrze (musi). Do tego robię to w Kotlinie. Spring boota, beanów springowych, itp. nie używam ale też powinno razem działać
(zaprawdę czasem nie wiem jak, ale testy pokazują, że działa).

jarekr000000 napisał(a):

Spring 5 WebFlux + project reactor działa razem dobrze (musi). Do tego robię to w Kotlinie. Spring boota, beanów springowych, itp. nie używam ale też powinno razem działać
(zaprawdę czasem nie wiem jak, ale testy pokazują, że działa).

ok, ale zalozenia jakie napisalem powyzej... po co mi to wszystko wlasciwie... są sluszne?

Czy rzutuje to w jakis sposob na strukture aplikacji ? jak rozumiem pewnie tez inaczej obslugujemy error handling, czy tak?

U mnie tak. Aplikacja, właściwie wszędzie rzuca Fluxem, bazy, pliki itp. Flux (projectreactor) stał się de fakto kluczową częścią API.
Czy to dobrze dla każdej aplikacji nie wiem (mam czasem wątpliwości) - u mnie akurat chodzi o przetwarzanie dużej ilości PDFów i przy tym ten koncept pasuje jak znalazł.

jarekr000000 napisał(a):

Czy rzutuje to w jakis sposob na strukture aplikacji ? jak rozumiem pewnie tez inaczej obslugujemy error handling, czy tak?

U mnie tak. Aplikacja, właściwie wszędzie rzuca Fluxem, bazy, pliki itp. Flux (projectreactor) stał się de fakto kluczową częścią API.
Czy to dobrze dla każdej aplikacji nie wiem (mam czasem wątpliwości) - u mnie akurat chodzi o przetwarzanie dużej ilości PDFów i przy tym ten koncept pasuje jak znalazł.

A uzywasz spring boota? niedlugo pewnie wyjdzie ale to dalej RC1.

Spring boot 2 to jest od grudnia. Ale nie używam. Nie wiem po co miałbym. Jak bede chciał spowolnić start aplikacji o 10 sekund to dorzuce Thread.sleep.

jarekr000000 napisał(a):

Spring boot 2 to jest od grudnia. Ale nie używam. Nie wiem po co miałbym. Jak bede chciał spowolnić start aplikacji o 10 sekund to dorzuce Thread.sleep.

niby w jaki sposob boot ma cokolwiek spowolnic ? sluzy w zasadzie za bootstrap i tyle.
i Boot jest na razie w wersji RC1.

Biały Mleczarz napisał(a):

Powiedzmy, że chcę zbudować nową, nowoczesną aplikację javową w środowisku mikroserwisów.
Dajmy na to, że chce, żeby to byl Spring Boot 2.0 i Spring 5.

jak rozumiem chcemy w tym wszystkim w wiekszosci utrzymac gdzie sie da komunikację asynchroniczną, nie blokowac niepotrzebnie wątków, non blocking, backpressure, fail safe, lepszy throughput itp.? I to są cale zalety tego ambarasu, czy tak?

A zeby sobie ulatwic zycie z async IO to potrzebne są nam rzeczy jak Reactor/RxJava2.0 ? I teraz bedzie jakby to dzialalo out of the box w Springu?
Bo wczesniiej tez mozna bylo uzyc np. RJavy ale byla troche malo zintegrowanym bytem z frameworkiem ? A teraz zarowno rest client, endpointy czy obiekty z bazy danych moga nam zwracac wszedzie Observable i calosc przetwarzania jest taka... reaktywna?

Czy rzutuje to w jakis sposob na strukture aplikacji ?
jak rozumiem pewnie tez inaczej obslugujemy error handling, czy tak?

bump

Biały Mleczarz napisał(a):

jarekr000000 napisał(a):

Spring boot 2 to jest od grudnia. Ale nie używam. Nie wiem po co miałbym. Jak bede chciał spowolnić start aplikacji o 10 sekund to dorzuce Thread.sleep.

niby w jaki sposob boot ma cokolwiek spowolnic ? sluzy w zasadzie za bootstrap i tyle.
i Boot jest na razie w wersji RC1.

RC1 wersji 2.

Serwer WWW uruchamia się w czasie zero, wszystko inne jest zbędne :)

https://docs.oracle.com/javase/8/docs/jre/api/net/httpserver/spec/com/sun/net/httpserver/package-summary.html

Biały Mleczarz napisał(a):

jarekr000000 napisał(a):

Spring boot 2 to jest od grudnia. Ale nie używam. Nie wiem po co miałbym. Jak bede chciał spowolnić start aplikacji o 10 sekund to dorzuce Thread.sleep.

niby w jaki sposob boot ma cokolwiek spowolnic ? sluzy w zasadzie za bootstrap i tyle.
i Boot jest na razie w wersji RC1.

OK. Tego RC1 nawet nie pamiętałem
Bootstrap musi poskanować klasy/jary, odpalić kontekts springowy. Nawet w niedużych aplikacjach jest to widoczne.
2 sekund na restart serwera nie zrobisz łatwo na Spring Boot.

Jakie są w zasadzie zalety tego wszystkiego ?

@jarekr000000:
Powiedzmy, ze pracujesz z ludzmi ktorzy robia rzeczy w starym stylu, czyli 3 warstwowo, synchroniczne i publiczne co sie da z rzucaniem wyjątkow na prawo i lewo i nieogarnietym DI.

Jak ich przekonac, ze reactive/webflux/ itp. będą korzystne?

Z mojego ostatniego projektu:

• testowalność, pokazałem jak łatw napisac testy,
• usability - pokazlem jak łatwo zrobić progress bar sensowny - bez gimnastyki,

... i i tak nie wszystkich przekonałem - mam jednego sceptyka uczulonego na programowanie funkcyjne.

Co do reactive - najpierw musisz mieć projekt gdzie to pasuje, przy czym jeśli masz odpowiednio zrypanych architektów to przysiądą do klienta na etapie omawiania koncepcji i ubiją mu całe usability, tak żeby pod spodem i tak tylko chamski CRUD wystarczal . Potem to już nie ma co wsadzać żadnego reactive.

Co do webflux i po prostu funkcyjnego pisania serwerów - trzeba siać, siać, siać... ja walczę.

jarekr000000 napisał(a):

Z mojego ostatniego projektu:

• testowalność, pokazałem jak łatw napisac testy,
• usability - pokazlem jak łatwo zrobić progress bar sensowny - bez gimnastyki,

... i i tak nie wszystkich przekonałem - mam jednego sceptyka uczulonego na programowanie funkcyjne.

Co do reactive - najpierw muszi miec projekt gdzie to pasuje, przy czym jeśli masz odpowiednio zrypanych architektów to przysiądą do klienta na etapie omawiania koncepcji i ubiją mu całe usability, tak żeby pod spodem i tak tylko chamski CRUD wystarczal . Potem to już nie ma co wsadzać żadnego reactive.

Co do webflux i po prostu funkcyjnego pisania serwerów - trzeba siać, siać, siać... ja walczę.

W zasadzie to ten webflux ma tak proste API, ze i prostego CRUDa tez latwo tym zrobic.
Ale pewnie tam gdzie jest intensive IO sie sprawdza lepiej.