Reactive Programming - hit czy kit ?

Czesc, na wstepie przepraszam za brak polskich znakow.

Co sadzicie o idei / manifescie "Reactive Programming" ? Piszmy wszystko asynchronicznie, niech nic nie blokuje niczego bezmyslnie, wykorzystujmy sprzet granic mozliwosci...

Chodzi mi to Scale, Akke, Playa, Spray.io, Reactive Mongo,itp. Czy to ma szanse zawojowac rynek ? A moze dalej bedziemy pisac w Javie na Tomcata ? Zaczalem sie tym jarac troche. Fajnie byloby znac Jave, Springa itp a do tego Scala i asynchronous-oriented-programming. Jednak utrzymac oba stosy wiedzy na wysokim poziomie moze byc ciezkie.

czekaj czekaj, możesz mieć appke w "javie na tomcata" i obok mieć osobno coś na czym stoi Akka (ktoś tu nie przeglądał materiałów) :D przecież w Springu jest deferredResult(które pod spodem tak naprawdę wykorzystuje async z servlet 3.0), jest @Async, a co to jest jak nie asynchroniczne programowanie ? W ogóle skąd to podejście że jedna "szkoła" musi od razu wyprzeć inną.

Są zastosowania dla microservisów ale są miejsca gdzie sprawdzają się klasyczne monolityczne aplikacje. Tak samo jest z programowaniem asynchronicznym, Ty masz szukać rozwiązań pod use-case a nie szukać miejsc żeby na chama wsadzać tam Akke czy rxJave.

Zresztą, żeby mieć jakiś "stos" na wysokim poziomie, to potrzebujesz z 5lat w codziennym użytku - w tedy Ci "noga wyrośnie" ( )

Źle się zabierasz za temat. Chcesz ogarniać Scalę, Akkę, Rx i coś tam jeszcze. Wszystkiego na raz nie da się ogarnąć. IMO powinieneś zacząć or RxJavy i na spokojnie dużo o tym poczytać, napisać kilka prostych programów i potem brać się za resztę. Sama RxJava ma wysoki próg wejścia i trzeba spędzić trochę czasu, żeby to dobrze zrozumieć i umieć się tym posługiwać. Korzystam z RxJavy jakiś czas i nie mogę powiedzieć, że w pełni poznałem tę bibliotekę, ponieważ API jest potężne. Nie można popadać w skrajności pisać wszystko w sposób reaktywny, ale w bardzo wielu miejscach takie podejście się sprawdza. Upraszcza kod i daje więcej możliwości. W przypadku aplikacji mobilnych na Androida staje się to powoli standardem, bo do tej pory nie wymyślono lepszego rozwiązania do obsługi asynchronicznych operacji dla tej platformy. W wielu innych miejscach też się to sprawdzi, ponieważ mamy API podobne do strumieni z Javy 8, ale ze wsparciem dla wielowątkowości.

Polecam m.in krótką prezentację n.t. Retrofita i RxJavy:

W tej chwili robię coś mocno rozproszonego na bazie Netty. Nie bardzo widzę, jak uzyskać taką wydajność i skalowalność pisząc w sposób klasyczny, tj. blokujący. Przede wsystkim jestem w stanie obsłużyć tysiące połączeń na kilku wątkach i praktycznie jednym wspólnym executorze, przez który przechodzi wszystko:

• połączenia od klientów
• połączenia do bazy danych
• we/wy dyskowe
• komunikacja między węzłami systemu

Mała liczba wątków to:

• małe straty na przełączaniu kontekstu i ciągłym blokowaniu wątków
• małe użycie pamięci stosu

Poza samym reactive dochodzi jeszcze fakt, że Netty począwszy od wersji 4.0 ma bardzo wydajne mechanizmy ręcznego zarządzania pamięcią (tak! w Javie :P), co powoduje, że GC Javowe pod pełnym obciążeniem nam się nudzi i ziewnie (w sensie - minor GC) może raz na kilka minut.

Wady:

• trochę trzeba się mentalnie przyzwyczaić do innego modelu, np. czasem korci żeby na jakimś future zrobić get
• czasem można natrafić jeszcze gdzieniegdzie na blokujące API i wtedy trzeba obchodzić stosując osobną pulę wątków aby "udawać" asynchroniczne
• pewne rzeczy się potrafią skomplikować i trzeba uważać na nowe typy problemów -
  • np. utknięcie w jakimś stanie na zawsze, bo zapomnieliśmy obsłużyć prawidłowo jakieś zdarzenie (albo wysłaliśmy nie tam gdzie trzeba),
  • albo nieograniczony wzrost liczby skolejkowanych komunikatów (tj. system szybciej generuje niż konsumuje).

Czyli co? Czas sie zaczac uczyc, zeby Janusze IT nas nie wygryzli?

Patrząc na to z drugiej strony - zabawne jest, jak stare koncepcje z wczesnych lat 70-tych (albo i jeszcze wcześniej), dostają nową nazwę i już B-playerzy podniecają się "nową technologią".

Jeśli jesteś Januszem IT, to używanie RxJava nie sprawi, że będziesz nim mniej. :P

Od czego warto zacząć się uczyć w stronę "reactive" gdy ktos jest programistą java, ale z dosć podstawową wiedzą o wielowątkowości?

Trochę jestem sceptyczny ale wydaje się warte przynajmniej pobawienia się.

Może ktoś zarzucić przykładowymi use casami dla web development?

java concurrency in practice, a potem może jakaś RxJava? ;)

chyba tak zrobie... chociaz podjaralem sie scala ostatnio.

a ma ktos jakas opinie o spring reactorze? albo reactive jersey? :p

Czy to cale reactive to bardziej frontend stuff?

jakies zastosowania na backend, server side?

Same zastosowania do backendu. Przeczytaj manifest...

https://spring.io/blog/2016/02/16/reactor-2-5-a-second-generation-reactive-foundation-for-the-jvm

Macie moze jakiegos linka z porownaniem futurow i callable vs threading w rxjava?

hmm... niedawno natrafiłem na RxJave i zastanawiam się do czego by można jej użyć.
Zrobiłem nieco bezmyslny przykład. Wątpię, że jest poprawny.
Czy w ten sposób albo podobny mógłbym robić async rest calls?
To Schedulers.io spawnuje RxCachedThreadSchedulers.

import java.util.List;

import rx.Observable;
import rx.functions.Func2;
import rx.schedulers.Schedulers;

public class App {

	public static void main(String[] args) {
		Observable<List<Person>> ziped = Observable
				.zip(getObservableName(), getObservableAge(), new Func2<String, Integer, Person>() {

					@Override
					public Person call(String name, Integer age) {
						Person person = new Person();
						person.setName(name);
						person.setAge(age);
						return person;
					}
				}).toList();

		List<Person> personList = ziped.toBlocking().single();
		personList.stream().forEach(person -> System.out
				.println("[Name : " + person.getName() + ", Age : " + person.getAge() + "]"));
		// [Name : Maciek, Age : 18]
		// [Name : Rysiek, Age : 20]
		// [Name : Zdzichu, Age : 45]
		ziped.subscribe();
	}

        // emits Observables of Lists.newArrayList("Maciek", "Rysiek", "Zdzichu");
	private static Observable<String> getObservableName() {
		return Observable.from(RestService.getNames()).subscribeOn(Schedulers.io());
	}
        
        // emits Observables of Lists.newArrayList(18, 20, 45);
	private static Observable<Integer> getObservableAge() {
		return Observable.from(RestService.getAges()).subscribeOn(Schedulers.io());
	}
}

edit: z tego co widzę to moglbym tez wywalic subscribe w ogole, albo przeciwnie zrobic jakis cache() i zebrac wynik w subscription. Zreszta nie wiem ;]

jakas podpowiedz? ;)

Ba, nawet bardzo dobrze się w tym sprawdza. Poszukaj wykładu z Confitury 2015 o RxJavie i Hystrixie ;)

Ok, obadam. Ale czy powyzszy przyklad to prawidlowe uzycie? Mniej wiecej. Glownie chodzi mi o kawalek toBlocking() gdzie nawet dokumentacja mowi, ze raczej sie tego nie robi. ;)

Chociaz mysle, ze chodzi o to by ten stream wystawic w swiat i publikowac wyniki kolejnych zipow, zamiast go przyblokowac i zwrocic wynik.

A ja mam pytanie. Jak na warstwie sieciowej są zrealizowane takie streamy. Niereaktywne mogę wystawić sobie RESTa, który pobiera stronę danych / cokolwiek, a Reactive przewiduje traktowanie danych jako streamu. Czyli mogę odwołać się najpierw po 10 elementów a potem po 20.

Chciałbym się dowiedzieć jak serwer wystawia "taką usługę" i jak klient z niej korzysta. Ktoś coś ?

Expertem nie jestem, ale wydaje mi się, że też możesz użyć RESTa - robisz tylko połączenie HTTP keep-alive i urywasz po tych 20-tu czy iluś tam żądaniach. Nie wiem czy to jest zalecana metoda.

Websockety są chyba w sam raz do tego. Są już dobrze wspierane przez przeglądarki: http://caniuse.com/#feat=websockets

websockets i server sent events

http://en.lichess.org/ to cos to chyba websockets, scala, play, akka streams

Ile plus / minus może zająć nauka Scali, Akki i Play'a mając 1,5 roku doświadczenia zawodowego w Javie ?

Jak chcesz używać Scali jako "lepszej Javy" to niedługo i ponoć sporo projektów jest w ten sposób pisanych w Scali. Natomiast jeśli chcesz się nauczyć programowania funkcyjnego, to trochę więcej.

Wątpię, czy ktoś ci dokładnie odpowie ile ci to zajmie, bo tak to nie działa ;)

Tak, żeby zacząć kodować coś i poczuć się w miarę swobodnie (składnia, podstawowy biblioteki standardowej itp.) to zajęło mi jakieś 2 tygodnie. Później to już zależy od tego co robisz, jak szybko się uczysz i jak bardzo chcesz być zaawansowany.

Te manifesty w IT sa zalosne :D
Tylko ten jest dobry: http://programming-motherfucker.com/

Ktoś może podać praktyczne przykłady tego?

Chat? Google Spreadsheets? real time?

Złoty Szczur napisał(a):

Ktoś może podać praktyczne przykłady tego?

Chat? Google Spreadsheets? real time?

Reactive programming może być (prawie) wszędzie.
Scala + Akka + Slick (baza danych) wszystko wewnątrz frameworka Play!

Prosty z życia wzięty przykład:

rest api w wykonaniu Play!

controller przyjmuje request, daje znać do aktora (ask -> zwraca future) do np pobrania danych z bazy -> aktor przekazuje zapytanie do bazy danych (slick), który zwraca future (albo stream, jeśli ktoś chce/potrzebuje), wszystko asynchronicznie wraca do controllera jako future, który na przyjście future zwraca dane do klienta, a jak future będzie failed to wykona jakąś tam inną akcję.

Piszę reactive od około 2lat i od czasu jak zacząłem tak pisać razem ze scalą, to
-nie ma pętli for (za wyjątkiem for comprehension w scala:) )

• if'ów prawie nie ma
• zapomniałem co to jest nullpointerexception
• kod jest bardziej zwarty, prostszy do refactorowania.

Jeden duży minus - próg wejścia w reactive (o scali nie wspomnę) dla ludzi, którzy od dawna piszą "normalnie" jest dość duży. Trzeba przestawić myślenie na zupełnie inne tory. Ale bardzo warto.... I na pewno nie jest łatwo używać tego w już istniejących systemach.

Zważywszy na kryteria takiego rodzaju programowania to pasuje do tego kod w Erlangu/Elixirze. Aktorowy model komunikacji, zero mutowalnych danych, funkcje mają wiele sygnatur wspierających różne scenariusze (poprzez pattern matching), funkcje rekurencyjne w przypadku przeglądania/modyfikowania list i map.
Próg wejścia: Wyrzucasz całe OO i wchodzisz w programowanie funkcyjne. Później ogarniasz dobrze model komunikacji "gołych" procesów, sprawdzasz GenServer/GenEvent/GenStage i Taski - rozwiązanie pośrednie.

Pipes napisał(a):

Zważywszy na kryteria takiego rodzaju programowania to pasuje do tego kod w Erlangu/Elixirze. Aktorowy model komunikacji, zero mutowalnych danych, funkcje mają wiele sygnatur wspierających różne scenariusze (poprzez pattern matching), funkcje rekurencyjne w przypadku przeglądania/modyfikowania list i map.
Próg wejścia: Wyrzucasz całe OO i wchodzisz w programowanie funkcyjne. Później ogarniasz dobrze model komunikacji "gołych" procesów, sprawdzasz GenServer/GenEvent/GenStage i Taski - rozwiązanie pośrednie.

Programowanie funkcyjne to jest magia, w kierunku którym idą (powoli niestety) języki programowania. Java 8 pooowoli zaczyna, Scala wg purystów nie jest w pełni funkcyjna, ale chyba już wyszła poza akademicki język. Haskel to samo. Jest też F#, cały LinQ, który jest "monadic" i wiele innych.
Póki co mam wrażenie, że niewielu jest programistów, którzy rozumieją functional programming.
Wielu nie widzi sensu w nauce nowego, skoro można po staremu :)
A to, że kod jest blokujący, a to, że trzeba się nawalić w klawiaturę, żeby coś dobrze napisać, a to, że refactor prostego mechanizmu potrwa 2dni... who cares?