Rahul Mhatre er teknisk arkitekt hos Built.io.
Node.js tar raskt igjen Java, Ruby, Python og .Net som et foretrukket språk for utvikling av nye webapplikasjoner. Node.js-teamet gjør JavaScript-kjøretiden bedre, raskere og mer solid for hver dag som går. Og brukersamfunnet vokser med et raskt klipp.
Etter hvert som adopsjonen fortsetter å øke, vil flere og flere utviklere bestige Node.js-læringskurven, møte lignende problemer og kode lignende funksjoner. Heldigvis har Node.js-fellesskapet kommet til unnsetning med rammer og designmønstre som ikke bare løser vanlige problemer, men også hjelper til med å strukturere applikasjoner.
Framework implementerer vanligvis MV-mønstre som MVC (modell-visning-kontroller), MVVM (modell-visning-visningsmodell), MVP (modell-visning-presentatør), eller bare MV. De forteller deg også hvor koden for modeller, visninger og kontrollere skal være, hvor rutene dine skal være, og hvor du skal legge til konfigurasjonene dine. Mange unge utviklere og Node.js-entusiaster forstår egentlig ikke hvordan designmønstre eller OOP (Object Oriented Programming) -diagrammer tilordnes til linjene eller strukturen til koden i applikasjonen.
Det er der Node.js-rammer som Express.js og Sails.js kommer inn. Disse og mange andre er tilgjengelige for å hjelpe kickstart utviklingen av webapplikasjoner. Uansett rammeverket du bruker, vil du ha visse hensyn i bakhodet når du strukturerer appen din.
Her er de syv viktige punktene jeg tenker på før jeg kartlegger et Node.js-program.
1. Riktig katalogstruktur for appen
Mens du bestemmer deg for katalogstrukturen for appen din, bør du vurdere designmønsteret du valgte. Dette vil hjelpe deg med ombordstigning, finne kode og isolere problemer raskere. Jeg foretrekker personlig å bruke et MVC-mønster mens jeg arkiverer en Node.js-app. Det hjelper meg å utvikle raskere, gir fleksibilitet til å lage flere visninger for de samme dataene, og tillater asynkron kommunikasjon og isolasjon mellom MVC-komponenter, for å nevne noen.
Jeg liker å følge katalogstrukturen vist ovenfor, som er basert på en kombinasjon av Ruby on Rails og Express.js.
Relatert video: Node.js tips og triks
I denne forklaringsvideoen kan du lære deg flere teknikker som kan forbedre din Node-utviklingsopplevelse.
2. Kartlegge ER-diagrammer til modeller
Som definert i Techopedia, "Et enhetsrelasjonsdiagram (ERD) er en datamodelleringsteknikk som grafisk illustrerer enhetene til et informasjonssystem og forholdet mellom disse enhetene." Et ER-diagram skisserer de forskjellige enhetene som vil delta i systemet vårt og definerer alle interaksjoner mellom dem slik at:
- Alt som er en abstrakt eller fysisk “ting” blir en enhet i en modell
- En modell tilordnes til et bord i databasen vår
- Et attributt eller en egenskap til en enhet oversettes til et attributt til en modell, som igjen er en kolonne inne i en tabell
For eksempel, hvis enheten din er en bruker, vil den tilsvarende modellen være en "bruker" med attributter som fornavn, etternavn og adresse i databasen, samt en tilsvarende tabell og kolonner.
Ved å bruke en enkel dataarkitektur blir det ganske greit å spore databasen og filveksten når som helst et nytt skjema blir opprettet.
3. Bruke MVP-mønsteret
Implementering av MVC betyr ikke bare å opprette mapper for kontrollere, visninger og modeller. Du må også dele koden og logikken din i henhold til MVC. Koden i modellene dine bør være strengt begrenset til definisjoner av databaseskjemaer. Utviklere glemmer generelt at modellene også vil ha kode som vil utføre CRUD-operasjoner. Også enhver funksjon eller operasjon som er spesifikk for den modellen, skal være tilstede i denne filen. Det meste av forretningslogikken knyttet til en modell skal være i denne filen.
En vanlig feil er å dumpe all forretningslogikken til kontrollere. Kontrollere skal bare påkalle funksjoner fra modeller eller andre komponenter, overføre data mellom komponenter og kontrollere flyten av forespørselen, mens visningsmappen bare skal ha kode for å konvertere objekter til menneskelig lesbar form. Ingen logikk som formatering av data eller sortering eller filtrering skal gjøres inne i visningen. Å holde visningene rene vil ikke bare gi en bedre brukeropplevelse, men også hjelpe deg med å endre visninger uten å endre noen annen komponent.
4. Bryte ut logikk i moduler
Som utviklere blir vi alltid fortalt at vi skal organisere koden i filer og moduler. Dette betyr ikke at vi skal prøve å passe hele appen i en enkelt fil. Å dele koden din basert på logikk og funksjonalitet er den beste tilnærmingen. Å gruppere funksjoner relatert til en enkelt enhet eller et objekt i en enkelt fil og organisere katalogstrukturen basert på logikk har mange fordeler. For det første vil det spare mye tid på å bestemme hvilken funksjon du skal berøre når en feil må løses. For det andre hjelper det å koble fra alle komponentene i arkitekturen, noe som letter utskifting av diskret funksjonalitet uten behov for å endre noen andre kodelinjer. For det tredje vil det også hjelpe til med å skrive testsaker.
5. Betydningen av testsaker
Det er veldig viktig å aldri kutte hjørner når du bygger testsaker - tester er beskyttere av kodebasen din. Etter hvert som søknaden din vokser, blir det vanskeligere å huske alle scenariene du må dekke mens du koder. Testtilfeller hjelper deg å holde kodebasen stabil. Testing forhindrer regresjon, og sparer verdifull utviklingstid og krefter. Det hjelper deg med å sikre at nye funksjoner blir presset feilfrie. Det hjelper også med å forbedre kodekvaliteten ved å fange feil før de går i produksjon. Og viktigst av alt, testing hjelper til med å innpode tillit til at koden ikke krasjer.
6. Betydningen av logger
Logger er nyttige for feilsøking og forstå tilstanden til applikasjonen din. De gir verdifull innsikt i oppførselen til appen. Her er en rask liste over ting du må huske på når du bruker logger:
- Finn riktig balanse når det gjelder logging. Å ha "for mye informasjon" er aldri dårlig, men overlogging vil bare gjøre jobben din vanskeligere. Nåler er lettere å finne i mindre høystakker. På baksiden vil underlogging føre til for lite informasjon tilgjengelig for feilsøking eller diagnostisering.
- Del dine offline- og online-logger, der de nyeste loggene blir oppbevart for rask henting og behandling, mens de eldre loggene arkiveres eller dumpes til filer.
- Tenk på hyppigheten og varigheten på loggene, da det vil påvirke mengden lagring du trenger. De fleste ganger er lagringsmengden du trenger og antall logger du har direkte proporsjonal.
Og husk at du ikke logger sensitive data som e-post-ID, passord, kredittkortinformasjon og telefonnummer. Det er ikke bare en enorm sikkerhetsrisiko, men ofte ulovlig.
7. Vil søknaden skaleres?
Den verste tilnærmingen til applikasjonsutvikling er å tenke på hvordan man skalerer etter du får trafikk. I stedet bør du bygge en arkitektur som har muligheten til å vokse fra begynnelsen for å spare tid og øke produktiviteten.
Å spinne opp servere er ikke skalering; distribuere belastning på tvers av ressurser er. Dette betyr ikke at du ikke skal gyte nye servere når belastningen øker. Først bør du konfigurere lastbalansering innenfor dine nåværende ressurser for å håndtere den økte belastningen. Når lastbalanseringen ikke effektivt kan håndtere arbeidsmengden, er det på tide å begynne horisontal skalering og gyte nye servere. Du kan oppnå dette gjennom en uavhengig statsløs prosess eller via moduler. Hver prosess eller modul vil fungere på en isolert, uavhengig måte. Dette vil ikke bare hjelpe applikasjonen din til å skalere effektivt, men også gjøre systemet ditt feiltolerant og enkelt å gjenopprette.
Hvordan du strukturerer en webapplikasjon er like viktig som å velge riktig teknologi. Hvis grunnlaget er feil, vil applikasjonen til slutt krasje, eller nekte å skalere, eller i noen tilfeller ikke starte i det hele tatt. Ikke skynd deg med å utvikle nye funksjoner eller nye ideer uten riktig planlegging og arkitektur. Dårlig struktur eller arkitektur er som en tikkende tidsbombe som venter på å eksplodere.
New Tech Forum er et sted for å utforske og diskutere ny teknologi i enestående dybde og bredde. Valget er subjektivt, basert på vårt valg av teknologiene vi mener er viktige og av størst interesse for leserne. godtar ikke markedsføringssikkerhet for publisering og forbeholder seg retten til å redigere alt bidratt innhold. Send alle henvendelser til [email protected].
