Új hozzászólás Aktív témák

• #6324 dqdb nagyúr Mr Dini #6321

  Új Válasz 2016-10-23 13:05:17 #6324

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  dqdb

  nagyúr

  válasz Mr Dini #6321 üzenetére

  Széllel szemben nehéz lesz

  Az egész Node.js éppen az aszinkron működésre épít, így minden esetben, amikor nem aktívan dolgozol, hanem valami erőforrásra vagy eseményre vársz, legyen az hálózatról adat lekérése, fájl írása* vagy adatbázis-művelet, mindig egy callbackben kapod meg a végeredményt. Ennek az az oka, hogy a szinkron várakozás blokkol egy feldolgozószálat, és csökken a szerver feldolgozási képessége, míg aszinkron esetben az adott szál lazsálás helyett értelmes munkára is befogható, vagyis egy másik kérés feldolgozására. Most mondhatod, hogy de te ezt nem kérted, azonban azzal, hogy a Node.js alapon álltál neki, pont egy aszinkron, threadpool alapú hatékonyan skálázódó platformra esett a választásod, így vagy megszoksz, vagy megszöksz ...

  Kókányolni szerencsére sajnos minden platformon lehet, így itt is, és valószínűleg ezt keresed (nem használtam soha, keresés dobta ki). De itt sem nem véletlenül kezdődik a leírás a Githubon elérhető legnagyobb betűméretű bekezdéssel, hogy miért ne használd ezt a libraryt.

  viszont gondolom node js-nél a CORS miatt nem megy
  A CORS böngésző szintjén értelmezhető csak. A Node.js azért nem támogatja az XHR-t, mert saját API-ja van, nem a böngésző DOM modelljét másolja.

  * ebből kivételesen létezik szinkron API is, de ennek ellenére a aszinkron felület felé terelnek a hivatalos dokumentációban:

  "In busy processes, the programmer is strongly encouraged to use the asynchronous versions of these calls."

• #6323 Jim-Y veterán Mr Dini #6321

  Új Válasz 2016-10-23 13:03:36 #6323

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Jim-Y

  veterán

  válasz Mr Dini #6321 üzenetére

  De ezt nem tudod megcsinalni, mert az asynchronous non-blocking I/O ahogy a javascriptet illetni szoktak lenyege pont az, hogy az async operationok nem blokkoljak a vegrehajtasi szalat. Magyaran, beallithatod te az XHR-t szinkronra, hogy amikor az mondod, hogy getPage(xyz) akkor az eredmeny rogton a DATA-ban legyen, de akkor az egesz javascript/nodejs filozofialval szembe mesz es amugy is ilyet nem csinalunk. Nem veletlenul minden async... Tenyleg javaslom hogy olvasgass kcsit a temaban, mert ugy tunik, hogy nem erted kristaly tisztan hogy hogy is mukodik a javascriptben az async.

  Magyarazat:

  a getPage belul egy requestet hasznal ami egy http keres lesz egy szerverre, amig erre a http keresre nem erkezik valasz addig NEM SZABAD blokkolni a stacket mert a javascript egy vegrehajtasi szallal (egy stackel) rendelkezik es minden UI is ezen "fut". Ha te egy szinkron kerest csinalsz, mint amit pont most szeretnel elerni akkor egez addig amig a tavoli szerver vissza nem ter addig SEMMIT sem tudnak a felhasznalok csinalni az oldaladon. Mondanom sem kell, hogy ez az egyik legnagyobb antipattern. Helyette aszinkron kell a tavoli szerver kerest kezelni. Vagyis... elinditod a kerest, majd rogton "visszaadod a vezerlest a fo szalnak" persze javascript eseten nincs ertelme ennek a mondatnak de igy konnyebb elkepzelni. Ami tenylegesen tortenik az az hogy amikor elinditasz egy requestet akkor a webapi regisztral egy callbacket amit tcp socket valasz eredmenyevel fog meghivni. Promiszok eseten a callback egy rezolvalt promis lesz.

Új hozzászólás Aktív témák