A Node fantasztikus platform a háttérképek írásához. Kivéve, ha nem rendezi jól a dolgokat.


Attól függően, hogy a kerítés melyik oldalán tartózkodsz, a csomópont vagy a legjobb, vagy a legrosszabb dolog, ami történik a webfejlesztő világban. De a vélemények ellenére semmi sem vitatja a Node népszerűségét. Népszerűségével gyorsabban emelkedett, mint bárki várt volna, még az alkotója is (ezt egyébként pesszimista módon mondta interjú)!

Az írástól kezdve ez az alapértelmezett platform az új alkalmazások elindításához, amelyet elismerek gyakran az állomány mentalitásának eredménye, de a nettó hatás az, hogy a Node-ban több munkahely, több pénz és izgalmasabb projekt van, mint más hagyományos szkriptnyelvekben..

Sajnos arra a pontra jutott, hogy amikor valaki megkérdezik tőlem, hogy javasoljak nekik kezdőcsomagot a webfejlesztéshez vagy új indítási termékekhez, a Node az első számú ajánlásaim, noha jól ismerek a PHP-t és a Laravel-t.

Ha megengedhetjük, hogy egy kicsit tovább folytatjuk a megszólaltatást (amiben én leszek, mivel én írom?), A csomópont-gyűlöletnek van egy pontja, amikor azt mondják, hogy kedvenc webes verem ugyanolyan jól tud dolgozni, mint a Node, de az ellenkezője is igaz. És akkor vannak olyan aszinkron programozási és események, amelyeket az első naptól kezdve sütöttek a csomópontba, és más ökoszisztémák most kétségbeesetten próbálják lemásolni.

Ma aszinkronizálási lehetőségek vannak a PHP-ben és a Python-ban, de sajnos a meglévő, népszerű könyvtárak magja tisztán szinkron, tehát szinte olyan, mintha a rendszer ellen harcolnál. De egyébként elég egy napra. ��

Tehát, ha csomópont-fejlesztő (kezdő vagy ismerős), akkor valószínű, hogy egyik ilyen hibát elkövet, amely negatívan érinti az alkalmazását. Lehetséges, hogy nem ismeri a csomópontban végzett dolgok jobb megismerésének bizonyos módját, vagy talán egyszerűen csak a szokásokból származik, amelyeket átvettek valamilyen más ökoszisztémából.

Nem tartjuk tiszteletben az esemény hurkot

Amikor egy személy migrál a csomópontba, részben azért, mert hallottak történeteket arról, hogy a LinkedIn miközben skálázza a csomópontot, vagy láttak olyan referenciaértékeket, amelyek megmutatják, hogy a csomópont PHP, Ruby stb. Körökben fut, amikor másodpercenként kérések kiszolgálására vagy kezelésére vonatkozik. nyitott csatlakozóaljzatok.

Tehát elkészítik alkalmazásukat, és ugyanolyan robbanásveszélyes reakcióidőre számítanak, amelyről álmodtak – azzal a különbséggel, hogy semmi közeli sem történik meg.

Ennek egyik legfontosabb oka az eseményhurok megfelelő megértése. Fontolja meg a következő kódot, amely egy könyvkészletet kap az adatbázisból, majd rendezi őket az összes oldalszám szerint:

db.Library.get (libraryId, function (hibás, könyvtár) {
hagyjuk könyvek = könyvtár.könyvek;
Books.sort ((a, b függvény) {
vissza a.oldalak < b.lapok? -1: 1
});
});

Egyetértek azzal, hogy ez a kód semmit sem csinál a rendezett könyvek tömbjével, de itt nem erről van szó. A lényeg az, hogy egy ilyen ártatlan kinézetű kód elegendő ahhoz, hogy felrobbantja az esemény hurkot, mihelyt elkezdi foglalkozni nem triviális számú könyvet..

Ennek oka az, hogy az esemény hurok a nem blokkoló I / O végrehajtására szolgál. Jó példa erre a pizzacsomagoló a pizzacsatlakozásnál – az a személy, aki a pizzát vágja, a fedőlapokat dobozokba hajtogatja, a pizzát behelyezi, a megfelelő címkéket felhelyezi, és a kézbesítőnek nyomja..

Csodálatos, igaz? Csakúgy, mint Node!

Forrás: stackoverflow.com

De fontolja meg, mi történik, ha ennek a személynek is össze kell kevernie, elkészítenie és becsomagolnia az ízesítőket. Attól függően, hogy milyen bonyolult a folyamat, a pizza csomagolási arányát egyharmadra csökkentik, vagy akár teljesen le is állnak.

Ezt értjük „blokkoló” feladatok alatt – mindaddig, amíg a csomópontnak egyszerűen információt kell átadnia, ez nagyon gyors és ideális esetben a legjobb megoldás, de amint szükségessé válik néhány átfogó számítás, megáll, és minden mást kell várnod. Ez azért történik, mert az esemény hurok egyszálú (további részletek itt.)

Tehát ne végezzen számításokat az eseménykörön belül, függetlenül attól, hogy mennyire fontosak. Úgy értem, a számok hozzáadása és az átlagok kiszámítása rendben van, de a nagy adatkészletek megkönnyítik a csomópont alkalmazás feltérképezését.

Remélve, hogy az async kód együttműködni fog

Tekintsük ezt a nagyon egyszerű csomópont-példát, amely leolvassa az adatokat egy fájlból és megjeleníti azokat:

const fs = igényelni (‘fs’);

Hagyjuk tartalom = fs.readFile (‘secret.txt’, (hibás, adatok) => {
adatok visszaadása;
});

console.log (‘A fájl tartalma:’);
console.log (tartalom);

A klasszikus nyelveknek (pl. PHP, Python, Perl, Ruby, C ++ stb.) Való kitettség esetén a józan ész lesz, hogy a kód futtatása után a változó tartalma megkapja a fájl tartalmát. De itt van, mi történik, ha ténylegesen végrehajtja a kódot:

Meghatározhatatlanná válunk (). Ennek oka az, hogy amíg Ön nagyon mélyen törődik a csomóponttal, aszinkron jellege nem törődik veled (viccnek szól! Kérjük, ne itt spam gyűlöletbeli megjegyzéseket ��). Feladatunk az, hogy megértsük az aszinkron jellegét és vele dolgozzunk. A readFile () egy aszinkron függvény, ami azt jelenti, hogy amint meghívják, a csomópont eseményhurok továbbítja a munkát a fájlrendszer-összetevőre, és továbblép.

Később visszatér a funkcióhoz, amikor a fájlt elolvasta, de addigra a tartalmat egy inicializálatlan változóként kezelik, és így meghatározatlanul tartalmaznak. A helyes módszer a fájl adatok feldolgozása a visszahívási funkción belül, de nem tudok részletesebben belemenni, mivel ez nem egy Csomópont bemutatója. ��

Visszahívás, amely felhívja a visszahívást, amely felhívja a visszahívást, amely felhívja . . .

A JavaScript közelebb áll a funkcionális programozáshoz, mint bármely más régebbi, mainstream nyelv (valójában mindazok szólnak és készek, ez a kedvencem az objektum-orientált tervezéshez és a funkcionális képességekhez – a Python, a PHP, a Perl, a Java és még a Ruby, amikor a „élvezetes” kódot kell írni).

Vagyis a funkciók több állampolgári jogot kapnak, mint más nyelveken. Ezt összekapcsolva azzal a ténnyel, hogy az aszinkron kód úgy működik, hogy visszahívási funkciót nyújt Önnek, és végül egy katasztrófareceptet hívunk, amely Callback Hell néven ismert..

Íme néhány példa az elektronkódra, amellyel a Quora-n találkoztam. Mit gondolsz, mit csinál??

var opciók;

igényelnek (elektron). app.once (
‘kész’,

function () {

opciók = {
keret: hamis,
magasság: 768,
szélesség: 1024,
x: 0,
y: 0
};

options.BrowserWindow = szükséges (‘elektron’).
options.browserWindow = új opciók.BrowserWindow (opciók);
options.browserWindow.loadURL ( ‘http://electron.atom.io’);
options.browserWindow.webContents.once (
‘Tette-stop-loading’,

function () {
options.browserWindow.capturePage (
opciók,

funkció (adatok) {
igényelnek ( ‘FS’). writeFileSync (
‘/Tmp/screenCapture.testExampleJs.browser..png’,
data.toPng ()
);

process.exit (0);
}
);
}
);
}
);

Ha nehézségei vannak, lépjen be a klubba!

A funkciókon belüli funkciókat nehéz olvasni és nagyon nehéz megérteni, ezért hívják úgy, mint „visszahívási pokol” (azt hiszem, hogy a pokol zavaró hely, ahol kijuthatunk!). Miközben ez műszakilag működik, a kódot jövőképessé teszi minden megértési és karbantartási kísérlet után.

Sokféle módon elkerülhető a visszahívás pokol, ideértve a következőket ígéretek és Reaktív kiterjesztések.

Az összes CPU-magot nem használja

A modern processzoroknak több magja van – 2, 4, 8, 16, 32. . . a szám folyamatosan mászik.

De erre nem gondolt a csomópont alkotója, amikor kiadta a csomópontot. Ennek eredményeként a csomópont egyszálú, ami azt jelenti, hogy egyetlen szálon belül fut (vagy egy folyamaton ha fut, ha azt akarod hívni, hogy bár nem azonosak), egyetlen CPU-magot használva.

Ez azt jelenti, hogy ha megtanulta a csomópontot oktatóanyagoktól és barátaitól, és körülötte lebegő kódrészleteket, és ha alkalmazásod egy 8-magos szerverre lett telepítve, akkor a rendelkezésre álló feldolgozási teljesítmény 7/8-át pazarolja.!

Mondanom sem kell, hogy ez egy hatalmas pazarlás. Ha ezen az úton haladsz, akkor nyolc szerverért fizetnek, amikor csak egyre van szüksége. Vagyis költessen havonta 16 000 dollárt, amikor 2000 dollár megteszi (a pénzvesztés mindig fáj, igaz?). Mindez, amikor a megoldás elég egyszerű: a fürt modul.

Nem tudok itt belemenni az összes részletbe, de ez egy egyszerű módszer annak megállapítására, hogy hány mag van a jelenlegi gépben, majd elindítom ezt a sok csomópont példányt. Ha hibákat észlel, a példányt újraindítják. Az alábbiakban bemutatjuk, milyen egyszerű a megvalósítása (bemutató itt):

var cluster = igényelni (‘klaszter’);

if (cluster.isMaster) {
var numWorkers = igényelnek (‘os’). cpus () hossz;

console.log (‘Mester klaszter beállítása’ + numWorkers + ‘dolgozók …’);

for (var i = 0; i < numWorkers; i ++) {
cluster.fork ();
}

cluster.on (‘online’, funkció (munkavállaló) {
console.log (‘Munkavállaló’ + munkás.process.pid + ‘online’);
});

cluster.on (‘exit’, funkció (munkás, kód, jel) {
console.log (‘Munkavállaló’ + munkás.process.pid + ‘kóddal:’ + kód + ‘, és jel:’ + jel) meghalt;
console.log (‘Új munkavállaló indítása’);
cluster.fork ();
});
} más {
var app = igényelni (‘kifejezni’) ();
app.all (‘/ *’, function (req, res) {res.send (‘process’ + process.pid + ‘hello hello!’). end ();})

var server = app.listen (8000, function () {
console.log (a ‘Process’ + process.pid + ‘meghallgatja az összes bejövő kérést’);
});
}

Mint láthatja, a cluster.fork () végrehajtja a varázslatot, a többit pedig egyszerűen csak néhány alapvető klaszteresemény meghallgatása és a szükséges tisztítás elvégzése jelenti..

A TypeScript nem használható

Oké, mint ilyen, ez nem hiba, és rengeteg csomópont-alkalmazást írtak és írunk TypeScript nélkül.

Ugyanakkor a TypeScript garantálja és garantálja a nyugalmat, amelyre mindig szükség volt a Node-nak, és véleményem szerint ez egy hiba, ha 2019-ben a Node-hez fejleszti és nem használja a Typecriptet (különösen, ha a MEAN veremben az A (szög)) mozog. a TypeScriptet régen).

Az átmenet enyhe, és a TypeScript szinte pontosan olyan, mint az ismert JavaScript, az ES6 típusgaranciával és néhány más ellenőrzéssel:

// /lib/controllers/crmController.ts
import * mangánként „mangózból”;
a {ContactSchema} importálása a ‘../models/crmModel’-ből;
{Request, Response} importálása az ‘express’-ből;

const Contact = mongoose.model (‘Kapcsolat’, ContactSchema);
export osztály ContactController {

public addNewContact (req: Request, res: Response) {
let newContact = új kapcsolattartó (req.body);

newContact.save ((hibás, kapcsolattartó) => {
ha (err) {
res.send (err);
}
res.json (érintkező);
});
}

Azt javaslom, ellenőrizze ezt a kedves és barátságos képet TypeScript bemutató.

Következtetés

A csomópont lenyűgöző, de nem nélkülözheti (sok?) Problémáját. Igaz, hogy ez vonatkozik minden, a régi és a régi technológiára, és jobban megértjük a csomópontot, és vele dolgozunk..

Remélem, hogy ez az öt tipp megakadályozza, hogy belekerüljön az évelő hibák és a teljesítményproblémák kátrányába. Ha hiányozott valami érdekes, kérlek, tudassa velem, és örömömre szolgál (valójában hálás!), Ha felveszem őket a cikkbe. ��

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me