Witam. Nie wiem czy w dobrym dziale piszę, więc z góry przepraszam jeśli to niewłaściwy dział
Piszę sobie portal społecznościowy i chciałbym się upewnić czy dobrą drogą podążam.
Backend głównie piszę w PHP 7, ale postanowiłem przerzucić wyświetlanie (i formatowanie postów do wyświetlenia) z PHP do NodeJS, ponieważ przy formatowaniu postów do wyświetlenia, pobieranych jest trochę danych (nazwa i avatar autora postu, ewentualne zdjęcia, ewentualne "event data" [np. jeśli to post o utworzeniu wydarzenia - to pobieram dane wydarzenia by wstawić info o wydarzeniu w tym poście]). Pomyślałem, że zamiast pobierać te dane za każdym razem po requeście do PHP, to zrobię sobie przechowywanie i aktualizowanie tych danych (użytkowników, wydarzeń, itp.) w obiektach na serwerze NodeJS, i przy formatowaniu po prostu będę wyciągał sobie potrzebne dane z obiektów - a nie z bazy danych. Jest to dobre podejście? Jakieś minusy tego rozwiązania?

Do tego serwera NodeJS (który odpowiada tylko za to pobieranie i formatowanie postów [pewnie jeszcze jakaś dodatkowa robota dojdzie dla niego]) łączę się poprzez WebSockety z przeglądarki, i mam jeszcze drugi serwer NodeJS (odpowiada za wiadomości prywatne między użytkownikami) z którym również tworzę kolejne połączenie WebSocket z przeglądarki - i moje pytanie jest następujące - czy jest to dobra droga? Sprawdziłem kilka dużych serwisów (Facebook, LinkedIn, Pinterest, Twitter) i nigdzie nie zauważyłem WebSocketów - a jedynie Long Pooling. Ja coś źle robię, czy oni używają Long Pooling z innego powodu (np. przez load balancing)?

Będę bardzo wdzięczny za wskazówki i konstruktywną krytykę

JS tak samo jak PHP to języki interpretowane uruchamiane w maszynie wirtualnej, która posiada swój odśmiecacz pamięci (garbage collector). To co chcesz zrobić to jest bardzo złe podejście, dlatego że garbage collector po prostu po czasie wyczyści ci wskaźniki do tych obiektów (wywali je z pamięci). W takim przypadku powinieneś używać jakiejś pamięci podręcznej, w stylu memcache, redis czy podobne, narzędzia stworzone do tego celu.

Jeżeli nie masz 2 kierunkowej komunikacji, na styl czata, to websockety tylko do wysyłania informacji do użytkownika, są najzwyklej overkillem. Między innymi loadbalancing jest problematyczny, ale i sama ilość połączeń jakie taki serwis pokroju FB musiałby utrzymywać jest astronomiczna. A przechodząc do mobilnych urządzeń, gdzie takie połączenie byłoby często ubijane oraz zrywane, jest zwyczajnie mega problematyczne.

Aktualnie większość tych rzeczy mógłbyś rozwiązać bezpośrednio w przeglądarce, cache jako session storage/local storage/indexedDb, a pobieranie danych w tle przy użyciu service workera, który mógłby aktualizować wiele otwartych kart/okien przy użyciu jednego requesta. Więc przerzucasz całą logikę na klienta (przeglądarkę) i odchodzi ci sporo pracy. I właśnie tego np używa gmail, fb, twitter. Będzie działać na mobilkach, będzie działać na dekstopie.

Czyli nawet wyczyści mi zmienną, w której zliczałbym sobie liczbę obecnie podłączonych użytkowników do serwera NodeJS i powinienem także do tego użyć pamięci podręcznej?


Czyli w tym moim przypadku lepszy od websocketów byłby zwykły AJAX-owy request do Nodejs, a z Nodejs zrobić endpoint api?

Jeżeli zmienna nie będzie miała żadnych referencji to zostanie wywalona z pamięci. Tak samo jest w PHP, tylko natura PHP jest inna niż JS'a dlatego tego od razu nie zauważysz.