javascript - Hur bestämmer man när man ska använda Node.js?

Jag är ny på den här typen av saker, men på sistone har jag hört mycket om hur bra Node.js är. Med tanke på hur mycket jag älskar att arbeta med jQuery och JavaScript i allmänhet, kan jag inte låta bli att undra hur man bestämmer när man ska använda Node.js. Webapplikationen jag har i åtanke är något liknande Bitly - tar innehåll och arkiverar det.

Från allt det läxor jag har gjort de senaste dagarna har jag fått följande information. Node.js

är ett kommandoradsverktyg som kan köras som en vanlig webbserver och låter en köra JavaScript-program
använder den kraftfulla V8 JavaScript-motorn
är mycket bra när du behöver göra flera saker samtidigt
är händelsebaserat så allt det underbara Ajax-liknande kan göras på serversidan
låt oss dela kod mellan webbläsaren och backend
låt oss prata med MySQL

Några av de källor som jag har stött på är:

Att dyka in i Node.js - Introduktion och installation
Förstå NodeJS
Node genom exempel (Archive.is)
Låt oss skapa en webbapp: NodePad

Med tanke på att Node.js nästan kan användas direkt på Amazons EC2-instanser, försöker jag förstå vilken typ av problem som kräver Node.js jämfört med någon av de mäktiga språken där ute som PHP, Python och Ruby. Jag förstår att det verkligen beror på vilken expertis man har i ett språk, men min fråga faller mer in i den allmänna kategorin: När bör man använda ett särskilt ramverk och vilken typ av problem är det särskilt lämpat för?

Svar #1

Du gjorde ett utmärkt jobb med att sammanfatta vad som är fantastiskt med Node.js. Min känsla är att Node.js är särskilt lämpat för applikationer där du vill upprätthålla en bestående anslutning från webbläsaren tillbaka till servern. Genom att använda en teknik som kallas "long-polling" kan du skriva en applikation som skickar uppdateringar till användaren i realtid. Att göra long polling på många av webbsidans jättar, som Ruby on Rails eller Django, skulle skapa enorm belastning på servern, eftersom varje aktiv klient använder en serverprocess. Denna situation motsvarar en tarpit-attack. När du använder något som Node.js behöver servern inte upprätthålla separata trådar för varje öppen anslutning.

Detta innebär att du kan skapa en webbläsarbaserad chattapplikation i Node.js som tar nästan inga systemresurser för att betjäna många klienter. När du vill göra den här sortens lång-polling är Node.js ett utmärkt alternativ.

Det är värt att nämna att Ruby och Python båda har verktyg för att göra den här typen av saker (eventmachine respektive twisted), men att Node.js gör det exceptionellt bra, och från grunden. JavaScript är exceptionellt väl anpassat till en callback-baserad samtidighetsmodell, och det utmärker sig här. Dessutom är det ganska fiffigt att kunna serialisera och deserialisera med JSON som är inbyggt både på klienten och servern.

Jag ser fram emot att läsa andra svar här, detta är en fantastisk fråga.

Det är värt att påpeka att Node.js också är utmärkt för situationer där du kommer att återanvända mycket kod över klient-/servergränsen. Meteor-ramverket gör detta riktigt enkelt, och många föreslår att detta kan vara framtiden för webbutveckling. Jag kan säga av erfarenhet att det är riktigt roligt att skriva kod i Meteor, och en stor del av detta är att spendera mindre tid på att tänka på hur du ska omstrukturera din data, så att koden som körs i webbläsaren enkelt kan manipulera den och skicka tillbaka den.

Här är en artikel om Pyramid och long-polling, som visar sig vara mycket lätt att sätta upp med lite hjälp från gevent: TicTacToe och Long Polling med Pyramid.

Svar #2

Jag tror att Node.js är bäst lämpat för realtidsapplikationer: onlinespel, samarbetsverktyg, chattrum eller vad som helst där det en användare (eller robot? eller sensor?) gör med applikationen måste ses av andra användare omedelbart, utan att sidan behöver uppdateras.

Jag bör också nämna att Socket.IO i kombination med Node.js kommer att minska din realtidslatens ännu mer än vad som är möjligt med långpolling. Socket.IO kommer att falla tillbaka på långpolling som ett värsta fallsscenario, och istället använda webbsockets eller till och med Flash om de är tillgängliga.

Men jag bör också nämna att nästan vilken situation som helst där koden kan blockera på grund av trådar kan hanteras bättre med Node.js. Eller vilken situation som helst där du behöver att applikationen ska vara händelsestyrd.

Dessutom sa Ryan Dahl i ett föredrag som jag en gång deltog i att Node.js-benchmarks ligger nära Nginx för vanliga gamla HTTP-förfrågningar. Så om vi bygger med Node.js kan vi leverera våra vanliga resurser ganska effektivt, och när vi behöver det händelsestyrda är det redo att hantera det.

Dessutom är det bara JavaScript hela tiden. Lingua franca på hela stacken.

Svar #3

Anledningar att använda NodeJS:

Det kör Javascript, så du kan använda samma språk på server och klient, och till och med dela viss kod mellan dem (t.ex. för formulärvalidering eller för att rendera vyer på båda sidor).
Det enkeltrådiga händelsestyrda systemet är snabbt även när det hanterar många förfrågningar samtidigt, och också enkelt, jämfört med traditionella multitrådade Java- eller ROR-ramverk.
Den ständigt växande samlingen av paket som är tillgängliga genom NPM, inklusive klient- och server-sidans bibliotek/moduler, samt kommandoradsverktyg för webbutveckling. De flesta av dessa är bekvämt värd på GitHub, där du ibland kan rapportera ett problem och få det åtgärdat inom timmar! Det är trevligt att ha allt under ett tak, med standardiserad felrapportering och enkel förgrening.
Det har blivit den facto-standardmiljön där man kör Javascript-relaterade verktyg och andra webbrelaterade verktyg, inklusive arbetsuppgiftskörningar, minifierare, beautifiers, linters, preprocessorer, bundlers och analysprocessorer.
Det verkar ganska lämpligt för prototyper, agil utveckling och snabb produktiteration.

Anledningar att inte använda NodeJS:

Den kör Javascript, vilket inte har typkontroll vid kompilering. För stora, komplexa säkerhetskritiska system, eller projekt som inkluderar samarbete mellan olika organisationer, kan ett språk som uppmuntrar kontraktsbaserade gränssnitt och erbjuder statisk typkontroll spara dig en del felsökningstid (och explosioner) på lång sikt. (Även om JVM är fast med null, så använd gärna Haskell för dina kärnreaktorer.)
Därtill är många av paketen i NPM lite råa och fortfarande under snabb utveckling. Vissa bibliotek för äldre ramverk har genomgått ett decennium av testning och buggfixar, och är mycket stabila vid det här laget. Npmjs.org har ingen mekanism för att betygsätta paket, vilket har lett till en spridning av paket som gör mer eller mindre samma sak, varav en stor andel inte längre underhålls.
Inbäddat callback-helvete. (Självklart finns det 20 olika lösningar på detta...)
Den ständigt växande mängden paket kan få ett NodeJS-projekt att framstå som radikalt annorlunda jämfört med nästa. Det finns en stor variation i implementationer på grund av det enorma antalet tillgängliga alternativ (t.ex. Express/Sails.js/Meteor/Derby). Detta kan ibland göra det svårare för en ny utvecklare att hoppa in i ett Node-projekt. Jämför detta med en Rails-utvecklare som går med i ett befintligt projekt: han bör kunna bli bekant med appen ganska snabbt, eftersom alla Rails-appar uppmuntras att använda en liknande struktur.
Att hantera filer kan vara lite besvärligt. Saker som är triviala i andra språk, som att läsa en rad från en textfil, är tillräckligt konstiga att göra med Node.js att det finns en fråga på StackOverflow om det med över 80 röster. Det finns inget enkelt sätt att läsa en post i taget från en CSV-fil. Och så vidare.

Jag älskar NodeJS, det är snabbt och vilt och roligt, men jag är orolig för att det har litet intresse för bevisbar korrekthet. Låt oss hoppas att vi så småningom kan förena det bästa av båda världar. Jag är ivrig att se vad som kommer att ersätta Node i framtiden... :)

Svar #4

För att göra det kort:

Node.js är väl lämpat för applikationer som har många samtidiga anslutningar och varje förfrågan bara behöver väldigt få CPU-cykler, eftersom händelseloopen (med alla andra klienter) blockeras under körning av en funktion.

En bra artikel om eventloopen i Node.js är Mixus teknikblogg: Förstå Node.js eventloop.

Svar #5

Jag har ett verkligt exempel där jag har använt Node.js. Företaget där jag arbetar fick en klient som ville ha en enkel statisk HTML-webbplats. Denna webbplats är för att sälja en vara med PayPal och klienten ville också ha en räknare som visar antalet sålda varor. Klienten förväntade sig att ha ett stort antal besökare på denna webbplats. Jag bestämde mig för att göra räknaren med Node.js och ramverket Express.js.

Node.js-applikationen var enkel. Hämta antalet sålda varor från en Redis-databas, öka räknaren när en vara säljs och tillhandahåll räknarvärdet till användare via API:et.

Några skäl till varför jag valde att använda Node.js i detta fall

Det är mycket lätt och snabbt. Det har varit över 200000 besök på den här webbplatsen på tre veckor och minimala serverresurser har kunnat hantera allt.
Räknaren är verkligen lätt att göra i realtid.
Node.js var lätt att konfigurera.
Det finns många moduler tillgängliga gratis. Till exempel hittade jag en Node.js-modul för PayPal.

I det här fallet var Node.js ett fantastiskt val.

Svar #6

De viktigaste anledningarna till att påbörja ditt nästa projekt med Node ...

Alla de coolaste killarna är inne på det ... så det måste vara roligt.
Du kan hänga vid kylskåpet och ha massor av Node-äventyr att skryta om.
Du är en snåljåp när det gäller kostnader för molnhosting.
Har varit där, gjort det med Rails
Du hatar IIS-distributioner
Ditt gamla IT-jobb börjar bli ganska tråkigt och du önskar att du var på en glänsande ny Start Up.

Vad man kan förvänta sig ...

Du kommer att känna dig trygg och säker med Express utan all serverprogramvara du aldrig behövde.
Fungerar som en raket och skalar bra.
Du drömmer det. Du installerade det. Node-paketbiblioteket npmjs.org är det största ekosystemet av öppen källkods-bibliotek i världen.
Din hjärna kommer att bli tidsförvrängd i landet av nästlade callback-funktioner ...
... tills du lär dig att hålla dina löften.
Sequelize och Passport är dina nya API-vänner.
Felsökning av mestadels asynkron kod kommer att bli, eh ... intressant.
Dags för alla Noders att behärska Typescript.

Vem använder det?

PayPal, Netflix, Walmart, LinkedIn, Groupon, Uber, GoDaddy, Dow Jones
Här är varför de bytte till Node.

Svar #7

Det finns inget som Silver Bullet. Allt har någon kostnad kopplad till sig. Det är som att om du äter fet mat, kommer du att äventyra din hälsa, och hälsosam mat kommer inte med kryddor som fet mat gör. Det är individens val om de vill ha hälsa eller kryddor i sin mat. På samma sätt anses Node.js användas i specifika scenarier. Om din app inte passar in i det scenariot bör du inte överväga det för apputveckling. Jag delar bara mina tankar om det här:

När man ska använda Node.JS

Om din serversida kod kräver mycket få CPU-cykler. Med andra ord gör du icke-blockerande operationer och har inte en tung algoritm/jobb som konsumerar många CPU-cykler.
Om du kommer från en JavaScript-bakgrund och är bekväm med att skriva entrådad kod precis som klient-sida JS.

När man INTE ska använda Node.JS

Din serverförfrågan är beroende av en CPU-intensiv algoritm/job.

Skalbarhetsövervägande med Node.JS

Node.JS själv använder inte alla kärnor i det underliggande systemet och det är singeltrådat som standard, du måste skriva logik själv för att utnyttja en flerkärnig processor och göra det flerkärnat.

Node.JS-alternativ

Det finns andra alternativ att använda istället för Node.JS, men Vert.x verkar vara ganska lovande och har många ytterligare funktioner som polygot och bättre skalbarhetsöverväganden.

Svar #8

En annan fantastisk sak som jag tror att ingen har nämnt om Node.js är det fantastiska communityt, paketshanteringssystemet (npm) och mängden moduler som finns och som du kan inkludera genom att helt enkelt inkludera dem i din package.json-fil.

Svar #9

Mitt inlägg: nodejs är fantastiskt för att skapa realtidsystem som analys, chattappar, API:er, annonsservrar, osv. S**n**, jag gjorde min första chattapp med nodejs och socket.io på under 2 timmar och det dessutom under tentaveckan!

Redigera

Det har gått flera år sedan jag började använda Node.js och jag har använt det för att göra många olika saker inklusive statiska filservrar, enkel analys, chattappar och mycket mer. Detta är min syn på när man ska använda Node.js

När man ska använda

När man skapar system som lägger vikt vid samtidighet och hastighet.

Endast sockets-servrar som chattappar, irc-appar, etc.
Sociala nätverk som lägger tonvikt på realtidsresurser som geolokalisering, videoström, ljudström, etc.
Hantera små datamängder väldigt snabbt som en analyswebbapp.
Som att exponera endast ett REST API.

När man inte ska använda

Det är en mycket mångsidig webbserver så du kan använda den var du vill men förmodligen inte på dessa platser.

Enkla bloggar och statiska webbplatser.
Precis som en statisk filserver.

Kom ihåg att jag bara petar i detaljer. För servrar som hanterar statiska filer är apache bättre främst för att det är allmänt tillgängligt. Nodejs-gemenskapen har vuxit större och mognare över åren och det är säkert att säga att nodejs kan användas nästan överallt om du har ditt eget val av hosting.

Svar #10

Det kan användas där

Applikationer som är mycket händelsestyrda och är starkt I/O-bundna
Applikationer som hanterar ett stort antal anslutningar till andra system
Real-tidsapplikationer (Node.js designades från grunden för realtid och för att vara lätt att använda.)
Program som jonglerar massor av information som strömmar till och från andra källor
Hög trafik, skalbara applikationer
Mobilappar som måste kommunicera med plattforms-API och databas, utan att behöva göra mycket dataanalys
Bygg ut nätverksanslutna applikationer
Applikationer som behöver kommunicera med back-end mycket ofta

På mobilfronten har ledande företag förlitat sig på Node.js för sina mobillösningar. Ta reda på varför?

LinkedIn är en framstående användare. Deras hela mobila stack är byggd på Node.js. De gick från att köra 15 servrar med 15 instanser på varje fysisk maskin, till bara 4 instanser - som kan hantera dubbelt så mycket trafik!

eBay lanserade ql.io, ett webbförfrågningsspråk för HTTP API:er, som använder Node.js som körstack. De kunde anpassa en vanlig utvecklarstation med Ubuntu för att hantera mer än 120 000 aktiva anslutningar per Node.js-process, där varje anslutning förbrukade cirka 2 kB minne!

Walmart byggde om sin mobilapp för att använda Node.js och flyttade sin JavaScript-bearbetning till servern.

Läs mer på: http://www.pixelatingbits.com/a-closer-look-at-mobile-app-development-with-node-js/

Svar #11

Nod bäst för samtidig hantering av förfrågningar -

Så, låt oss börja med en berättelse. Under de senaste 2 åren har jag arbetat med JavaScript och utvecklat webbfrontenden och jag tycker om det. Backend-gänget ger oss några API:er skrivna i Java, Python (det bryr vi oss inte om) och vi skriver helt enkelt ett AJAX-anrop, får våra data och gissa vad! vi är klara. Men i verkligheten är det inte så enkelt, om data vi får inte är korrekt eller om det finns ett serverfel, då står vi still och vi måste kontakta våra backend-gäng via mail eller chatt (ibland på WhatsApp också :).) Det är inte coolt. Tänk om vi skrev våra API:er i JavaScript och anropar dessa API:er från vår frontend? Ja, det är riktigt coolt eftersom om vi stöter på något problem i API:et kan vi titta på det. Gissa vad! du kan göra detta nu, hur? - Node finns där för dig.

Okej, vi är överens om att du kan skriva ditt API i JavaScript, men vad om jag är okej med ovanstående problem. Har du någon annan anledning att använda Node för ett REST-API?

så här börjar magin. Ja, jag har andra skäl att använda Node för våra API:er.

Låt oss gå tillbaka till vårt traditionella REST API-system som är baserat på antingen blockering eller trådning. Antag att två samtidiga förfrågningar uppstår (r1 och r2), och vardera kräver databasoperation. Så i det traditionella systemet, vad kommer att hända:

1. Väntesätt : Vår server börjar betjäna r1-förfrågan och väntar på svarsfrågan. Efter att r1 är slutförd, börjar servern att betjäna r2 och gör det på samma sätt. Så väntan är inte en bra idé eftersom vi inte har så mycket tid.

2. Trådmetod : Vår server skapar två trådar för båda förfrågningarna r1 och r2 och tjänar deras syfte efter att ha frågat databasen, så coolt det är snabbt. Men det är minneskrävande eftersom du kan se att vi startade två trådar, och problemet ökar när båda förfrågningarna frågar samma data, då måste du hantera typ av låsproblem. Så det är bättre än väntemetoden, men fortfarande finns det problem.

Nu här är, hur noden kommer att göra det:

3. Nodeway : När samma samtidiga förfrågan kommer in i Node kommer det att registrera en händelse med dess callback och gå vidare, det kommer inte att vänta på svar på en specifik förfrågan. Så när r1-förfrågan kommer registrerar Node:s händelseslinga (ja, det finns en händelseslinga i Node som tjänar detta syfte) en händelse med dess callback-funktion och går vidare för att hantera r2-förfrågan och registrerar på samma sätt dess händelse med dess callback. När någon fråga är klar triggar den sin motsvarande händelse och utför dess callback till fullbordande utan att bli avbruten.

Så ingen väntan, ingen trådning, inget minnesförbruk - ja, detta är nodeway för att serva REST API.

Svar #12

Min ännu en anledning att välja Node.js för ett nytt projekt är:

Kunna utföra ren molnbaserad utveckling

Jag har använt Cloud9 IDE ett tag och nu kan jag inte föreställa mig att vara utan det, det täcker alla utvecklingslivscykler. Allt du behöver är en webbläsare och du kan koda när som helst, var som helst på vilken enhet som helst. Du behöver inte checka in kod på en dator (som hemma) och sedan checka ut på en annan dator (som på arbetsplatsen).

Självklart kan det finnas molnbaserade IDE för andra språk eller plattformar (Cloud 9 IDE lägger också till stöd för andra språk), men att använda Cloud 9 för att utveckla Node.js är verkligen en fantastisk upplevelse för mig.

Svar #13

En sak till som node erbjuder är möjligheten att skapa flera v8-instans av node med hjälp av nodes barnprocess (childProcess.fork() som var och en kräver 10 MB minne enligt dokumentationen) på språng, vilket alltså inte påverkar huvudprocessen som kör servern. Så att avlasta ett bakgrundsjobb som kräver stor serverbelastning blir barnlek och vi kan enkelt avsluta dem när det behövs.

Jag har använt Node mycket och i de flesta av de appar vi bygger krävs serveranslutningar samtidigt, vilket leder till tung nätverkstrafik. Ramverk som Express.js och den nya Koajs (som tog bort callback-helvetet) har gjort det ännu enklare att arbeta med Node.

Svar #14

Tar på sig asbestlångkalsonger...

Igår gav jag ut min bok med Packt Publications, Reactive Programming with JavaScript. Den är egentligen inte en Node.js-centrerad titel; de tidiga kapitlen är avsedda att täcka teori, och de senare, kodtunga kapitlen täcker praktik. Eftersom jag egentligen inte tyckte det skulle vara lämpligt att låta läsarna vara utan en webbserver, verkade Node.js absolut det uppenbara valet. Fallet var avslutat innan det ens hade öppnats.

Jag hade kunnat ge en mycket rosig bild av min erfarenhet med Node.js. Istället var jag ärlig om både de goda och dåliga punkterna jag stötte på.

Låt mig inkludera några citat som är relevanta här:

Varning: Node.js och dess ekosystem är heta--heta nog att bränna dig ordentligt!
När jag var lärarassistent i matematik, var ett av de icke-uppenbara råden jag fick att inte säga till en elev att något var "lätt." Anledningen var något uppenbar i efterhand: om du säger åt människor att något är lätt, kan någon som inte ser en lösning sluta känna sig (ännu mer) dum, eftersom inte bara förstår de inte hur man löser problemet, utan problemet som de är för dumma för att förstå är ett lätt problem!
Det finns fallgropar som inte bara irriterar personer som kommer från Python/Django, som omedelbart laddar om källkoden om du ändrar något. Med Node.js är standardbeteendet att om du gör en ändring fortsätter den gamla versionen att vara aktiv tills tidens slut eller tills du manuellt stoppar och startar om servern. Detta olämpliga beteende irriterar inte bara Python-användare; det irriterar också inhemska Node.js-användare som erbjuder olika lösningar. StackOverflow-frågan „Auto-reload of files in Node.js“ har, vid tidpunkten för detta skrivande, över 200 röster upp och 19 svar; en redigering leder användaren till ett nanny-skript, node-supervisor, med hemsida på http://tinyurl.com/reactjs-node-supervisor. Detta problem ger nya användare en stor möjlighet att känna sig dumma eftersom de trodde att de hade åtgärdat problemet, men det gamla, buggiga beteendet är helt oförändrat. Och det är lätt att glömma att starta om servern; jag har gjort det flera gånger. Och budskapet jag vill ge är: "Nej, du är inte dum för att detta beteende hos Node.js föll dig på ryggen; det är bara det att designers av Node.js inte såg någon anledning att ge ett lämpligt beteende här. Försök att hantera det, kanske med lite hjälp från node-supervisor eller en annan lösning, men snälla, gå inte därifrån och känn att du är dum. Problemet är inte hos dig; problemet finns i Node.js standardbeteende."
Detta avsnitt, efter en del diskussion, lämnades kvar, just för att jag inte vill ge intrycket av 'Det är lätt.' Jag skar mig upprepade gånger medan jag försökte få saker att fungera, och jag vill inte sopa över svårigheter och få dig att tro att det är enkelt att få Node.js och dess ekosystem att fungera bra, och om det inte är enkelt för dig också, betyder det inte att du inte vet vad du håller på med. Om du inte stöter på irriterande svårigheter när du använder Node.js, är det fantastiskt. Om du gör det, hoppas jag att du inte går därifrån och känner 'Jag är dum—det måste vara något fel på mig.' Du är inte dum om du upplever obehagliga överraskningar när du arbetar med Node.js. Det är inte du! Det är Node.js och dess ekosystem!

Bilagan, som jag egentligen inte ville ha efter den stigande crescendo i de sista kapitlen och slutsatsen, handlar om vad jag kunde hitta i ekosystemet, och gav en lösning för idiotiskt bokstavstroende:

En annan databas som verkade vara en perfekt passform, och kanske fortfarande kan räddas, är en server-side-implementering av HTML5:s nyckel-värde-lagring. Detta tillvägagångssätt har den viktiga fördelen av ett API som de flesta skickliga front-end-utvecklare förstår tillräckligt väl. För den delen är det också ett API som de flesta inte så skickliga front-end-utvecklare förstår tillräckligt väl. Men med paketet node-localstorage, även om åtkomst med ordbokssyntax inte erbjuds (du vill använda localStorage.setItem(key, value) eller localStorage.getItem(key), inte localStorage[key]), är hela localStorage-semantiken implementerad, inklusive en standardkvot på 5 MB—VARFÖR? Behöver server-side JavaScript-utvecklare skyddas från sig själva?
För databasfunktioner på klientsidan är en kvot på 5 MB per webbplats verkligen en generös och användbar marginal som låter utvecklare arbeta med det. Du skulle kunna sätta en mycket lägre kvot och ändå erbjuda utvecklare en omätbar förbättring jämfört med att stappla sig fram med hantering av cookies. En gräns på 5 MB lämpar sig inte särskilt väl för storskalig databehandling på klientsidan, men det finns verkligen ett ganska generöst tillägg som resursfulla utvecklare kan använda för att göra mycket. Å andra sidan är 5 MB inte en särskilt stor del av de flesta diskar som köpts nyligen, vilket innebär att om du och en webbplats inte är överens om vad som är rimlig användning av diskutrymme, eller om någon webbplats helt enkelt är självisk, kostar det dig egentligen inte mycket och du är inte i någon risk för en överbelastad hårddisk om inte din hårddisk redan var för full. Kanske skulle vi ha det bättre om balansen var lite mindre eller lite mer, men överlag är det en hyfsad lösning för att hantera den inneboende spänningen i ett klientbaserat sammanhang.
Det kan dock försiktigt påpekas att när du är den som skriver koden för din server behöver du inget extra skydd för att göra din databas större än den tolerabla storleken på 5 MB. De flesta utvecklare kommer varken att behöva eller vilja ha verktyg som agerar som barnvakt och skyddar dem från att lagra mer än 5 MB server-sida data. Och den 5 MB kvota som är en gyllene balansakt på klientsidan är ganska lite löjlig på en Node.js-server. (Och för en databas för flera användare, som täcks i detta appendix, kan det påpekas, något smärtsamt, att det inte är 5 MB per användarkonto om du inte skapar en separat databas på disken för varje användarkonto; det är 5 MB som delas mellan alla användarkonton tillsammans. Det kan bli smärtsamt om du blir viral!) Dokumentationen anger att kvoten är anpassningsbar, men ett e-postmeddelande för en vecka sedan till utvecklaren som frågade hur man ändrar kvoten har inte besvarats, liksom StackOverflow-frågan som frågade samma sak. Det enda svaret jag har kunnat hitta finns i Githubs CoffeeScript-källa, där det listas som ett valfritt andra heltalsargument till en konstruktor. Så det är tillräckligt enkelt, och du kan specificera en kvot som motsvarar storleken på en disk eller partition. Men förutom att porta en funktion som inte är meningsfull, har verktygets skapare helt misslyckats med att följa en mycket vanlig konvention att tolka 0 som att det betyder "obegränsat" för en variabel eller funktion där ett heltal ska ange en maximal gräns för någon resursanvändning. Det bästa att göra med denna felaktiga funktion är förmodligen att specificera att kvoten är Oändlighet:

if (typeof localStorage === 'undefined' || localStorage === null)
  {      
  var LocalStorage = require('node-localstorage').LocalStorage;
  localStorage = new LocalStorage(__dirname + '/localStorage',
    Infinity);
  }

Byta plats på två kommentarer i ordning:

Människor sköt sig själva i foten i onödan hela tiden när de använde JavaScript som helhet, och en del av att JavaScript blev ett respektabelt språk var ett Douglas Crockford-uttalande i huvudsak, “JavaScript som språk har några riktigt bra delar och några riktigt dåliga delar. Här är de bra delarna. Glöm bara att något annat finns.” Kanske kommer det heta Node.js-ekosystemet att få sin egen “Douglas Crockford,” som kommer att säga, “Node.js-ekosystemet är ett kodande vilda västern, men det finns några riktiga juveler att hitta. Här är en färdplan. Här är områdena att undvika nästan till varje pris. Här är områdena med några av de rikaste fynden att hitta i VILKET språk eller miljö som helst.”
Kanske någon annan kan ta de orden som en utmaning och följa Crockfords ledning och skriva upp „de bra delarna“ och/eller „de bättre delarna“ för Node.js och dess ekosystem. Jag skulle köpa ett exemplar!
Och med tanke på graden av entusiasm och rena arbets timmar på alla projekt kan det vara motiverat om ett år, eller två, eller tre, att kraftigt tona ned eventuella kommentarer om ett omoget ekosystem gjorda vid denna tids punkt. Det kan verkligen vara meningsfullt om fem år att säga: "Node.js-ekosystemet 2015 hade flera minerade fält. Node.js-ekosystemet 2020 har flera paradis."