NODE.JS csak szeresd, szeresd....

Indította eztcsekk, 2017 január 14, 01:17:00 DÉLUTÁN

Előző téma - Következő téma

eztcsekk

Évek óta nem volt semmi topic amiben tényleg szó van valami programozásról akkor most legyen valami ilyen is.

Bemutatom a Node.JS-t, vagyis majd ti utána olvastok, de azért dobok pár fontos infót róla, hogy sporoljak egy kis időt:

Hivatalos oldal/letöltés:
- https://nodejs.org/en/

Tutorialok kezdőknek(Angolul):
- Youtube: https://www.youtube.com/watch...
- Olvasgatós: http://www.tutorialspoint.com/nodejs/

Multiplatform application fejlesztéshez:
- http://electron.atom.io/

Mire jó a Node.JS:
- Alapvetően BackEnd rendszereket írni a PHP-nél jó 15 évvel fejletebb eszköz a C#-nál pedig multiplatformabb, illetve akinek van gyakorlata JS-ben elég hamar feltalálja magát.

Single Thread, de nem 1 szállas!!:
- Gyakori tévhit, hogy a Node.JS egy szállat kiteker és semmit nem tudd kezdeni a 32 Magos Xeon processzoroddal, ez nem igaz. Ami igaz, hogy a müveletek 1 szállon egymástól függetlenül futnak le, tehát egyszere nincs ThreadSafe és nincs Parallel futatás sem. Azaz ha 2 függvényt egymás után szerentnénk, hogy lefusson és szeretnénk, az egyikben a másik visszatérési értékét használni akkor bizony Callback-et kell használnunk, sőt leginkább minden esetben Callback-et kell használnunk jöhet is a következő "fogalom".

Callback Hell:
- Ha túlvagytok az alapokon, akkor hamar találkozni fogtok vele, hogy az Event Handled I/O egyik legszembetünöbb következménye, hogy pl. Function amiben van egy I/O müvelet (monduk egy SQL query) ha csak úgy simán utána írunk egy másik müveletett ha csak nem a memóriához nyulunk szinte biztosan nem fogja megkapni az I/O müvelet eredményét.

MongoDB ne sz*pd be(saját vélemény):
- Általános HYPE, hogy a MEAN(http://mean.io/) Stack a Node.JS tökéletes megformálodása. Nos több Backend project után el tudom mondani, hogy a MongoDB-nek még nem jött el az ideje a ebben a MySQL/MSSQL uralta világban.


Elírás jogát fentartom.

hunti

Milyen problémákba futottál ami miatt nem ajánlod mongodb-t? Illetve milyen tapasztalataid vannak vele?

eztcsekk

Ha nem használnék évek óta MySQl-t lehet más véleményem lenne, de nekem több fejfájást okozott mint amit valaha vissza hozzna teljesítményben vagy fejlesztési időben vagy akárhogy. (Igazából nem gondolom, hogy gyorsabb lenne a fejleszés sőt mióta a MySQL is támogatja a JSON adattípust, tényleg csak ott tudom elképzelni ahol 1millió + Inserted van és mellé minimális lekérdezésed).

Shyro

Hali!

Orulok, hogy valaki vegre bedobott egy temat. Ritkan szoktam mar visszatevedni az oldalra, viszont olvasva a post cimet kedvet kaptam hozzaszolni.

Elso korben MongoDB. Azzal csak egyetertek, hogy a hype - nak nem szabad bedolni. A legfontosabb tenyezo ebben a kerdesben az adott projekt vagy megoldando feladat. Ugyanis az fogja meghatarozni - meg akkor is ha ez a projekt elorehaladtaval valtozik - hogy milyen igenyeknek kell megfelelned adatok modellezese es azok tarolasa teren. Van hogy boven eleg a csak a fajlrendszert hasznalnod, de tobbfele adatbazis modell is letezik es egyatalan nem biztos hogy egy adott feladat kapcsan neked az adataidat relacios adatbazis modell szerint kell manipulalnod. Abban az esetben, ahol ugy gondolom boven eleg egy dokumentum-alapu adattarolas, nincsenek kapcsolatok a kulonbozo tipusu tarolt dokumentumok kozott, boven jo szolgalatot tehet egy MongoDB.
Ha azok a feature - k, amikkel rendelkezik (indexeles, replika, skalazhatosag) elegendoek, akkor nehezen tudom elkepzelni, hogy jo kezekben barmilyen hatrany is szarmazna abbol, hogy valaki MongoDB - t hasznal. Tovabba NodeJS backend eseten - JavaScript miatt - szimpatikus lehet a shellje es a NodeJS drivere, az ember ugy erzi, hogy ismeros terepen jar.

Kicsit a NodeJS - rol is. Ha valakit kiraz a hideg mar a nev hallatan is, akkor azon nem hiszem, hogy lehet segiteni. Meg nem talalkoztam olyan esettel, ami ilyen reakciot indokolta tenne barkinel. Erre is ugyanaz igaz, mint barmi masra, erteni kell hozza es tudni pontosan, hogy azt hogyan tudod jol kihasznalni. Azok az esetek, amikor barmi negativ tapasztalat volt, mindig visszavezetheto volt valami fejlesztoi "hibara". Nem volt skalazhato (horizontalisan) az alkalmazas, rossz architektura, vagy akar a karbantarthatatlan kod, amelyek kozul bizony egyik sem a NodeJS hibaja.

A NodeJS az alkalmazasodat 1 szalon futtatja (nincs is lehetoseged szalkezelesre) es bizonyos utasitasokat (pl. I/O, networking) amelyek alapbol lassu, blokkolo utasitasok lennenek, asszinkron, nem-blokkolo modon futtatja (persze van lehetoseg szinkron modon is fajlba irni, stb.). Igy ered el, hogy a kod amit irsz konkurrensen fog futni, nem parhuzamosan. Ha szeretned kihasznalni a vasat jobban, akkor arra ott van a cluster API - ja. Ami meg lenyeges, hogy legtobb esetben az operacios rendszer async API - jaira epit, viszont I/O eseten korrekt async API - ami tobb platformon is mukodik es nincs vele annyi szopas - sajnos nincs. Ezt a NodeJS egy thread pool - al orvosolja. bovebben

A callback hell szerencsere ma mar elkerulheto es konnyen kezelheto. Nightly verzional ott az async/await (bovebben), de Promise - ok es generatorok reven (kis csavarral), de konnyen elkerulheto, hogy callback - eket kelljen irni. Persze az alap NodeJS API az callback - ekkel megy, de ezeket is konnyu "wrappelni" egy Promise - al, onnantol kezdve pedig mar ott a lehetoseg, hogy asszinkron kodot irj, ami kinezetre megis szinkron kodnak tunik.

Udv,
Shyro
makeSystem :: Integral a => [a] -> [a]
makeSystem l = concat (zipWith (\ a b -> replicate (fromIntegral a) (fromIntegral b)) l [ product x | x <- inits l ])
makeSystem [ 60, 60, 24, 7, 52 ] = ?

AximCore

#4
Nekem csak egy kérdésem lenne azok felé akik komolyabban is használják a NodeJs-t, hogy mi az a terület/projektek/applikációk amikor jobb alternatíva X-Y-Z tulajdonsága miatt mint mondjuk egy PHP, Spring, WildFly Swarm vagy akármi ?

Eddig nem találkoztam olyan nagyobb/kisebb projekttel ahol NodeJS feljött volna alternatíva ként, ezért érdeklődöm.

MongoDB meg felesleg ha úgy is üzemeltet az ember valami normálisabb relációs adatbázist, ahol meg azok kevesek ott már mi saját binárisokat használunk.
"Tanítani lehet az ostobát, de gondolkodásra bírni nem."
A Talmud

Windows Firewall
http://devopsreactions.tumblr.com/

Why use Windows, if you have open doors... to Linux

Shyro

Ez egy nehez kerdes, egyszeruen a szemleletbeli kulonbsegek miatt. Ha valami olyasmire gondolsz, hogy van e az a projekt, vagy feladat amit csak es kizarolag NodeJS - re epitve erdemes megvalositani, arra az en valaszom az, hogy nincs. De szerintem barmi mas technologia / nyelv eseten ugyanez elmondhato, legyen az Scala, Ruby, PHP, Haskell vagy Java, teljesen mindegy. En nem tudok olyan feladatot, aminek a megvalositasara csak es kizarolag a Spring framework lenne alkalmas. Vannak mas nyelvek, hozzajuk mas keretrendszerek, amivel ugyanugy meg tudod valositani az adott alkalmazast.
Persze lehet extrem felteteleket szabni, amire biztosan nem hasznalna senki a NodeJS - t, de ertelmetlen, mivel senki nem is hasznalna ilyen esetekben. Nekem errol mindig az a hasonlat jut eszembe, hogy az esetek 95% - ban boven eleg egy kalapacs a haztartasban, de ha arra kerul a sor, hogy egy falat kell kibontani, nem fogok nekiallni azzal erolkodni, nem hulye az ember.
A NodeJS nem egy szent gral, egyszeruen egy alternativa a technologiak sokasaga kozott es ugy gondolom jogosan. Ettol fuggetlenul, ahol en lattam NodeJS alapu backend alkalmazast, oda en ugyanugy el tudtam volna kepzelni az eddig felsoroltak kozul barmit es ugyanugy helyt alltak volna.

Azt tudom elkepzelni, hogy az embereket megteveszti az, hogy egy "szalon fut az alkalmazasod". Ez meg nem azt jelenti, hogy le vagy limitalva erre. De peldaul egy API - t megvalosito NodeJS alkalmazasnal nem az tortenik, hogy elinditod a process - t aztan bir amennyit bir. Stateless - re tervezed meg az alkalmazasodat (token alapu autentikaciot hasznalsz, stb.), load balance - olod a request - eket, es mogotte horizontalisan ugy skalazod az alkalmazasodat, ahogy akarod, akar terhelestol fuggoen. Ennek is megvannak persze a limitacioi, de eleg sokaig lehet ezzel menni es sok esetben boven elegendo, sot.

Ha jol tervezed meg a backend architekturadat, ennel tovabb is lehet menni. Ha sok CPU idot igenylo feladat van, ami mar terhelne a web instance - okat, egyszeruen bevezetsz egy message queue - t, amibe innentol kezdve a web instance - ok mar csak pakolnak, leveve roluk a feldolgozas terhet, es egyszeruen worker jobokkal szepen dolgozod fel a queue - t, amiket aztan szinten skalazhatsz. Mind a queue - t, mind a jobokat, stb.

Persze meg mindig hangsulyozom, nem ez az "A megoldas" mindenre, es nem is a NodeJS, csak szerettem volna szemleltetni, hogy ezt lehet okosan is csinalni. Ezzel pedig alkalmazasok, service - k eleg szeles skalajat le is fedtuk, ahol a NodeJS egy jo alternativa a tobbi technologia mellett. Es meg mindig ott a kod, amin legtobb esetben elso izben kell huzni, amire jo pelda ez a blog bejegyzes.

Ha peldakat es tapasztalatokat szeretne az ember a NodeJS - rol, akkor van jo par ceg, akik eleg erosen hasznaljak a NodeJS - t, persze mas technologiakkal egyutt. (Miert ne?) Az ilyen cegek beszamoloit erdemes meghallgatni / elolvasni. Persze nem a harmadkezbol, hatalmas hype - kent eloadott, a "NodeJS a jovo" cimu cikkeket kell keresni, hanem olyan fejlesztok velemenyet, akik a NodeJS mellett azert lattak egy s mast.

A MongoDB - t szinten nem ertem. De azt is hosszu lenne leirnom, inkabb kesobbre hagyom.

Udv,
Shyro
makeSystem :: Integral a => [a] -> [a]
makeSystem l = concat (zipWith (\ a b -> replicate (fromIntegral a) (fromIntegral b)) l [ product x | x <- inits l ])
makeSystem [ 60, 60, 24, 7, 52 ] = ?

eztcsekk

Nyilván ez is csak egy technológia, ASM-ben is meg lehet írni mindent.  Viszont az általad felsorolt nyelvek Scala, Ruby, PHP, Haskell vagy Java (kivétel a Java,PHP) nem éppen növekvő népszerüséget mutatnak a JS-el szemben.

Nem vitatom a MongoDB létjogosultságát, csak felhívom a figyelmet, hogy a Node-nak a MongoDB nem olyan mint a PHP-nak a MySQL.

AximCore

Mármint lehet rosszul írtam de én főként arra lennék kíváncsi, hogy pl egy sima oldalnak amin max pár ezer ember használja és nincs mögötte különösebb szolgáltatás akkor nem állok neki Spring-be fejleszteni mert egyszerűen PHP erre célszerűbb. De ha egy komplexebb szolgáltatáskörrel bíró honlapot kell megírni amit nagyságrendekkel többen használnak azt már inkább Springbe érdemes. Míg mondjuk ahol kell egy teljesítmény kritikus szolgáltatás oda már Spring helyet inkább egy C++.  Persze PHP-t is átlehet forgatni C++ kódba, hogy gyorsabb legyen mint pl FB.

Meg mindent lehet húzogatni csak vannak erre nyelvek amik jobban támogatják így célszerű azt használni.
Feladathoz illő szerszámmal kell dolgozni szerintem. ( Fadarabbal is lehet szöget beverni )

Ui.: Kezdem azt érezni, hogy igazából annyi ez a NodeJS, hogy egy php alternatíva annak aki mindenáron JS-el akar dolgozni.
"Tanítani lehet az ostobát, de gondolkodásra bírni nem."
A Talmud

Windows Firewall
http://devopsreactions.tumblr.com/

Why use Windows, if you have open doors... to Linux

eztcsekk

A PHP-nak nem az a baja, hogy lassú a PHP 7 már kifejezetten gyors. Hanem, hogy igazi nagybetüs Script nyelv lefutt kidobja az eredményt majd kilép. (Igen van hozzá 1001 extension a muti-thread-től a socket kezelésig...)

Amikor elkezdtem használni a Node-ot az volt az elsődleges szempont, hogy valamit megkelett 100x gyorsabban csinálni mint ahogy PHP-val ment, megcsinálta kész nálam approved lett.

Néhány Node alapú Desktop alkalmazás:
- Pop-corn time!
- Spotify
- Netflix

Shyro

@AximCore Ertem, hogy mire gondolsz. Viszont en nem tudom ennyire konkretan latni a dolgokat. Itt arra gondolok, hogyha "valami komolyabb szolgaltatasra van szukseg akkor Spring, amugy meg PHP". Egyreszt ilyen szituacioban en mar nem biztos hogy monolitikus felepitesben gondolkoznek, onnantol kezdve meg mar nincs megkotve a kezed 1 technologia altal. Megirhatod a szolgaltatasod API backend - jet mondjuk Java - ban, de pl. a szolgaltatas riporting oldalahoz az adat migraciot akar vegezheti egy NodeJS service is. Ennek a szuksegessege es ertelme persze megint rengeteg dolgon mulik, ami egy teljesen kulon tema es beszelgetes is. Amit ezzel mondani akartam, hogy en abban az esetben sem latom egyetlen technologianak az elonyet, ha valami brutalisan nagy szolgaltatas lefejleszteserol van szo. Sokszor inkabb azon mulik, hogy az adott ceg melyik technologiaban bizik meg, melyikhez van meg a kello fejlesztoi tudasa, emberi eroforrasa, es akkor az fog nyerni sok kerdesben. Lehetseges, hogy performanciaban, konkurrens es parhuzamos programok irasaban a Go egy komoly szereplo mint nyelv. De egy ilyen ceg nem fog nekiallni Go - ban megvalositani egy projektet, csak azert mert arra mondjuk az a nyelv lenne a legalkalmasabb. Se Go - ban jartas fejlesztok, se tapasztalat nincs a cegnel, ugyanugy Java - ban fogjak megvalositani. Ettol meg a Go az elobb emlitett elonyeit megtartja, es nem fog az kovetkezni a dologbol, hogy a Java mindenre jo.

Es ugyanez igaz egy fejleszto esetere is. Ez talan a valasz igazan a kerdesedre. Ha egy jo szoftverfejleszto ismeri a Java - t kovulrol belulrol es az ahhoz tartozo technologiai stack - eket, plussz meg van nehany nyelv es technologia a zsebeben, teljesen jogos a kerdes, hogy miert hasznaljon meg plusszba NodeJS - t is? A valasz erre az, hogy nem szukseges. Boldog es profi fejleszto lehet anelkul is hogy valaha hasznalna NodeJS - t. Viszont van egy masik oldala is ennek. Egy masik profi szoftverfejleszto aki JavaScript - ben programozik es igy NodeJS - t hasznal backend oldalon (biztos sokan rancoljak a szemuket ;) ), mellette meg mondjuk ott a kezeben egy Haskell meg egy Ruby, akkor neki is joggal merul fel a kerdes, hogy ugyan, miert hasznaljon Java - t? Hiszen a feladataik 99% - t meg fogjak tudni oldani az aktualis tudasukkal es eszkozeikkel. Es itt is az a valasz, hogy nem kell. Ilyenkor alakul ki vallasi vita, aminek nincs ertelme, hogy a NodeJS szar, folosleges hype, vagy akar a Java es az elburjanzott vilaga folosleges es szar. Egyik sem korrekt.

En ugy allok ehhez a kerdeshez, hogyha az utobbi szemely lennek, akkor is erdekelne a Java/Spring, mert fejleszto vagyok, folyamatosan fejlodni akarok, es biztos sokat lehet tanulni belole. Ugyanez a hozzaallas szerintem a NodeJS fele is korrekt, ha valaki nem ismeri, csak latja a felhajtast korulotte, foloslegesnek erzi vagy csak nem talalja a letjogosultsagat, szerintem akkor is erdemes ranezni, biztos vagyok benne, hogy ha kello alapossaggal teszi akkor nyertesen, ujabb ismeretekkel a zsebeben fogja vegezni.
makeSystem :: Integral a => [a] -> [a]
makeSystem l = concat (zipWith (\ a b -> replicate (fromIntegral a) (fromIntegral b)) l [ product x | x <- inits l ])
makeSystem [ 60, 60, 24, 7, 52 ] = ?

Shyro

Egyebkent szerintem erdemes megnezni ezt a videot, azt hiszem az elso eloadas a NodeJS atyjatol, ahol elmondja, hogy miert is letezik a NodeJS:
https://www.youtube.com/watch?v=ztspvPYybIY
makeSystem :: Integral a => [a] -> [a]
makeSystem l = concat (zipWith (\ a b -> replicate (fromIntegral a) (fromIntegral b)) l [ product x | x <- inits l ])
makeSystem [ 60, 60, 24, 7, 52 ] = ?

eztcsekk

Kicsit régi videó, 2015 óta senki nem kérdöjelezi meg a Node JS jogosultságát.

Off:
- Ez egy Node JS bemutató topic lett volna, ahol mondjuk az ajánlott IDE-kről a NPM-ről meg olyan tippek-trükkökről osztanánk meg infót, hogy akkor most EJS,Jade vagy Mustache template enginet használjunk...
Erre egy WTF is NODE használj Springet topic lett.  :'(

Shyro

@eztcsekk Regi video, viszont ha valakit erdekel a NodeJS eredete es szeretne latni azt, hogy mikent jutottunk el napjainkig, akkor egy alapmu. Amik elhangzanak benne, azok szerintem mai napig igazak es fontos szempontok.

Meg nem keso, viszont en fontosnak ereztem az eddig elhangzottakrol is beszelni. A topic nem annyira sziguro, legalabbis a cim alapjan, hogy amikrol beszeltunk az OFF kategoria lenne.

Mindent nem hiszem, hogy ossze tudok szedni igy elsore, de nehany gondolat, hogy mit es hogyan hasznalok NodeJS eseten.

Szerver oldalon:

  • szerver oldalon nincs kod forditas, inkabb folyamatosan a legujabb Node verziora valo atallast probalom elosegiteni, ez egyreszt azert is lehetseges, mert a tesztek vedenek (persze csak annyira jol amennyire meg is vannak irva), masreszt "future proof" megoldasokban kell gondolkodni, amennyire csak lehet

    • NodeJS - ben egyenlore meg CommonJS modul formatum van, viszont ES2015 - re konnyen migralhatoan erdemes irni:
      const { resolve } = require('path'); // CommonJS
      import { resolve } from 'path'; // ES2015
    • Asszinkron kodokat nem callback - el es Promise - okkal (kliens oldalon kicsit mas a helyzet) vannak megoldva, hanem "szinkron stilusban" irok asszinkron kodot, ez jelenleg generator fuggvenyekkel es Promise - okkal mukodik, illetve egy co nevu library segitsegevel, igy ha bekerul az async/await a stable Node verzioba, mind a tesztek, mind az implementazio konnyen atmigralhato lesz ra:

      co(function* () {
        yield db.query();
      });

      async function () {
        await db.query();
      }
  • NPM - et hasznalok, mint package manager, illetve sok egyeb feladatra, nagyon jol kiegeszitheto mas tool - okkal. Task futtatasra szoktak a grunt - ot es a gulp - t hasznalni meg. Hasznaltam oket egy ideig, viszont ma mar ezeket foloslegesnek erzem, NPM nekem boven eleg funkcionalitast adott task - ok futtatasahoz. Emlegetik meg a Yarn - t, hogy az sokkal gyorsabb, mint package manager. Nem probaltam, de elhiszem. Ennek ellenere en maradok az NPM - nel
  • Meg hasznalok NVM - et, tobb projekt eseten szerintem elengedhetetlen az eltero verziok miatt
  • Meg nehany dolog, ami most eppen eszembe jutott:

Kliens oldalon:

  • Ez egy picit nagyobb falat, szoval ezt majd kesobb... ;)
makeSystem :: Integral a => [a] -> [a]
makeSystem l = concat (zipWith (\ a b -> replicate (fromIntegral a) (fromIntegral b)) l [ product x | x <- inits l ])
makeSystem [ 60, 60, 24, 7, 52 ] = ?

eztcsekk

IDE?

A Netbeans egész jól támogatja a Node-ot, de a syntax highlight az valami borzalmas benne.

Ki mit használ?

Shyro

PhpStorm / WebStorm amik komolyabb IDE - k es mar hasznaltam / hasznalom oket. Viszont en nem szeretem az ilyen komplex, monstrum szoftvereket annak ellenere, hogy alairom nagyon fel tudjak gyorsitani a fejlesztest. Mivel kliens oldalon most TypeScript - et hasznalok, valahogy ezen a vonalon csorgott be a Visual Studio Code (nem Visual Studio :) ), amit mar lassan egy eve hasznalok. Lattam, hogy honnan indult es hogy mara meddig jutott. Alapvetoen egy community-driven / open-source editor. Nekem jobban bejon az a vonal ha magam "hackelgethetem" ossze az eszkozeimet, a sajat szam ize szerint, a sajat absztrakcios szintemmel. Erre viszont eleg alkalmasnak talaltam, raadasul ahogy fejlodik es egyre tobb mindent tud, azt sem tolakodo modon teszi, amit en eleg nagyra ertekelek. Konfiguralhatosaga szinten az en stilusom, egy JSON fajlt kell bovitgetni. Plugin - ekbol viszonylag keveset es csak kiforrottabbakat hasznalok, de abbol is egyre tobb van.
makeSystem :: Integral a => [a] -> [a]
makeSystem l = concat (zipWith (\ a b -> replicate (fromIntegral a) (fromIntegral b)) l [ product x | x <- inits l ])
makeSystem [ 60, 60, 24, 7, 52 ] = ?

Powered by EzPortal