CategoryNezařazené

sleep(), nebo wait() v NodeJS

Znáte to: čas od času byste rádi na něco počkali. A zrovna to čekání není moc v souladu s asynchronní povahou samotného NodeJS.

NodeJS, narozdíl od sleep v PHP, nebo time.sleep v Pythonu, žádnou takovou funkcionalitu, zaplať pán bůh, nemá.

Proč byste měli třeba čekat?
Modelová situace: někde na vaší API, nebo někde úplně mimo váš dosah, spustíte například nějakým POST requestem proces, který nevíte kdy skončí, nebo jak dlouho bude trvat. Takže vám nezbude nic jiného, než se stále dokola ptát na nějakém endpointu, jestli už proces nedoběhl a API má pro vás data. No a abyste APInu nezahltily tunou nic neřešících requestů a nedostali se tak třeba na nějaký black list, je dobré mezi odesláním každého requestu nějakou dobu počkat a opakovaně se ptát až po nějakém rozumném časovém intervalu.

Třeba takto

Srdcem tohoto jednoduchého konceptu je jen využití Promise a díky syntax sugaru async/await, to pak celé vypadá takto imperativně, pochopitelně, pro každého péhápkáře 😀

Kód je tak dlouhý, protože v něm demonstruju krom samotnéo sleep() i vše kolem…

NodeJS: Threads, práce s vlákny

NodeJS je báječný, a to hlavně díky svému Async I/O. Dalším silným znakem je to, že NodeJS je Single Threaded Event Loop Architecture. Jednoduché, čitelné a výkoné paradigma pro webové aplikace stavějící na Request/Response modelu.

Na základě tětchto principů se NodeJS moc nehodi na takové věci, jako je Machine Learning, nebo Artificial Intelligence, jinými slovy, úlohy závislé na silné paralelizaci. Byť vzhledem k tom, že je samotný javascriptový engine napsaný v C++ a nabízí tak dost vysoký výkon.

Tedy až do teď! 🙂

Od verze 10.5.0 umí NodeJS pracovat s vlákny! Což z něj dělá prostředí vhodné i pro věci kolem strojového učení a umělé inteligence. Funkcionalitu vláken přináší modul worker_threads.

Modul je dostupný od verze 10.5.0 a jen v při spuštění s paramatrem
--experimental-worker, protože se zatím jedná o novinku.

Příklad spuštění javascriptového kódu v několika, v tomto případě ve 2 vláknech.

Z příkladu je jasné, že v procesu potomka můžete spouštět jakýkoliv javascriptový kód, sdílet s rodičovským procesem proměnné (paměť) a také posílat si navzájem zprávy. Vše, co byste po vícevláknových aplikací požadovali.

Dokumentace modulu worker_threads.

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.

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…

PHP v 2018

OK, taky jsem kdysi psal v PHP, jako snad každý, kdo dělal něco na Internetu… Nicméně k mému dobru, nikdy jsem neměl ambice psát nad PHP vlastní templejtovací systém (templejty v templejtách…), nebo ještě dál, celý framework… 🙂

Narazil jsem dnes na tohle video, kde autor PHP, Rasmus Lerdorf, popisuje aktuální stav PHP, tedy retrospektivně porovnává některé věci v PHP z minulosti s tím co je v PHP 7…

Jednou z věcí, kterou řekne někde skoro na začátku videa je, že PHP podle něj mělo být uplně něco jiného, než se z PHP dnes stalo…. Co k tomu dodat….

Myslím si, že Rasmus musí být strašně nasranej, když dnes vidí NodeJS, Rust, Go, WebAssembly a všechno kolem a on už kdysi tam někam mířil…

JavaScript: callback, promises, async/await, naposledy…

Mám pocit, že čím dál víc javascriptových vývojářů používá nové jazykové kostrukce pro práci s asynchronním kódem, ale ne všichni mu rozumí jak by měli a jen slepě používají něco co viděli někde jinde. Proto naposledy tohle velice stručné, ale podle mě snad všeříkající shrnutí všech možných současných variant pro psaní asynchronních operací:

Dodám, že v TypeScriptu se píše asynchronní kód úplně stejně.

NVM, NPM problém

Pro běh NodeJS runtime používám NVM, který mi dovoluje do produkce dostat novější verzi NodeJS, než je v oficiálních balíčcích použité linuxové distribuce. A je v podstatě jedno, jestli běžíte na Centosu, Fedoře nebo Debianu, protože situace je v tomto ohledu všude stejná…

Vedle toho jsem v současné době začal vytvářet a distribuovat privátní NPM balíčky s funkcionalitami, které chci opakované používat ve více projektech. NPM je super. Vyvíjím v TypeScriptu, builduji balíček do čistého JavaScriptu, přidávám definice types (respektive se při vhodné konfiguraci generují sami), aby ostatní konzumenti mého balíčku věděli jak je použít.

Konfigurace produkce

Ale v podstatě i jakéhokoliv develop stroje, kde chcete mít přístup k privátním NPM balíčkům. Aby vám vše fungovalo jak má, je potřeba jen jemně dokonfigurovat prostředí. Úprava spočívá v úpravě .bashrc a .npmrc. Nic složitého:

1. Konfiguracve NVM

Někde na konci vašeho .bashrc přidejte pro NVM následující

Tím máte NVM funkční a můžete skrze něj instalovat požadované NodeJS runtimy:

A NodeJS vám běží v poslední dostupné stabilní verzí:

2. Konfigurace NPM
Vytvořte ~/.mpmrc a do něj vložte

A do svého .bashrc přidejte následující řádek:

Hotovo 🙂

No a tady přišel problém.

Pokud zmodifikujete své, nebo produkční prostředí, tak jak jsem popsal, přestane vám NodeJS fungovat 🙂
Problém je v nevinně vypadajícím export env proměnné NPM_TOKEN na konci vašeho .basrc. Pokud jej odeberete, nebo zakomentujete, bude vám NVM opět fungovat a tím pádem j node poběží…

Řešení

Stačí přemístit v .bashrc příkaz exportující NPM_TOKEN před příkazy exportující proměnné pro NVM…
Výsledná konfigurace v .bashrc by měla vypadat takto:

Funguje 🙂

Go Lang: intro book

An Introduction to Programming in Go

NodeJS CLI: Lighthouse

Lighthouse je open source nástroj od Googlu, sloužící k měření kvality www stránek (performance, accessibility, progressive web apps a další…). Jeho tvůrci jej popisují jako automatizovaný nástroj pro zlepšování kvality webových stránek.

Standatně můžete Lighthouse použít buď jako rošíření do prohlížeče, nebo přímo v Chrome DevTools.

Oboje funguje, nicméně ani jeden ze způsobů použití tohoto nástroje není vhodné pro automatizované měření kvality, jak jej vývojáři z Goolgu proklamují.

Další nevýhodou nástroje integrovaného do prohlížeče je, že naměřené výsledky může zkreslovat aktuální stav Chrome v momentě, kdy měření provádíte. Komunikace v ostatních záložkách, využití CPU a RAM…

NPM: skuteně automatizovaný Lighthouse

No a pak přichází v potaz skutečně plně automatizovatelné měřění pomocí NPM balíčku Lighthouse

Instalace

Spuštění

Výsledek

Výsledkem je HTML stránka, která obsahuje všechny naměřené informace. Dalším plusem pro automatizované zpracování může být, krom samotného spouštění přímo z příkazové řádky i možnost výstupu naměřených hodnot do JSONU, pro jejich další zpracování.

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

© 2018 pepa.holla.cz

Theme by Anders NorénUp ↑