ReactPHP - ktos cos? Opcje

[nospor]

Hejka, uzywa(l) ktos z was reactPhp i moze cos powiedziec na jego temat, jak sie zachowuje, czy warto itp? Z gory dzieki (IMG:style_emoticons/default/smile.gif)

edit: pozwole sobie odswiezyc temat, bo spora czesc userow byla na phpcon, teraz wrocili, to moze nie zauwazyli tematu (IMG:style_emoticons/default/wink.gif)

[Skie]

Tak, ale żeby opisać czy też odpowiedzieć potrzebuję konkretnego pytania (IMG:style_emoticons/default/smile.gif) ReactPHP to jest zbiór różnych asynchronicznych komponentów a nie jednolita technologia, i jedne działają lepiej, inne gorzej. Osobiście polecam zamianę komponentów Reacta na komponenty Krakena, gdyż dużo problemów jakie miał React udało mi się naprawić, a sam interfejs jest taki sam (+dodatkowe metody) lub bardzo zbliżony. Wiem, że to zalatuje na kilometr autoreklamą, no ale co poradzić, jeśli działają lepiej?

Reacta używałem w kilku projektach przy projektowaniu gier przeglądarkowych w PHP. React sam w sobie jest po prostu implementacją asynchronicznych obliczeń w PHP na pojedynczym wątku z wykorzystaniem programowania opartego o zdarzenia (event-driven development). Główna częścią tej technologii jest Evenement i Event-Loop. To pierwsze to jest implementacja klasycznego tandemu zdarzeniowego EventEmitter-EventListener w PHP, co pozwala na tworzenie loosely-coupled architecture, a drugie to kolejka zdarzeń. Cały React działa właśnie na bazie tego drugieg komponentu - pętli. Pętla w nieskończoność sprawdza czy istnieją do wykonania jakieś funkcje, timery oraz sprawdza czy są dane do zapisanai do strumieniu, a także czy do tych strumieni przyszły dane, które warto odczytać, a następnie je wykonuje.

Oprócz tych dwóch podstawowych modułów, wartym uwagi na pewno są jeszcze Promise, które jak nazwa wskazuje jest implementacją specyfikacji Promise/A+ w PHP, Promise-Timer który dodaje timeouty do nich oraz Stream implemetujący asynchroniczne strumienie.

Nie opłaca się korzystać z komponentów takich jak Socket, Http, Http-Client czy Datagram. Zamiast nich polecam wykorzystać bibliotekę Ratchet, która to wszystko ma lepiej zrobione i wciaż jest kompatybilne z Reactem. Ratchet to osobna biblioteka rozwijana przez tego samego autora co React.

Dużo komponentów obecnie też wymarło - chociażby Zmq - gdzie od ponad roku czekam na akceptację lub odrzucenie mojego pull requesta z fixami, co skończyło się z tym, że zaimplementowałem Zmq sam.

To teraz bardziej ogólnie. React jest stosunkowo prosty w użytkowaniu ze względu na to iż każdy webdeveloper miał styczność z programowanim opartym o zdarzenia w JS. Do tego jest bardzo wydajny, w PHP7 bijący nawet Node.js. Największe problemy Reacta to polegania na bibliotece Evenement, w której wycieka pamięć przy jednorazowych zdarzeniach i która już od dłuższego czasu nie jest rozwijana, a także fakt, że React nie posiada dobrego mechanizmu do rozpraszania obliczeń na wątki i procesy. Tak, istnieje child-process, ale to tylko potrafi spawnować nie-odizolowane procesy i korzystać z ich STDOUT i STDIN. I tutaj pojawia się pewna ironia - by w pełni wykorzystać Reacta, potrzeba używać wielu procesów, które React jako tako nie wspiera i całą ich logikę - wymiany informacji, łapania błędów, deployment i bootstrap programista musi sam zaimplementować. To dla mnie było największym problemem z pracą z Reactem. Sam React jest wydajny i w miarę stabilny, ale tak jak pisałem, wymaga dużo dodatkowego boilerplate'u.

Jak macie jakieś konkretne pytania , odpowiem na wszystkie.

EDIT:

Jeśli interesują was tego typu rozwiąznaia to oprócz React PHP i Kraken PHP istnieje jeszcze trzeci zestaw bibliotek asynchronicznych dla PHP - Icicle.io. Icicle jednak ma całkowicie inne podejście do asynchroniczności, oparte o trick z generatorami. Ich metoda sprawdza się lepiej w programowaniu współbieżnym*, ale jest trudniejsze do opanowania i ma poważne problemy z kompatybilnością z bibliotekami PHP, które nie bazują na generatorach.

* Mówiąc współbieżnie, mam na myśli parallel programming. Icicle świetnie sprawdza się do tego typu programowania, ale nie jest lepszy od Reacta w kontekście distributed i concurrent programmingu.

EDIT2 :

Dużo ciekawych informacji odnośnie Reacta zawarł na swoim blogu Wyrihaximus, który jest teraz jednym z najbardzije udzielających się contributorów Reacta.

Ten post edytował Skie 6.10.2016, 17:37:43