Programmering

7 nøgler til strukturering af din Node.js-app

Rahul Mhatre er teknisk arkitekt hos Built.io.

Node.js indhenter hurtigt Java, Ruby, Python og .Net som et foretrukket sprog til udvikling af nye webapplikationer. Node.js-teamet gør JavaScript-runtime bedre, hurtigere og mere solid med hver dag der går. Og brugergruppen vokser med et hurtigt klip.

Efterhånden som vedtagelsen fortsætter med at stige, vil flere og flere udviklere bestige Node.js-læringskurven og konfrontere lignende problemer og kode lignende funktioner. Heldigvis er Node.js-samfundet kommet til undsætning med rammer og designmønstre, der ikke kun løser almindelige problemer, men også hjælper med at strukturere applikationer.

Frameworks implementerer generelt MV-mønstre som MVC (model-view-controller), MVVM (model-view-viewmodel), MVP (model-view-presentator) eller bare MV. De fortæller dig også, hvor koden til modeller, visninger og controllere skal være, hvor dine ruter skal være, og hvor du skal tilføje dine konfigurationer. Mange unge udviklere og Node.js-entusiaster forstår ikke rigtig, hvordan designmønstre eller OOP (Object Oriented Programming) -diagrammer kortlægges til linjerne eller strukturen i koden i deres applikation.

Det er her, Node.js-rammer som Express.js og Sails.js kommer ind. Disse og mange andre er tilgængelige for at hjælpe med at starte udviklingen af ​​webapplikationer. Uanset hvilken ramme du bruger, vil du være opmærksom på visse overvejelser, når du strukturerer din app.

Her er de syv nøglepunkter, jeg overvejer, inden jeg kortlægger en Node.js-applikation.

1. Den rigtige katalogstruktur til appen

Mens du beslutter dig for katalogstrukturen til din app, skal du overveje det designmønster, du valgte. Dette vil hjælpe med ombordstigning, finde kode og isolere problemer hurtigere. Jeg foretrækker personligt at bruge et MVC-mønster, mens jeg arkiverer en Node.js-app. Det hjælper mig med at udvikle mig hurtigere, giver fleksibilitet til at oprette flere visninger til de samme data og tillader asynkron kommunikation og isolering mellem MVC-komponenter, for at nævne nogle få.

Jeg kan godt lide at følge katalogstrukturen vist ovenfor, som er baseret på en kombination af Ruby on Rails og Express.js.

Relateret video: Node.js tip og tricks

I denne forklaringsvideo lærer du flere teknikker, der kan forbedre din Node-udviklingsoplevelse.

2. Kortlægning af ER-diagrammer til modeller

Som defineret i Techopedia, “Et enhedsrelationsdiagram (ERD) er en datamodelleringsteknik, der grafisk illustrerer et informationssystems enheder og forholdet mellem disse enheder.” Et ER-diagram skitserer de forskellige enheder, der vil deltage i vores system og definerer alle interaktioner mellem dem således, at:

  • Alt, hvad der er en abstrakt eller fysisk ”ting” bliver en enhed i en model
  • En model kortlægges til en tabel inde i vores database
  • En attribut eller egenskab for en enhed oversættes til en attribut for en model, som igen er en kolonne inde i en tabel

For eksempel, hvis din enhed er en bruger, ville den tilsvarende model være en "bruger" med attributter som fornavn, efternavn og adresse inde i databasen samt en tilsvarende tabel og kolonner.

Brug af en simpel dataarkitektur gør det ret ligetil at spore din database og filvækst, når som helst et nyt skema oprettes.

3. Brug af MVP-mønsteret

Implementering af MVC betyder ikke bare at oprette mapper til controllere, visninger og modeller. Du skal også opdele din kode og logik i henhold til MVC. Koden inde i dine modeller skal være strengt begrænset til definitioner af databaseskemaer. Udviklere glemmer generelt, at modellerne også har kode, der udfører CRUD-operationer. Enhver funktion eller operation, der er specifik for den model, skal også være til stede i denne fil. Det meste af forretningslogikken relateret til en model skal være i denne fil.

En almindelig fejl er at dumpe al forretningslogik til controllere. Controllere bør kun påberåbe sig funktioner fra modeller eller andre komponenter, overføre data mellem komponenter og styre strømmen af ​​anmodningen, mens visningsmappen kun skal have kode til at konvertere objekter til menneskelig læsbar form. Ingen logik som formateringsdata eller sortering eller filtrering skal foretages inde i visningen. At holde visningerne rene giver ikke kun en bedre brugeroplevelse, men hjælper dig også med at ændre visninger uden at ændre nogen anden komponent.

4. Opdel i logik i moduler

Som udviklere får vi altid at vide, at vi skal organisere kode i filer og moduler. Dette betyder ikke, at vi skal prøve at passe hele appen ind i en enkelt fil. At opdele din kode baseret på logik og funktionalitet er den bedste tilgang. Gruppering af funktioner relateret til en enkelt enhed eller et objekt i en enkelt fil og organisering af bibliotekstrukturen baseret på logik har mange fordele. For det første sparer det meget tid på at bestemme, hvilken funktion der skal berøres, når en fejl skal rettes. For det andet hjælper det med at afkoble alle komponenterne i arkitekturen, hvilket letter udskiftning af diskret funktionalitet uden behov for at ændre andre kodelinjer. For det tredje vil det også hjælpe med at skrive testsager.

5. Betydningen af ​​testsager

Det er meget vigtigt aldrig at skære hjørner, når du bygger testsager - tests er værgerne for din kodebase. Efterhånden som din ansøgning vokser, bliver det sværere at huske alle de scenarier, du skal dække, mens du koder. Testcases hjælper dig med at holde din kodebase stabil. Test forhindrer regression, hvilket sparer værdifuld udviklingstid og kræfter. Det hjælper dig med at sikre, at nye funktioner bliver skubbet fejlfrie. Det hjælper også med at forbedre kodekvaliteten ved at fange bugs, før de går i produktion. Og vigtigst af alt hjælper testning med at skabe tillid til, at koden ikke går ned.

6. Vigtigheden af ​​logfiler

Logfiler er nyttige til fejlfinding og forståelse af applikationens tilstand. De giver værdifuld indsigt i appens opførsel. Her er en hurtig liste over ting, du skal huske på, når du bruger logfiler:

  • Find den rette balance, når det kommer til logning. At have "for meget information" er aldrig dårligt, men overlogning vil kun gøre dit job sværere. Nåle er lettere at finde i mindre høstakke. På bagsiden vil underlogging resultere i for lidt information tilgængelig til fejlfinding eller diagnose.
  • Opdel dine offline- og online-logfiler, hvor de nyeste logfiler opbevares for hurtig hentning og behandling, mens de ældre logfiler arkiveres eller dumpes til filer.
  • Overvej hyppigheden og varigheden af ​​dine logfiler, da det vil påvirke mængden af ​​lagerplads, du har brug for. De fleste gange er mængden af ​​lagerplads, du har brug for, og antallet af logfiler, du har direkte proportional.

Og husk, log ikke følsomme data såsom e-mail-id'er, adgangskoder, kreditkortoplysninger og telefonnumre. Det er ikke kun en enorm sikkerhedsrisiko, men ofte ulovlig.

7. Vil ansøgningen blive skaleret?

Den værste tilgang til applikationsudvikling er at tænke over, hvordan man skalerer efter du får trafik. I stedet skal du opbygge en arkitektur, der har evnen til at vokse fra starten for at spare tid og øge produktiviteten.

Spinning af servere er ikke skalering; fordeling af belastning på tværs af ressourcer er. Dette betyder ikke, at du ikke skal gyde nye servere, når belastningen stiger. Først skal du oprette belastningsbalancering inden for dine nuværende ressourcer til at håndtere den øgede belastning. Når belastningsbalanceringen ikke effektivt kan styre arbejdsbyrden, er det tid til at begynde vandret skalering og gyde nye servere. Du kan opnå dette gennem en uafhængig statsløs proces eller via moduler. Hver proces eller modul fungerer på en isoleret, uafhængig måde. Dette hjælper ikke kun din applikation med at skalere effektivt, men gør også dit system fejltolerant og let at gendanne.

Hvordan du strukturerer en webapplikation er lige så vigtig som at vælge den rigtige teknologi. Hvis fundamenterne er fejlbehæftede, vil applikationen til sidst gå ned eller nægte at skalere eller i nogle tilfælde ikke starte overhovedet. Skynd dig aldrig med at udvikle nye funktioner eller nye ideer uden ordentlig planlægning og arkitektur. Dårlig struktur eller arkitektur er som en tikkende tidsbombe, der venter på at eksplodere.

New Tech Forum giver et sted at udforske og diskutere nye virksomhedsteknologier i hidtil uset dybde og bredde. Valget er subjektivt baseret på vores valg af de teknologier, som vi mener er vigtige og af største interesse for læserne. accepterer ikke markedsføringssikkerhed til offentliggørelse og forbeholder sig retten til at redigere alt bidraget indhold. Send alle forespørgsler til [email protected]