ugrás a tartalomhoz

Hanging Up On Callbacks: Generators in ECMAScript 6

complex857 · 2014. Júl. 28. (H), 22.18
Előadás arról, hogy ES6 generátorok hogyan használhatóak egymásba ágyazott callbackek helyett
 ■
1

Szerver

Hidvégi Gábor · 2014. Aug. 3. (V), 09.20
Igazából csak tegnap gondoltam bele, hogy miért úgy működik a node.js, ahogy, miért van szükség a callback-ekre – mivel a V8 alapvetően egy böngésző JS motorja, ahol az események más-más időpontban keletkeznek, és ezt kezelni kell.

Alapvetően más a helyzet egy szerveren, ahol tipikusan egy kérésre azonnal kell válaszolni, és nagyjából lényegtelen információ, hogy az I/O mennyi idő alatt fut le, mert mindenképp – még a kérésen belül – szükség van az eredményre.

A PHP nagy valószínűséggel belül pontosan ugyanúgy működik, mint a node.js, azaz eseményvezérelt, de elrejtik egy "dobozban", és csak a script futásának a végén kapjuk vissza a legenerált tartalmat. Ott is biztosan vannak callback-ek, csak nem látjuk őket.

Egy ugyanilyen dobozt kéne írni a V8 elé, elnevezni jobb.js-nek, és el lehetne felejteni a callback-ekkel, fiberekkel és generátorokkal való bohóckodást.
2

Webszerver

Poetro · 2014. Aug. 4. (H), 08.02
Node.js alatt nem feltétlen webszervert fogsz írni. Ahogy más keretrendszer vagy nyelv alatt sem. Go alatt is kb 10 sor alatt megvan egy webszerver, mégsem arra használják elsődlegesen (és jé, abban is callback-ek vannak). Egy olyan nyelvben, ami felkínálja a funkcionális programozás alapjait, szerintem igenis használjuk ki azt. Ha valakinek nem tetszik egy szerver oldali nyelv, választhat rengeteg másikat is.
A PHP teljesen másképp működik, mint a Node.js. Ott van egy webszerver, ami vezérli a kiszolgálást. Ez lehet Apache HTTPd, vagy Nginx stb. Az a webszerver minden egyes bejövő kérésnek indít egy PHP szálat, és utána a PHP egyetlen szálon folyamatosan blokkolva fut le. Azaz 100 konkurens kérés kiszolgálására több 100MB memória is elfolyhat. Node.js esetén egyetlen programszál van, ami, amennyiben HTTP szervert írunk, szolgálja ki a kéréseket pár MB memóriát foglalva.
3

Nem feltétlenül webszerverre

Hidvégi Gábor · 2014. Aug. 4. (H), 09.11
Nem feltétlenül webszerverre gondoltam, a php is és a node.js is használható parancssori scriptértelmezőként (mint a #/bin/sh) vagy bármilyen más kiszolgálóként.

A node.js 2009-es kiadása óta öt év telt el, mire találtak egy kényszerű megoldást arra a problémára, ami abból következik, hogy a V8-at böngészőben való futtatásra találták ki, nem szerverkörnyezetre.

Azaz 100 konkurens kérés kiszolgálására több 100MB memória is elfolyhat.
Érdekes módon ez a százmilliós nagyságrendű PHP-s oldal üzemeltetőjét nem zavarja. Valószínűleg az sem zavarná őket, ha a node.js is hasonló elven működne, csak százszor gyorsabban.
4

Érdekes módon ez a

BlaZe · 2014. Aug. 4. (H), 23.05
Érdekes módon ez a százmilliós nagyságrendű PHP-s oldal üzemeltetőjét nem zavarja. Valószínűleg az sem zavarná őket, ha a node.js is hasonló elven működne, csak százszor gyorsabban.
Mert nem lövik őket. Ahol komoly terhelés van, ott a process/thread-based model egy ponton túl nem működik. C10k problem. Amellett, hogy jóval erőforráspazarlóbb is. De nem érdemes összehasonlítgatni őket, teljesen máshogy működnek belül és másra jók.

A callback meg általában együtt jár az event-driven programminggal, nem a V8 sajátja.
In an event-driven application, there is generally a main loop that listens for events, and then triggers a callback function when one of those events is detected. In embedded systems the same may be achieved using hardware interrupts instead of a constantly running main loop. Event-driven programs can be written in any programming language, although the task is easier in languages that provide high-level abstractions, such as closures.
5

Egy átlagos website-nak

Hidvégi Gábor · 2014. Aug. 5. (K), 09.31
Egy átlagos website-nak (legyen mondjuk kétszázmillió) "szerencsére" nem kell ilyen problémával küzdenie (ti. nagy terhelés), viszont a callback-es programozás nem lehet egy nagy élmény, mert a videóban is utal rá az előadó, hogy a kollegái mennyire örültek már a generátoroknak is. Ez alapján azért le lehet vonni következtetéseket.

Másrészt ez választás elé állítja a node.js csomagok (npm) készítőit:
1, meghagyják a callback-eket, így viszont hosszú távon várható, hogy egyre kevesebben fogják karbantartani őket, mert a programozók számára fontos a kényelem,
2, újraírják a csomagot, ami elég nagy meló lehet.
6

JavaScript

Poetro · 2014. Aug. 5. (K), 14.08
A JavaScript-ben eléggé alapvető a callback-ek használata, rengeteg függvény fogad függvényeket (Array metódusok, String metódusok, eseménykezelők és a DOM API számos egyéb eleme), ezért természetes választás volt a Node esetén is ezek használata. Elvégre a Node.js-es modulok használata eseményeket figyel, amik bizonyos idő elteltével váltódnak ki.
Valószínűleg, akinek nem tetszik a JavaScript, akkor nem fog Node.js-t használni, elvégre az JavaScript-re épül, hanem használ helyette Java-t, Python-t, vagy Ruby-t.

Nekem például kifejezetten tetszik az eseményvezérelt programozás, és ahogy látom, azért vannak még rajtam kívül pár ezren. Ez egyébként segít a kód szervezésében is, mert az egyes működéseket önálló, kis függvényekbe, metódusokba csomagolja, ami javítja az egyes részfolyamatok átláthatóságát.
7

Akkor gondolom, hogy te nem

Hidvégi Gábor · 2014. Aug. 5. (K), 15.02
Akkor gondolom, hogy te nem örülsz kifejezetten a generátoroknak.
8

Nem zavar

Poetro · 2014. Aug. 5. (K), 15.28
Nem zavarnak a generátorok. Még egy lehetőség van a kód vezérlésére, ami nem igazán fog ártani senkinek. Főleg, hogy a támogatás egyelőre nagyon gyerekcipőben van (még Node.js esetén is külön kapcsoló kell, a beüzemeléséhez).