Zgłębienie tematu "reaktywnego programowania"

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 ;)

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.

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)

1

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.

2

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

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ń.

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.

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/jdbc-next:-a-new-asynchronous-api-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).

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