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.

Ź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?

Zdecydowanie tak. Utworzysz kilka bardziej rozbudowanych aplikacji w RX i od razu pomyślisz jak bez tego mogłem żyć. Z swojej strony mogę sugerować abyś wybrał się na jakiś wykład o Rx.

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?