[czech] V Apiary používáme node.js v produkci už přes rok.
Proč se zamyslet nad tím, zda ho chcete? A na co se připravit a na co si dát pozor, pokud se do toho pustíte?
2. Historie
webu
(stručná
a
nepřesná)
Proč mě poslouchat a zabývat se node.js je dobrá otázka, takže nejprve historické okénko
3. Web
’95
Vznik webu: stránky jsou statické, jen nahrajeme HTML přes FTP. Easy-peasy, super.
Kdo umí vyslovit HTML bez zakoktání, bere velké peníze.
4. Web
27.8.2001
Dynamické “části”, menu, uživatelská jména a informace o posledním přihlášení, datum --
tedy šablony. Prorazil šablonovací jazyk PHP nad SSI a CGI, v jednoduchosti a graduální učící
křivce je síla.
Statická část se bouří, argumentuje rychlostí a mladostí “nových” a chce psát moduly v C,
případně řešit vše pomocí vkládání přes SSI (server-side includes).
Kdo umí vyslovit “CMS” nebo “SEO” bez zakoktání a nainstalovat Wordpress, bere velké
peníze.
5. Web
’05
CMS (content management systém, “redakční systémy”) a jejich následovníci. (Jedna) centrální
databáze, MVC framework, Rails, Django.
PHPkisti se bouří, argumentují pomalostí a neozkoušeností a Davídek Nettuje.
6. Web
’12
Více datových zdrojů, relační, grafové, dokumentové databáze, 3rd party APIs (více v dalších
slidech)
JavaScriptaři vymýšlí node.js. Djangisti argumentují neefektivitou, postačující rychlostí a
novostí bez knihoven.
Kdo umí vyslovit “UX” bez zakoktání a nakreslit čtvereček, bere velké peníze.
9. Více
datových
zdrojů
Analytická data v hadoopu, cache v memcached, grafová data v neo4j jste-li bohatí, mnohé
druhy dat v redisu, dokumentová data v mongu/couchi.
10. Y
U
NO
ORM
object?
nerelacni databaze se mnohdy nemapuji dobre na objekty
11. Data
z
jiných
služeb
Časté používání API jiných služeb.
12. haters
gonna
hate
node.js je jen jedna z variant. Kazdopadne, Djangisti a Rubysti argumentuji novosti, absenci
zakladni knihovny, pomalosti, neozkousenosti...
13.
14. Smyčka
Event loop. Jeden ze způsobů řešení parelelních přístupů, “obchází” cenu za kontext switch.
Něco jako cooperative multitasking ve Windows 3.11.
15. V8
Jedna z nejlepších language-specific VM, brutálně rychlá. Mozkový výkon by se dal utratit líp,
ale co se dá dělat.
Byť se tak místy snaží tvářit, pořád to samozřejmě není full-fledged platforma, které jsou
rozumné jenom dvě (JVM a .NET CLI).
16. JavaScript
Starý, ale lepší jazyk, než si myslíte. Má své chyby, ale jsou všeobecně známé. Nový
assembler webu.
17. ...všude...
Děsivá představa pro mnohé, ale kupodivu tím ten jazyk dostává lepší rozměr: šetří se
kongitivní kontext-switche z hranic mezi systémy.
18.
Kafe
pomáhá
CoffeeScript opravuje spoustu problematických míst JS, doporučuju.
Částečně ovšem ruší tu výhodu z předchozího slajdu, takže je dobré jím nahrazovat
konzistentně.
19. Neblokující
I/O
Neblokující != rychlejší. Je tu ovšem lepší odolnost proti problémům se sítí etc., kdy requesty
“umřou”, ale původní vlákno typicky stejně blokuje až do timeoutu.
20. Existující
komunita
JS umí spousta lidí, co měli tu smůlu, že pracovali na frontendu. Znamená to, že velmi rychle
vznikají knihovny na všechno a ”platforma” se posouvá dopředu překvapivě rychle.
21. Streamování
Výchozí přístup je, že se nebufferuje. Jak přichází data do systému (po chuncích po buffer
flushích), tak se zpracovávají. Člověk díky tomu designuje systémy na tohle zpracování tak
nějak defaultně, což je většínou v kontrastu s přístupem jinde. S pamětí to dělá dobré věci.
22. JavaScript meetup 29.11.
Felix Geisendörfer (node.js core commiter)
Writing high performance binary parser in
node.js
http://praguejs.cz/
...a hlasujte pro kvadrukoptéru, bude určitě levnější a zábavnější!!!11!!11!
23. Estetika
CoffeeScript: Když si člověk dá práci se zarovnáním šipek a rovnítek (editory pomáhají), kód
se velmi dobře čte. Vzhledem k tomu, že pokud to výkonnost dovoluje, je čitelnost snad
nejdůležitější atributu kódu...
24. tail
-‐f
/var/log/messages
|
coffee
logserver.coffee
Čteme input a posíláme ho v realtime do browseru. Super flexibilní v unix
ekosystému...zdarma prakticky na čtyři řádky.
Plný funkční kód s HTML bordelem je na https://gist.github.com/3756594
26. CPU
Na rozdíl od I/O, CPU je blokující. Cokoliv co se zasekne na procesoru (jako třeba regexp
catastrophic backtracking) “zabije” celý server.
27. Funkce
getData
=
-‐>
“mock
data”
Mějmě jednoduchou funkci, která vrací nějaká data -- ještě budeme řešit jaká, takže si
vrátíme něco co zatím stačí.
28. Změna
zdroje
dat
getData
=
(cb)
-‐>
Model.findOne()
(m)
-‐>
cb
m.data
...pak se k tomu vrátíme a data od někud skutečně vezmeme, třeba z databáze a vrátíme je
onomu callbacku...
29. ...který tam původně nebyl -> změna signatury funkce a flow všeho co ji používá.
Rule of thumb: pokud by se vaše funkce mohla dotknout libovolného I/O, rovnou si
předávejte callback.
30. Chybějící
callback
E.T. volat domu: stává se, že chyba v aplikaci se projeví tak, že člověk zapomene zavolat
finální callback/render do browseru, tj. žádný traceback, nic. Debugging toho je občas mírně
frustrující.
32. newFunction
=
-‐>
log
=
'abc'
newFunction
=
function()
{
var
log;
return
log
=
'abc';
};
Pakliže funkce ve vyšším scope neexistuje, správně se vytvoří s var, tj. jenom pro podřízený
scope --- výborně, opravuje to jednu z poměrně frustrujících věcí v JS (člověk omylem plevelí
globální scope).
33. log
=
require
'./log'
newFunction
=
-‐>
log
=
'abc'
log
=
require('./log');
newFunction
=
function()
{
return
log
=
'abc';
};
...nicméně pokud už tam stejná proměnna existuje (samozřejmě nezávisle na tom, jakého
typu), je místo toho přepsána. To znamená, že funkce nejsou zcela zapouzdřené -- jsou
ovlivňovány kontextem ze svého nadřazeného scope. IMO nedobrá volba.
34. API
je
pro
konzervy
Trochu souvisí s předchozími poznámkami. Komunita je mladá a kreativní a dynamická a
změn zpětné kompatibility se nebojí, s čímž je potřeba počítat. Node samotné už nicméně
dosti stabilní je na změny API dává pozor, ekosystém k tomu ještě musí dojít.
35. Výjimky
zabíjí
Neodchycená výjimka zabije celý proces/server a většinou to za vás nikdo moc neřeší:
standardní pattern je výjimky nevyhazovat, ale vracet v callbacích jako první parametr. Stát se
to ovšem z vašeho kódu může a je potřeba na to dávat pozor.
(Třeba node-raven se to snaží řešit přes raven.patchGlobal, ale funguje to tak nějak všelijak.)
36. Škálování
The guys that are getting paid the big bucks to
deliver scalable solutions aren’t up at night
feverishly rewriting their systems in Node.
They’re doing what they’ve always done:
measuring, testing, benchmarking, thinking
hard, keeping up with the academic literature
that pertains to their problems. That’s what
scaling in the large necessitates.
-- Alex Payne
Když řikám škálování tak myslim cestu ke Škálování, nikoli stránky velikostí čínského eshopu
jako seznam nebo centrum.
37. Concurrency
lock-‐in
Když člověk roste ke škálování, mění se přístupové vzorce. Díky tomu se v čase mění i
vhodná řešení. V node.js je člověk zamčen, nemá možnost volby -- All Hail To Mighty
Evenloop. Tohle časem člověka může bolet...na druhou stranu, v momentě, kdy řeší takové
problémy, tak to znamená, že je na tom dobře.
38. Kam
s
ním?
I/O bound věci
Distribuce dat (a APIs)
Proxy
Realtime / server push
Tam, kde se dájí sdílet data mezi serverem a klientem (tj. javascript-heavy appky nebo při
sdílení klíčové komponenty, jako třeba DSL/parseru).
39. The Way of Node
• Node
is
a
platform.
• Node
is
JavaScript.
• Node
is
callbacks
&
Streams.
• Node
is
not
pretending
it
is
blocking
when
it
is
not.
• Node
is
not
going
to
include
that
module.
• Node
is
for
building.
• Node
is
a
community.
• Node
is
faster.
• Node
is
fun.
-‐-‐
Mikeal
Rogers
Převzato z http://www.mikealrogers.com/posts/the-way-of-node.html , thx & kudos!
40. Až budete psát příští aplikaci, zamyslete se, jestli na daný problém více nesedí vhodnější
technologie, jestli jen neohýbate ty co znáte, protože jste po kotníky zakopání v nějaké
komfortní zóně.
No a kdyby vám to ve vaší firmě nechteli dovolit...