Tagnodejs

NodeJS: neodchycené výjimky

Premisa 1: JavaScript, potažmo TypeScript, je komplexní, mocný programovací jazyk. Krom všeho možného 🙂
Premisa 2: všichni děláme chyby…

Je dobré o chybách vědět.
A to je cílem tohoto kódu:

Tento krátký kód se postará o obsluhu všech neodchycených výjimek kdekoliv v aplikaci. A proto je dobré jej umístit někam do míst startu aplikace, aby vše, co je španě, někde nepropadlo. V samotné funkci obsluhy výjimky pak může být cokoliv co vám dává smysl: výstup do konsole, notifikace někam přes sít, či cokoliv jiného co vám dává smysl.

Více zde.

ES moduly v NodeJS

Modularita, co by nezbytná vlastnost jakéhokoliv programovacího jazyka pro psaní velkých aplikací, je v NodeJS zajištěna pomocí funkce require. Samotnou fyzcickou definici a implementaci pak zajišťuje CommonJS.

Takže takto v NodeJS

JavaScript a import

JavaScript, skrze svou specifikaci ECMAScript 2015 zavádí, mimo jiné, i nové klíčové slova import a export pro možnost modularizovat javasxriptový kód.
To dovoluje následující zápis kódu:

Tohle vám bude například fungovat, pokud píšete React, VueJS, nebo Typescript aplikaci, protože ta je teprve skrze nějaký transpiler kompilována do požadované verze JavaScriptu.

Nicméně v NodeJS import nefunguje… Zatím 🙂

node –experimental-modules

A tady přichází na scénu parametr příkazového řádku --experimental-modules, který vám umožní v NodeJS používat klíčové slovo import místo require. Přesně tak, jak byste jej použili v Reactí apce…
Opravdu píšu místo, protože obě možnosti zatím nejdou kombinovat.
Takže pokud spustíte NodeJS script s tímto parametrem, můžete použít novou syntaxi pro importování, ale samozřejmě i exportování na úrovni modulu:

Dalším rozdílem je samotná přípona souboru se zdrojákem. Původní require funguje v klasických .js souborech, nově import pak v souborech s příponou .mjs.
Samozřejmě můžete import přímo psát do.js souboru a spouštět pokaždé s potřebným parametren, ale je to proti zavedené konvenci a navíc, nejde na první pohlef vidět jaký způsob práce s moduly jste použili.

Moje doporučení?

Pište v TypeScriptu 🙂 budete moct v .ts souborech použít obě konstrukce pro import, ale vedle toho mnohem víc věcí, které JavaScript dělají skutečně silným programovacím jazykem.

NPM: link

Pedpokládám, že každý kdo něco píše v JavaScriptu, nebo TypeScriptu zná NPM.
Pro ty co jsou tu prvně: největší a nejrychleji rostoucí repozitář (knihovna) javascriptových modulů. Samozřejmě se vším co k tomu patří.

Vedle toho, že NPM je nějaký síťový, skrze internet dostupný, centrálně spravovaný, byste třeba někdy chtěli dosáhnout stejného chování balíčků pomocí require pro nějaké vlastní, lokálně vyvíjené moduly, které neopustily disk vašeho notebooku.

NPM lokálně

Příklad

Mám někde na disku adresář, ve kterém mám vlastní implementaci super výkoné matematické knihovny:

zdrojový kód mé knihovny:

package.json v adresáři s knihovnou:

Tak a tenhle modul bych chtěl pak používat v dalších svých projektech stejně jako jakýkoliv jiný modul, který pochází z NPM.

Jak na to?

1. zaregistrování modulu

V adresáři s balíčkem ./my-math-lib spustím následující:

Tím dojde k vytvoření sym linku do globálního prostoru NPM balíčků na vašem stroji. O tom, že balíček se zaregistroval se přesvědčíte následovně:

2. samotné využití požadovaného balíčku

Pak už jen stačí v adresáři s projektem, kde chcete váš balíček používat spustit následující:

V podstatě náhrada za

Protože příkaz install by hledal a stahoval balíček z centrálního, síťového repozitáře a to nechceme.

Pak už můžeme v projekt klasicky použit require jak jsme zvyklý:

Resume

Celý fígl je v tom, že příkaz npm link vytváří symlinky mezi globálnín NPM uložištem na vašem stroji a adresářem node_modules v daném projektu.
Super je, že zůstává plně zachována plná funkcionalita práce s baličky, takže funguje i toto:

Tím dojde k odebrání balíčku z daného projketu, nicméně sdílený balíček půjde dál využívat v ostatních projektech.
Pokud budete chtít úplně zrušit sdílení lokálního balíčku, pak následovně:

Elegantní a hezhé řešení…

NodeJS: JWT autorizace

JWT je docela jednoduchá metoda použitelné k autorizaci. Princip fungování asi nejlépe popíše samotný obrázek s diagramem:

Součástí vráceného tokenu mohou být jakákoliv data získaná při autorizaci na serveru, protože jsou vráceny zakódovaná. Data si takto můžete předávat v aplikaci dál. Každá zabezpečená routa může dostat do svého requestu dekódovaná data a dál s nimi pracovat

Opravdu jednoduchá implementace

Samotnou práci s JWT zajišťuje NPM balíček jsonwebtoken. Nejdůležitější je asi samotná funkce verifyToken jako Expressjs midleware funkce, ktará zajišťuje JWT autorizaci. Vše ostatni je jen obsluha jednotlivých rout…

POST /login – získání tokenu, kde v body je email a password
POST /data – zabezpečené načítání dat, kde v requestu musí být ‚token‘ získaný z /login a pak v odpovědi jsou požadovaná data.

Routa /data samozřejmě může fungovat i na metodě GET, ale pak by bylo potřeba přepsat autorizačni funkci midlewaru tak, aby token hledala například v hlavičce requestu. Nic složitého…

NodeJS: new Buffer

Už delší dobu se vedou diskuze kolem konstruktoru new Buffer, které, jak to vypadá, skončí uvolněním NodeJs ve verzi 10, kde tato konstrukce bude označena za deprecated. Pokud tedy někde ve svých projektech Buffer používáte, měli byste začít refaktorovat svůj kód a nahrazovat volání konstruktoru za jeho alternativní metody:

Pokud ve svých projektech používáte ESLint, tak stačí, když upravíte jeho konfiguraci a on vám olintuje a vyhodí všechny výskyty deprecated volání konstruktoru a můžete docela jednoduše a rychle refaktorovat.

Digitální transformace s NodeJS DevOps stackem

PayPal, Netflix a Wallmart představují způsob jak rychle transformovat legacy software.
node-js-devops-stack-transformation

JavaScript: promises a async/await

Jsem si vědom toho, že o promises toho bylo napsáno dost. Určitě už ale o něco méně o async/await. Nicméně z diskuzí s javascriptovými vývojáři, kterých se v poslední době účastním, mám pocit, že většina z nich vidí async a promise jako zcela odlišné techniky, které krom toho, že řeší stejný problém, chápou jako zcela odlišné věci.

Promises


Určitě ne ideální, ale plně funkčnní javascriptový kód, který pomocí promises řeší asynchronní operace, byť se v příkladu jedná o obyčejné matemtické operace. Důkaz že asynchronně se dá psát i non-blocked kód 🙂

Async/Await


Přepsal jsem výše uvedený kód z promises do async/await.

Vlastně nepřepsal 🙂 Použil jsem všechny jednotlivé funkcionality tak jak jsou s primises a jen jsem nahradil chain volání v promisách implementovaný skrze then do jedné jediné funkce, uvozené klíčovým slovem async. Samotné volání může vypadat složitě, ale to jen kvůli IIEF, které jsem v příkladu použil.

Suma sumárum

Async/await přímo staví na promises. Je vnitřně naiplementovaný skrze promises. Jen zavádí novou konstrukci zápisu, která může být programátorům přicházejících ze světa blokujících operací na první pohled bližší, než více méně funkcionální zápis v zřetězeném chainu pomocí holých promisí.

Osobně se dál držím callbacků, ale pokud bych musel šáhnout po něčem z výše popsaném, vyberu si async/await konstrukci.


PS: calback hell není vlastnost jazyka, je to jen špatně navržená kompozice jednotlivých funkcionalit 🙂

SocketIO v NodeJS (předpověď počasí)

Našel jsem moc hezký článek jednoduše popisující SocketIO. Takže jestli hledáte technologické řešení, jak komunikovat s návštevníkem vaší www stránky v reálném čase, pak věřte, že to už nejde jednodušeji…

NodeJS: NODE_ENV dev || production

Taková ta uplná klasika: vyvíjíte aplikaci na svém stroji, kde máte samozřejmě úplně jinou konfiguraci, než na produkčním serveru, respektive také odlišnou od konfigurace kolegy, který se snaží psát pod Windejsi.
Tou jinou konfigirací může být cokoliv. Od propojení na externí služby až po způsob logování toho co a jak chcete vidět. Jasně že na developu vás zajíma víc věcí, které chcete na produkci vidět až když řešíte nějaký problém…

A řeči o tom, že byste měli kontejnerovat, dokrovat a tak vás taky nebaví. Nevidím jediný důvod, proč bych měl na svém lokále sestavovat nějaký dokr a pak spouštět virtuální stroj… WTF! Jediné co chci je spustit apku na mém mekovi prostě jinak nakonfigurovanou, ale funkčně pokud možná co nejvíc identickou s produkčním prostředím…

Dřív jsem rozdílnou konfiguraci do aplikace zaváděl skrze parametr příkazové řadky. Vstupní JS modul aplikace rozparsoval parametry příkazové řádky. Pokud našel parametr udávající soubor s konfigurací, pak se jej pokusil naimportovat. Pokud nic takové, pak natáhnul nějakou defaultní konfiguraci… Super. Funguje skvěle a umožnuje opravdu dobře nakonfigurovat kde co a to pokaždé úplně jinak. Prostě jak je libo…

Jenže jsem línější a línější a i tohle mi připadalo jako opruz. Je to přece jen nějaký kód navíc.. Já vím, že ne moc, ale je… Stačilo mi prostě něco lehčího.

NODE_ENV

A tak jsem se vrátil k NODE_ENV. Ne že bych o ní nevěděl, ale protože jsem vytvářel přece jen složitější struktury, mírně jsem podcenil možnosti této enviroment proměnné, a proto jí nějak moc rychle přeskočil. Chyba. NODE_ENV mi umožňuje dál lenošit a odpadl problém s konfigurací.

Jediné co jsem musel ořešit je jak NODE_ENV propašovat v různých způsobech spouštění, či využívání přímo do aplikace. Apku spouštím různě a nechtěl jsem se připravit o konfort kastomizovaných konfiguráků specifikovaných z příkazové řádky.

Základní implementace v package.json skrze sekci script:

Pokdud spouštíte apku z shellu, pak takto:

No a pokud potřebujete NODE_ENV sdílet s dalšími nástroji, jako je gulp, nebo cokoliv jiného, pak:

Samotný JS kód se pak k proměnné prostředí dostane odkudkoliv skrze globální promenou process, která obsahuje celý ENV, včetně toho co sami nějak nadefinujete:

Takže můj konfig dnes může vypadat i takto:

Samozřejmě se i tohle dá napsát jinak, dle libosti… 🙂

Nicméně tohle je obecný přístup, kterým se dá do vaší apky propašovat jakákoliv proměnná z prostředí operačního systému…

NodeJS, Module patterns

NodeJS Module Patterns

© 2018 pepa.holla.cz

Theme by Anders NorénUp ↑