Node.js adatok frissítése
2021-05-15T16:46:44+02:00
2021-05-15T20:30:30+02:00
2022-08-12T02:41:46+02:00
Zas
Sziasztok!


Végre sikerült egy olyan szerverre költözni ahol van Node.js futtatás. A lényeg hogy nem igazán ismerem még, de példát se találtam arra hogyan lehetne megoldani nodejsel. Van egy php fájlom, ami update.php. Ha ez a fájl lefut, akkor frissiti az adatokat, amit div tag-el kiíratok. (Online felhasználók, Online felhasználók száma) Aki be van jelentkezve, annak kiosztja a kreditet. Ezt Ajax-al oldottam meg, viszont terheli a szervert. 

function loadData() { $.ajax({ type: "GET", url: "update.php", async: true, cache: false, dataType: 'JSON', success: function(data){ $('#online').html(data.online_users); $('#online_user_list').html(data.online_user_list); $('#online_credit').html(data.online_credit); }, complete: function(jqXHR, textStatus) { //console.log("Siker."); setTimeout("loadData()", 6000); }, error: function(jqXHR, textStatus, errorThrown) { console.log(textStatus, errorThrown); } }); } loadData();
Esetleg valakinek van ötlete arra hogyan lehetne ezt megoldani nodejs-el? Ha tudsz valami példát amin elindulhatod annak örülnék.
Mutasd a teljes hozzászólást!
Igen, én a helyedben websocket-tel mennék. Sokkal egyszerűbb, mint a két szerveres (és nem utolsósorban két tech stackes) megoldás valamint a terhelést is csökkenteni fogja.
Mutasd a teljes hozzászólást!

  • Jól értem, hogy pollozol? (Bizonyos időközönként a JavaScript kódod meghívja a PHP scriptet.)
    Igazából ez egy teljesen bevett technika az adatok közel-valósidejű frissítésére. Van még két másik opció:
    long-polling: Ez azt jelenti, hogy a webszerver nem válaszol, amíg valamilyen adatot nem kell frissíteni a kliensen. Persze timeout történhet, ilyenkor a kliens új request-et indít.
    server-sent events: Ez egy állandó kétirányú kommunikációs csatornát jelent a kliens és a szerver közt, vagyis a szerver is küldhet adatot a kliens számára, amikor kedve tartja. Itt is figyelni kell arra, hogy a kapcsolat bármikor megszakadhat, de cserébe nem közel-valósidejű, hanem valósidejű az adatközlés.

    Igazából a (long-)pollingnak és a server-sent events módszernek is van előnye és hátránya. Ha a szerver horizontálisan skálázható és load balancer mögött futnak az instance-ok, akkor a (long-)polling gyakorlatilag azonnal működik, ami a server-sent events esetében nem mondható el. A load balancert kell ebben az esetben konfigurálni úgy, hogy engedélyezve legyen rajta a sticky sessions (a load balancer a request-eket ugyanarra az instance-ra továbbítja), illetve akár közös Redis backendre is szükség lehet szerver oldalon.

    Léteznek erre már kiforrott technológiák. Én .NET-es vagyok és a SignalR-t ismerem, ami támogatja mindhárom transport módszert. JavaScript backenden úgy tudom, a socket.io-t szokták használni. Én azt gondolnám, hogy ez is tudja mindhárom módszert, de a server-sent events-t mindenképp. Jobban utána kellene nézni. De ezek a lehetőségek.
    Mutasd a teljes hozzászólást!
  • És legvégül van a websocket szabvány, ami az általad felsorolt workarond-ok (short/long-polling) és félmegoldás (SSE) helyett egy full-duplex kommunikációs csatornát épít a kliens és a szerver között. A SignalR és a socket.io is alapból websocket-et preferál és az összes többi kommunikációs technika csak fallback mechanizmusként szolgál arra az esetre, ha a ws nem működne.

    A kolléga kérdését pedig személy szerint nem értem. Lecserélné a php backend-et nodejs backend-re, majd bedob egy kliens oldali scriptet, ami egy BE endpointot hív meg és a kérdés, hogy mindezt hogyan lehet megcsinálni nodejs alatt. Ha nem tudja hogyan kell egy API-t összerakni node alatt, akkor miért kell leváltani a php-t? Nem tudja, hogy a node backend oldali technológia? Node-ról akarja hívni a php servert? Vagy netán más a gond és a node csak elterelésként van a kérdésben?
    Mutasd a teljes hozzászólást!
  • Akkor ezt rosszul tudtam. Köszi ^^
    Mutasd a teljes hozzászólást!
  • Én azt akarom hogy a Node server legyen terhelve, ne a webszerver. :) Ugyebár a mostani update 6 másodpercenként frissít / kliens. Például ha van 200 online felhasználó, akkor 200 kliens terheli a webszervert.
    Mutasd a teljes hozzászólást!
  • Most a kliensed a php server-eden az /update.php url-t hívja az adatokért. Ezt a funkcionalitást újra kell implementálnod nodejs alatt és elérhetővé kell tenned valamilyen url-en (pl.: https://mynodejsurl/nodeupdate) Ezután a kliensednek ezt az url-t kell hívogatni. Ezzel egyébként a serverek elhelyezésétől függően egy rakat probléma lehet mint CORS vagy authentikáció.

    Ha van valamilyen esemény, ami frissíti a mögöttes adatokat, akkor valószínűleg egyszerűbb lenne, ha a php szerveredről értesítenéd a klienseket websocketen keresztül arról, hogy változott az adatállomány. Ezzel megszabadulnál a 6 sec-es pollingtól és csak annyiszor kellene kommunikálni ahányszor az adat ténylegesen frissül is.
    Mutasd a teljes hozzászólást!
  • Akkor lényegében jobban járok ha lecserélem PHP SSE-re?
    Mutasd a teljes hozzászólást!
  • Ratchet-re gondoltam.
    Mutasd a teljes hozzászólást!
  • Igen, én a helyedben websocket-tel mennék. Sokkal egyszerűbb, mint a két szerveres (és nem utolsósorban két tech stackes) megoldás valamint a terhelést is csökkenteni fogja.
    Mutasd a teljes hozzászólást!
abcd