Názory k článku
Začněte stavět serverové aplikace s Node.js (školení)
-
misaz (neregistrovaný)
"porušují se základní best practice" je vše co potřebujete vědět. Neporušují se jenom best practice, porušují se ZÁKLADNÍ best practice. Zlo je když se porušují jakékoliv best practice, natož pak základní.
Mám 2 projekty > 10000 řádků kódů v node.js a už při >5000 je to nechutné zlo. Oba žijí jen ze setrvačnosti, další verze jsou jeden v Pythonu a jeden v .NET core. Node JS je super na vyzkoušení něčeho malého (třeba senzoru na RPI, npm a běžná knihovna je podstatně jednoduší než se patlat s pipem a prapodivnými polofunkčními knihovnami nějakého Lojzy v Pythonu) a aplikace kde NIKDY (znamená minimálně 50 let) nehrozí že by se rozrostli na více než 500 řádků kódů. Takových projektů mám asi 12 (některé jako podpůrné aplikace řešící různé průsery Node.JS pro ty větší projekty) a zas tak moc si stěžovat nemůžu.
// příklad bokem: Node.JS ani po 10 verzích nativně neumí pracovat s XML....
-
null null (neregistrovaný)
@misaz
A)
"porušují se základní best practice" je vše co potřebujete vědětTo jako myslíš vážně? To se mám řídit tím co někdo někde vykřikne, ne tak to ještě papouškovat dál aniž bych znal důvod?
No, ok, tak v čem se teda porušují?B)
Dobře, máme tvůj OSOBNÍ názor na to co bude za 50let a dobrozdání že se to do tvých projektů nehodí. XML ... Nativní mají JSON. Jo nedokonalý, přesto stačil. Musí mít všechno nativní? -
lol2 (neregistrovaný)
příklad bokem - to je vtipne, si nevidel node.js ani z rychliku. Ked si neimportujes fs, tak node.js nevie pracovat ani so suborovym systemom... Cize co si importoval aby vedel node.js pracovat s XML. Ak nic, tak sa ani necudujem ze nevie. Mozes marne cakat dalsich 100 verzii. XML je tak okrajova vec, ze nativny support sa tomu robit nebude. Defaultne tam ma len to co zdedilo z V8. Teraz otazka - kolko pull requestov si poslal do V8 s perfektne fungujucou podporou XML?
ostatne bla bla bla ... plno prazdnych reci :) Dam ti radu - skus to v parlamente. Uspejes.
Sprasit kod vies v akomkolvek jazyku. To ze niekto napise taky kod neznamena ze jazyk je zly, ale ze ako programator stoji za kocku.
-
Petr Neni (neregistrovaný)
Mas naprostou pravdu, programator serverovych reseni v javascriptu stoji za kocku. Ano, pokud to pouziva 5 lidi tak at je to klidne v javascripte nebo znakovem pisme, pokud ale ocekavas skalovatelnost, vymenu dat, georedundanci databazovou i aplikacni, tak s node.js muzes tak snit... i proto to neumi xml, 10 let stary standard, protoze implementace v node.js by byla nad schopnosti programatoru v node.js.
-
Roman (neregistrovaný)
Muzu doporucit Go - mam s nim velky uspech a uz pisu temer vyhradne v nem. Je na serverova reseni primo staveny. Nema spoustu OOP funkci jako Java, ale jde to prekvapive i bez nich. Super jednoduchy, rychly a prehledny kod, diky Goroutines vyuzivajici vsechna dostupna CPU jadra a rychly garbage collector optimalizovany pro 21. stoleti.
-
Roman (neregistrovaný)
... a https://github.com/golang/dep pro spravu vendor balicku; reproduktivni build zajisten. :)
-
Mlocik97 (neregistrovaný)
všetci čo flamia node.js zrejme s nim ani nepracovali, a ak ano, tak ho používali špatne... to je jak kdyby ste nadávali na to že když si nalejete vodu na tácku a znej pijete že je tácka k ničomu. Node.js neni vôbec špatný, len treba vedieť na čo ho použiť, kdy ho použiť, a ako ho použiť.
-
pac (neregistrovaný)
To je jak systemd-speak:
"všetci čo flamia systemd zrejme s nim ani nepracovali, a ak ano, tak ho používali špatne... to je jak kdyby ste nadávali na to že když si nalejete vodu na tácku a znej pijete že je tácka k ničomu. Systemd neni vôbec špatný, len treba vedieť na čo ho použiť, kdy ho použiť, a ako ho použiť."
No ja si vodu naliju do sklinky misto na tacek, pac tacek je na piti vody fakt k nicemu. Tudiz ho nepotrebuju. Staci stara dobra sklinka :)
-
Yak (neregistrovaný)
Je to reprodukovatelné jako jiné package managery - hint verzovani a restrikce. Až po "je to dneska někde online". Co je u Node a obecně js ekosystemu problem je rychle zastaravani balicku a casto prekotne zpetne nekompatibilni nove verze. Pokud si tedy na kazdou blbinu nekdo natahne balik, lehce se mu stane ze pak kvuli nejake blbine nic neupdatuje aby mohl naolinstalovat dalsi blbinu ktera chce nove verze vseho. To je ale problem vyvojarsky na vsech stranach a sposty ekosystemu okolo spravcu nikoliv samotnych spravcu balicku
-
Petr Neni (neregistrovaný)
A jak reprodukujete ty online balicky v offline prostredi? Treba na 1k+ serveru? Tar na nejakou dir kterou pak rozbalis vsude? U rpm natlacim balicky kam potrebuji a nainstaluji. U node.js? Nikdo z developeru mi rozumne nedokazal vysvetlit jak reprodukovat cokoliv z node.js na produkci ktera si netaha nic z internetu.
-
Kolja (neregistrovaný)
Možná to je mezi židlí a klávesnicí. Tak mi ale prosím řekni, jak NPM přimět, aby nějaký node včetně celého stromu závislostí složil off-line z lokálních souborů. Já jsem tedy žádné funkční řešení nenašel. Jen stížnosti, že to nejde, a odpovědi vývojářů, že to je proti filozofii celého systému.
-
L. (neregistrovaný)
Co se týče reprodukovatelných buildů. tak k tomu slouží package-lock.json, který zajistí, že se použijí vždy ty samé verze knihoven včetně závislostí.
Nějaké harakiri se skládáním z lokálních souborů k tomu vůbec nepotřebuješ. Hlavně proto, že bys musel nějak zajistit, aby byly offline lokálně dostupné všechny dependence.
Pokud máš potřebu pouštět "npm install" na počítači, který nemá přístup k internetu, tak bych spíš tipoval, že používáš nějaký fatálně chybný postup typu "nakopíruju zdrojáky na produkční server a tam teprve aplikaci zkompiluju". Řešení není donutit NPM instalovat offline, ale používat profesionálnější provozní postupy - typicky sestavit na build serveru balíček aplikace a na servery instalovat ten.
Pokud bys _náhodou_ měl opravdu legitimní důvod pouštět build aplikace na offline serveru, tak nejjednodušší je prostě přenést sakumprásk adresář node_modules. A nemusíš ten npm install vůbec pouštět.
Jinak je možné dělat nějaké čachry s nastavením repository pro NPM na nějaký server v lokální síti (nebo localhost), ale to je opravdu komplikovaná cesta, kterou bych se nevydával, pokud bych absolutně nemusel.
-
Kolja (neregistrovaný)
Sestavení provádíme na vývojářských strojích, na cílovém by to ani nešlo, protože je to embedded, které na to nedostačuje (viz další odstavec).
NPM se spouštět musí, protože existují nody, které nejsou čistě v JS, ale mají část třeba v C (např. node-authenticate-pam nebo node-red-lwm2m). A na to potřebuješ různá komplexní buildovací prostředí (ta jako doplnění k prvnímu odstavci, aby se někdo nedivil, že to zařízení zvládá obecně Node.js, ale ne NPM).
Zamknout to přes package-lock.json jsem samozřejmě zkoušel. Funguje to, ale jen v prvním levelu. U zanořených závislostí to prostě občas ignoruje.
Co se týká off-line, tak problém je, že my musíme zákazníkovi zaručit stále stejný produkt, ale nám nikdo nezaručí, že z repozitáře se ta jedna konkrétní verze jedné z tisíců závislostí, jednoho dne neztratí. Zkoušel jsem v package-lock.json zadat node pomocí file://, ale opět, u zanořených závislostí to občas ignoruje.
-
null null (neregistrovaný)
@Kolja
A no co ti brání si to zkopírovat do složky a pak to distribuovat odtud?
"ale nám nikdo nezaručí, že z repozitáře se ta jedna konkrétní verze jedné z tisíců závislostí, jednoho dne neztratí."
No to ale není chyba NPM. To je obecná vlastnost toho, když si uděláš závislosts na něčem veřejném nad čím nemáš kontrolu.
-
Hlavně miliarda různých nářečí a frameworků. :-D A ještě javascriptík, který se má používat u klienta a ne někde na serveru. JS mám rád a používám, ale na serveru bych to nechtěl. Ne, fakt, napíšu si jednoduchý a efektivní skript v PHP a mám pokoj. Mám rád základní jazyky a taky v nich píšu, kromě jQuery se frameworkům vyhýbám, protože je to prostě.. ehm... zlo. ;) Upalujte si mě tu a křičte na mě, mě je to naprosto šumafuk. Nevím, co je špatného na PHP na serveru a proč ho všichni tak nenávidí. Jedu si spokojeně na 7.1 a nic mi tam nechybí. Rvát tam ještě javascript.. To fakt ne. Hlavně víte co, mě štve ta komplikovanost. Prostě si napíšu krátký skript a hotovo. Nějaký balíček, tam naimportovat tuhle a tamtu knihovnu, ideálně nějaké složité běhové prostředí a jen rozjetí celého řešení stojí minimálně hodinu času. Ne, fakt děkuji. Já chci SSH, v něm v jakémkoliv texťáku napsat program, uploadnout a je hotovo. Verzování si udělám sám, na to nepotřebuji nějaké berličky. Nebo třeba ten pitomý Ruby on Rails. Je to nepřehledné a furt to zlobí. Ne mě, já v něm nedělám, ale vím o problémech. Pak se tam člověk chce připojit, udělat rychlý fix v části, které rozumí, ale ne, ono se to ještě musí kompilovat a kdoví co ještě. Mám rád prostě jednoduchost. Piš a funguj. Jo, možná popátrám na Pythonem na serveru, ten by mě naopak zajímal. :-) A vidíte toho smajlíka jako mého avatara, viďte? No stress. :-D
-
null null (neregistrovaný)
@Libor Šedivý
No to máš jako pravdu, proti tomu nic. JS Frameworky nejsou moc výhodné - spousta berliček protože prostě rozsah JS, překotný vývoj a zpětná kompatibilita je za rok tak hodit si korunou - no proč ne, ale výhoda to rozhodně není. Problém je v tom když někdo začne vykřikovat blbiny jako:
'"porušují se základní best practice" je vše co potřebujete vědět.'
bez jediné ukázky a další ...
ČLÁNKY DO MAILU