7 nycklar för att strukturera din Node.js-app

Rahul Mhatre är teknisk arkitekt på Built.io.

Node.js hämtar snabbt Java, Ruby, Python och .Net som ett föredraget språk för att utveckla nya webbapplikationer. Node.js-teamet gör JavaScript-körningen bättre, snabbare och mer solid för varje dag som går. Och användargruppen växer med ett snabbt klipp.

När adopteringen fortsätter att öka kommer fler och fler utvecklare att klättra in på Node.js-inlärningskurvan, möta liknande problem och koda liknande funktioner. Tack och lov har Node.js-communityn kommit till undsättning med ramar och designmönster som inte bara löser vanliga problem utan också hjälper till att strukturera applikationer.

Framework implementerar vanligtvis MV-mönster som MVC (modell-view-controller), MVVM (model-view-viewmodel), MVP (model-view-presenter) eller bara MV. De berättar också var koden för modeller, vyer och styrenheter ska vara, var dina rutter ska vara och var du ska lägga till dina konfigurationer. Många unga utvecklare och Node.js-entusiaster förstår inte riktigt hur designmönster eller OOP-diagram (Object Oriented Programming) kartlägger till raderna eller strukturen i koden i deras applikation.

Det är där Node.js-ramverk som Express.js och Sails.js kommer in. Dessa och många andra är tillgängliga för att hjälpa till att starta utvecklingen av webbapplikationer. Oavsett vilket ramverk du använder vill du ha vissa överväganden i åtanke när du strukturerar din app.

Här är de sju viktiga punkterna jag tänker på innan jag kartlägger ett Node.js-program.

1. Rätt katalogstruktur för appen

När du bestämmer dig för katalogstrukturen för din app bör du överväga det designmönster du valde. Detta hjälper till med ombordstigning, hitta kod och isolera problem snabbare. Jag personligen föredrar att använda ett MVC-mönster när jag arkiverar en Node.js-app. Det hjälper mig att utveckla snabbare, ger flexibilitet för att skapa flera vyer för samma data och möjliggör asynkron kommunikation och isolering mellan MVC-komponenter, för att nämna några.

Jag gillar att följa katalogstrukturen som visas ovan, som är baserad på en kombination av Ruby on Rails och Express.js.

Relaterad video: Node.js tips och tricks

I den här förklaringsvideoen lär du dig flera tekniker som kan förbättra din utvecklingsupplevelse för nod.

2. Kartlägga ER-diagram till modeller

Som definierats i Techopedia, "Ett enhetsrelationsdiagram (ERD) är en datamodelleringsteknik som grafiskt illustrerar ett informationssystems enheter och förhållandena mellan dessa enheter." Ett ER-diagram beskriver de olika enheterna som kommer att delta i vårt system och definierar alla interaktioner mellan dem så att:

  • Allt som är en abstrakt eller fysisk ”sak” blir en enhet i en modell
  • En modell kartläggs till en tabell i vår databas
  • Ett attribut eller en egenskap hos en enhet översätts till ett attribut för en modell, vilket i sin tur är en kolumn i en tabell

Till exempel, om din enhet är en användare, skulle motsvarande modell vara en "användare" med attribut som förnamn, efternamn och adress i databasen samt en motsvarande tabell och kolumner.

Med hjälp av en enkel dataarkitektur blir det ganska enkelt att spåra din databas och filtillväxt varje gång ett nytt schema skapas.

3. Använda MVP-mönstret

Implementering av MVC betyder inte bara att skapa mappar för styrenheter, vyer och modeller. Du måste också dela din kod och logik enligt MVC. Koden inuti dina modeller bör vara strikt begränsad till definitioner av databasscheman. Utvecklare glömmer i allmänhet att modellerna också kommer att ha kod som utför CRUD-operationer. Alla funktioner eller funktioner som är specifika för den modellen ska också finnas i den här filen. De flesta affärslogik relaterade till en modell bör finnas i den här filen.

Ett vanligt misstag är att dumpa all affärslogik till styrenheter. Styrenheter ska endast åberopa funktioner från modeller eller andra komponenter, överföra data mellan komponenter och styra flödet av begäran, medan visningsmappen endast ska ha kod för att konvertera objekt till läsbar form. Ingen logik som formateringsdata eller sortering eller filtrering bör göras inuti vyn. Att hålla vyer rena ger inte bara en bättre användarupplevelse utan hjälper dig också att ändra vyer utan att ändra någon annan komponent.

4. Bryta ut logik i moduler

Som utvecklare får vi alltid veta att vi ska organisera koden i filer och moduler. Detta betyder inte att vi ska försöka passa hela appen i en enda fil. Att dela din kod baserat på logik och funktionalitet är det bästa tillvägagångssättet. Gruppera funktioner relaterade till en enskild enhet eller ett objekt i en enda fil och organisera katalogstrukturen baserat på logik har många fördelar. Först kommer det att spara mycket tid att bestämma vilken funktion som ska beröras när ett fel måste åtgärdas. För det andra hjälper det att koppla bort alla komponenter i arkitekturen, vilket underlättar utbyte av diskret funktionalitet utan att behöva ändra några andra kodrader. För det tredje kommer det också att hjälpa till att skriva testfall.

5. Vikten av testfall

Det är väldigt viktigt att aldrig klippa hörn när du bygger testfall - tester är vårdnadshavare för din kodbas. När din ansökan växer blir det svårare att komma ihåg alla scenarier du måste täcka medan du kodar. Testfall hjälper dig att hålla din kodbas stabil. Testning förhindrar regression, vilket sparar värdefull utvecklingstid och ansträngning. Det hjälper dig att se till att nya funktioner kommer att drivas felfria. Det hjälper också till att förbättra kodkvaliteten genom att fånga buggar innan de går i produktion. Och viktigast av allt, testning hjälper till att skapa förtroende för att koden inte kommer att krascha.

6. Vikten av stockar

Loggar är användbara för att felsöka och förstå applikationens tillstånd. De ger värdefull insikt i appens beteende. Här är en snabb lista över saker att tänka på när du använder loggar:

  • Hitta rätt balans när det gäller loggning. Att ha "för mycket information" är aldrig dåligt, men överloggning kommer bara att göra ditt jobb svårare. Nålar är lättare att hitta i mindre höstackar. På baksidan kommer underloggning att resultera i för lite information tillgänglig för att felsöka eller diagnostisera.
  • Dela dina offline- och online-loggar, där de senaste loggarna förvaras för snabb hämtning och bearbetning medan de äldre loggarna arkiveras eller dumpas till filer.
  • Tänk på frekvensen och varaktigheten för dina loggar eftersom det kommer att påverka mängden lagring du behöver. Oftast är mängden lagring du behöver och antalet loggar du har direkt proportionell.

Och kom ihåg, logga inte känsliga data som e-post-ID, lösenord, kreditkortsinformation och telefonnummer. Det är inte bara en enorm säkerhetsrisk utan ofta olagligt.

7. Kommer applikationen att skala?

Det värsta tillvägagångssättet för applikationsutveckling är att tänka på hur du kan skala efter att du fått trafik. Istället bör du bygga en arkitektur som har förmågan att växa från början för att spara tid och öka produktiviteten.

Spinning upp servrar är inte skalning; fördela belastning över resurser är. Detta betyder inte att du inte ska leka nya servrar när belastningen ökar. Först bör du ställa in lastbalansering inom dina nuvarande resurser för att hantera den ökade belastningen. När lastbalanseringen inte effektivt kan hantera arbetsbelastningen är det dags att börja horisontell skalning och skapa nya servrar. Du kan uppnå detta genom en oberoende statslös process eller via moduler. Varje process eller modul fungerar på ett isolerat, oberoende sätt. Detta hjälper inte bara din applikation att skala effektivt, utan gör också ditt system feltolerant och lätt att återställa.

Hur du strukturerar en webbapplikation är lika viktigt som att välja rätt teknik. Om grunden är bristfälliga kommer applikationen så småningom att krascha eller vägra att skala eller i vissa fall inte starta alls. Skynda dig aldrig med att utveckla nya funktioner eller nya idéer utan ordentlig planering och arkitektur. Dålig struktur eller arkitektur är som en tickande bomb som väntar på att explodera.

New Tech Forum är en plats för att utforska och diskutera framväxande företagsteknologi i oöverträffat djup och bredd. Urvalet är subjektivt, baserat på vårt val av den teknik som vi anser vara viktig och av största intresse för läsarna. accepterar inte marknadsföringssäkerhet för publicering och förbehåller sig rätten att redigera allt innehåll som har bidragit. Skicka alla förfrågningar till [email protected]