Zgłębienie tematu "reaktywnego programowania"

Odpowiedz Nowy wątek
2019-06-04 15:00
0

Nie wiem czy to dobry dział, ale najbardziej mi pasował.
Mianowicie - Od kilku dni czytam sporo o programowaniu reaktywnym i szczerze mówiąc albo natrafiam na złe przykłady/artykuły albo ciężko jest mi przyswoić tą ideę. Proszę więc o wsparcie w temacie tj namiary na jakieś sensowne i przystępne materiały/sugestie dotyczące nauki.

Do czego zmierzam - przykładowo ostatnio wyczytałem, że mongoDB jest przystosowane do pracy reaktywnej podczas gdy oracle nie bo sterownik jdbc jeszcze nie wspiera tego podejścia. Czyli tymsamym nie ma sensu pisanie kodu aplikacji w sposób reaktywny podczas gdy dana aplikacja ma korzystać z bazy oracle? Bo chyba albo całość reaktywna albo nie bo inaczej nie ma to sensu?
A jeśli tak to co właściwie cudownego zaimplementowano w tym mongo, czego nie ma w oracle. Przecież z mongo też jeśli trzeba wyciągnąć wszystkie rekordy to wszystkie. Jeśli jakąś kolekcję z "where" to tak samo... zwracamy userowi komplet więc gdzie tu "reaktywność"?

Jakby mi ktoś wyjaśnił podstawowe kwestie tego paradygmatu lub podrzucił jakieś nowe spojrzenie na temat będę wdzięczny ;)

edytowany 2x, ostatnio: Hepek, 2019-06-04 15:05
To jest chyba problem stricte Javowy jak rozumiem po treści i tagach? Może lepiej, gdyby do działu Java to przenieść? - somekind 2019-06-04 21:44
osobiście nie widzę problemu tym bardziej że istotnie interesowałaby mnie sfera Javy, dodałem tutaj bo wiem też, że samo pojęcie rekatywności nie musi być zależne od języka - Hepek 2019-06-05 08:26
Co do podejścia masz rację, ale jednak w innych językach już to jest rozwiązane, więc wygląda na ściśle Javowy problem. - somekind 2019-06-05 18:21

Pozostało 580 znaków

2019-06-04 15:17
2

Co masz na myśli przez "reaktywny"? To słowo ma kilka znaczeń

  1. FRP - functional reactive programming https://en.wikipedia.org/wiki/Functional_reactive_programming
  2. reaktywne w stylu, jakim propagują takie biblioteki jak Rx (działasz na takich jakby strumieniach). Trochę może się wydawać podobne do FRP, jednak nie do końca jest to to samo. FRP ma swoje założenia, których Rx nie do końca spełnia, ponieważ działa na eventach a nie na ciągłym czasie. https://twitter.com/headinthebox/status/504748845965004800
  3. reaktywne w stylu "samo się aktualizuje", czyli tak jak działa javascriptowa biblioteka Mobx czy Excel
  4. reaktywne w stylu manifestu reaktywnego https://www.reactivemanifesto.org/

Jak wspomniałeś coś o bazach danych, backendzie, to mi się to kojarzy z punktem 4 i tym, żeby systemy były niezawodne, ale z drugiej strony niektóre bazy danych (np. Firebase) są reaktywne w sensie 3, o tyle, że możesz się podłączyć pod bazę i mieć aktualnienia jak coś dojdzie, więc nie wiem dokładnie, co masz na myśli.


((0b10*0b11*(0b10**0b101-0b10)**0b10+0b110)**0b10+(100-1)**0b10+0x10-1).toString(0b10**0b101+0b100);
Ten punkt 4 to nie jest ReactiveX (w sensie punkt 2) tylko dla nietechnicznych i bez konkretów, żeby było łatwiej przyswajalne? - Michał Sikora 2019-06-04 15:32

Pozostało 580 znaków

2019-06-04 15:54
1

Słowo "reaktywny" jest często nadużywany z powodów marketingowych, gdy ludzie mają na myśli "asynchroniczny".
Co do baz danych to w tej chwili:

  • Oracle i PostgreSQL mają synchroniczny sterowni (synchronicznego klienta), tzn jeśli pytasz bazę o dane to wątek pytający jest zatrzymywany do czasu uzyskania odpowiedzi z bazy danych.
  • Cassandra i MongoDB mają asynchroniczny sterownik (asynchronicznego klienta), tzn jeśli pytasz taką bazę o dane to dostajesz obiekt Future (w Scali) lub Promise (w JS). Obiekt ten jest obietnicą, że kiedyś w przyszłosci dane dostaniesz. Twój wątek w tym czasie może wykonywać inne obliczenia.

Jeśli twoja aplikacja ma być odporna na duże obciążenieto warto pisać kod "reaktywny"/asynchroniczny, ponieważ wtedy tworzy się mniej wątków. A każdy wątek to straty na RAMie i CPU. Przynajmniej w Javie.

Ciekawostka: niektóre jezyki/platformy wymuszają pisanie aplikacji w sposób "reaktywnych"/asynchronicznych, ponieważ posiadają tylko jeden wątek/proces. Np. node.js (przynajmniej z tego co mi wiadomo)


Pozostało 580 znaków

2019-06-04 16:19
0

Oracle i PostgreSQL mają synchroniczny sterowni (synchronicznego klienta), tzn jeśli pytasz bazę o dane to wątek pytający jest zatrzymywany do czasu uzyskania odpowiedzi z bazy danych.

Niby tak, ale można też zrobić asynchroniczny sterownik (bazując np. na kqueue czy innym event loopie), a dodatkowo często używa się connection poola, który również powoduje, że nie trzeba blokować wątku robiącego zapytanie.

Pozostało 580 znaków

2019-06-04 18:10
2

Blokowanie wątku z puli to dalej blokowanie. Asynchroniczny sterownik do bazy nie blokuje żadnego wątku.


"Programs must be written for people to read, and only incidentally for machines to execute." - Abelson & Sussman, SICP, preface to the first edition
"Ci, co najbardziej pragną planować życie społeczne, gdyby im na to pozwolić, staliby się w najwyższym stopniu niebezpieczni i nietolerancyjni wobec planów życiowych innych ludzi. Często, tchnącego dobrocią i oddanego jakiejś sprawie idealistę, dzieli od fanatyka tylko mały krok."
Demokracja jest fajna, dopóki wygrywa twoja ulubiona partia.

Pozostało 580 znaków

2019-06-04 18:52
0
Kamil Żabiński napisał(a):
  • Cassandra i MongoDB mają asynchroniczny sterownik (asynchronicznego klienta), tzn jeśli pytasz taką bazę o dane to dostajesz obiekt Future (w Scali) lub Promise (w JS). Obiekt ten jest obietnicą, że kiedyś w przyszłosci dane dostaniesz. Twój wątek w tym czasie może wykonywać inne obliczenia.

Czyli można powiedzieć, że stukamy do bazy, baza "mieli" a wątek nie czeka na koniec "mielenia" tylko może w tym czasie obsłużyć inne lżejsze zapytanie i potem "wrócić" do tego jeżeli odpowiedź będzie gotowa?

Wibowit napisał(a):

Blokowanie wątku z puli to dalej blokowanie. Asynchroniczny sterownik do bazy nie blokuje żadnego wątku.

Dzięki za odpowiedź bo właśnie mnie to zainteresowało. Swoją drogą mam wrażenie, że tutaj zaczynamy mylić pulę wątków z pulą połączeń.

edytowany 1x, ostatnio: Hepek, 2019-06-04 18:55

Pozostało 580 znaków

2019-06-04 19:42
0

Asynchroniczny sterownik do bazy nie blokuje żadnego wątku.

Prawda, ale to czy sterownik jest synchroniczny czy nie, nie zależy od DB a od samego sterownika właśnie. To, że oficjalny sterownik jest synchroniczny wcale nie oznacza, że inne nie mogą być asynchroniczne. A czasami (ex. Elixir) to potrafi być jeszcze bardziej zagmatwane.

Pozostało 580 znaków

2019-06-04 20:27
0

Prawda, ale to czy sterownik jest synchroniczny czy nie, nie zależy od DB a od samego sterownika właśnie. To, że oficjalny sterownik jest synchroniczny wcale nie oznacza, że inne nie mogą być asynchroniczne.

Dokładnie. Stąd oprócz typowych blokujących sterowników do Postgresa i MySQLa są i nieblokujące jak np: https://github.com/mauricio/postgresql-async Niestety ten sterownik przestał być rozwijany. Oracle przygotowuje niby nowy standard ADBA https://blogs.oracle.com/java[...]-for-connecting-to-a-database ale z tego co widzę to rozwój idzie w ślimaczym tempie i chyba dalej jest to prowizorycznie oparte o blokujące JDBC (czyli jak na razie zysk żaden oprócz zaznajomienia się z API potencjalnie umożliwiającym nieblokujące działanie).


"Programs must be written for people to read, and only incidentally for machines to execute." - Abelson & Sussman, SICP, preface to the first edition
"Ci, co najbardziej pragną planować życie społeczne, gdyby im na to pozwolić, staliby się w najwyższym stopniu niebezpieczni i nietolerancyjni wobec planów życiowych innych ludzi. Często, tchnącego dobrocią i oddanego jakiejś sprawie idealistę, dzieli od fanatyka tylko mały krok."
Demokracja jest fajna, dopóki wygrywa twoja ulubiona partia.

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0