NodeJS - dobre podejście? Czemu Long Pooling zamiast WS?

Witam. 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ę :)

Jest to dobre podejście? Jakieś minusy tego rozwiązania?

Twoje drugie podejście zdaje się być przeinżynierowane - czy przeprowadziłeś benchmark udowadniający namacalnie, że warto tak bardzo komplikować całą architekturę?

Czemu Long Pooling zamiast WS?

1. WS nie są wspierane w niektórych starszych przeglądarkach.
2. Skoro mają już ogromną infrastrukturę opartą o long polling, która działa prawidłowo... po co ją przepisywać? Byłaby to tylko strata czasu.

Patryk27 napisał(a):

Jest to dobre podejście? Jakieś minusy tego rozwiązania?

Twoje drugie podejście zdaje się być przeinżynierowane - czy przeprowadziłeś benchmark udowadniający namacalnie, że warto tak bardzo komplikować całą architekturę?

Nie, ale wydaje mi się, że to słuszne rozwiązanie. Pobierając użytkownikowi po kilka postów do wyświetlenia (infinite scroll jak na FB), jeden request szedłby do bazy MySQL, a potem jeszcze dodatkowo pętlą przelatuję po pobranych postach i do każdego z nich pobieram dodatkowe rzeczy, czyli kolejny request by pobrać imię nazwisko i avatar autora postu, jeśli jakieś zdjęcia ma ten post to kolejny request by pobrać ścieżki do tych zdjęć albo jeśli to post o utworzeniu wydarzenia to zamiast pobierania zdjęć - idzie request do bazy by pobrać dane wydarzenia - więc średnio do każdego pobranego postu dochodzą po 2 requesty na pobranie dodatkowych danych - przy większej liczbie użytkowników takie rozwiązanie wydaje mi się, że zajechałoby mi bazę. Dlatego chciałem zoptymalizować ten proces formatowania pobranych postów właśnie przez użycie NodeJS i tych obiektów z listą wydarzeń, użytkowników itd by nie zaciągać już ich z bazy, ale ktoś mi napisał że na maszynie wirtualnej na której odpalany jest NodeJS, działa sobie Garbage Collector i po jakimś czasie usunie mi wskaźniki do tych obiektów :/ Zamiast tych obiektów w NodeJS, powinienem użyć memcache lub Redisa?

Może w ogóle za bardzo kombinuję? Jakaś inna, lepsza opcja?

Nie, ale wydaje mi się, że to słuszne rozwiązanie.

Dlaczego wydaje Ci się, że jest to słuszne rozwiązanie?

przy większej liczbie użytkowników takie rozwiązanie wydaje mi się, że zajechałoby mi bazę.

Na podstawowym serwerze (w stylu kilka GB RAMu + wielordzeniowy procesor) MySQL powinien być w stanie uruchomić kilkadziesiąt tysięcy SELECTów na sekundę - gdy już dojdziesz do momentu "zajeżdżania" tej bazy, prawdopodobnie będziesz zarabiał z reklam tyle, by bez problemu pozwolić sobie na wynajem klastra RDS w Amazonie... w dalszym ciągu bez potrzeby zabawy w mikroserwisy ;-)

Dlatego chciałem zoptymalizować ten proces formatowania pobranych postów (...)

Ale co chcesz optymalizować? Skąd wiesz, że Twoje rozwiązanie z mikroserwisami nie okaże się wolniejsze (protip: prawdopodobnie tak by było), skoro nawet nie masz punktu odniesienia?

Napisz najpierw wersję podstawową (taką z wykorzystaniem standardowej relacyjnej bazy danych, renderowania po stronie serwera itd.) i dopiero potem, jeśli pojawią się problemy wydajnościowe, zastanów nad przemigrowaniem w coś rozproszonego - popyt i podaż.

Zamiast tych obiektów w NodeJS, powinienem użyć memcache lub Redisa?

Redis jest wydajnościowo bardzo zbliżony do MySQLa oraz innych baz danych (zresztą nic dziwnego, nie ma tam żadnej magii - pod spodem wszystko śmiga sobie na B-drzewach oraz innych, podobnych algorytmach), więc nie zyskałbyś tym sposobem nic, czego nie możesz osiągnąć bez komplikowania sobie życia.

Może w ogóle za bardzo kombinuję? Jakaś inna, lepsza opcja?

W tej chwili dywagujesz na temat problemu, który prawdopodobnie w ogóle się nie pojawi - gdy dojdziesz już do sytuacji kilkudziesięciu tysięcy użytkowników online w jednej chwili, będziesz miał o wiele więcej znacznie istotniejszych kwestii do rozwiązania niż to czy formatować posty w PHPie, czy może też w mikroserwisie napisanym w NodeJS.

Sugeruję pójść najbardziej pragmatyczną drogą i nie szukać problemów tam, gdzie ich nie ma - najpierw napisz aplikację z wykorzystaniem technologii, które znasz, a potem dopiero łataj ewentualne problemy, które zaczną pojawiać się na horyzoncie.

Zdaję sobie sprawę, że prawdopodobnie wydaje Ci się to najzwyczajniej w świecie nudne (bo przecież cały świat już działa na mikroserwisach, hello!), lecz uważam, że jest to najsensowniejsza decyzja, jaką można w tej chwili podjąć - najważniejszym jest zrobić coś, niż pół roku zastanawiać się nad problemami, z którymi być może nigdy nie przyjdzie Ci się zmagać.