Programovanie

Sedem kláves na štruktúrovanie vašej aplikácie Node.js.

Rahul Mhatre je technický architekt v spoločnosti Built.io.

Node.js rýchlo doháňa jazyky Java, Ruby, Python a .Net ako preferovaný jazyk pre vývoj nových webových aplikácií. Tím Node.js každým dňom zvyšuje skvalitnenie, zrýchlenie a stabilizáciu runtime jazyka JavaScript. A komunita používateľov rýchlo rastie.

Ako bude adopcia stále stúpať, čoraz viac vývojárov stúpa po krivke učenia Node.js, čelí podobným problémom a kóduje podobné funkcionality. Komunita Node.js našťastie prišla na pomoc s rámcami a návrhovými vzormi, ktoré nielenže riešia bežné problémy, ale pomáhajú aj pri štruktúrovaní aplikácií.

Rámec všeobecne implementuje vzory MV ako MVC (model-view-controller), MVVM (model-view-viewmodel), MVP (model-view-presenter) alebo iba MV. Tiež vám povedia, kde by mal byť kód pre modely, zobrazenia a ovládače, kde by mali byť vaše trasy a kam by ste mali pridať svoje konfigurácie. Mnoho mladých vývojárov a nadšencov Node.js skutočne nechápe, ako sa návrhové vzory alebo diagramy OOP (Object Oriented Programming) mapujú na riadky alebo štruktúru kódu v ich aplikácii.

To je miesto, kde prichádzajú na trh rámce Node.js ako Express.js a Sails.js. Tieto a mnoho ďalších je k dispozícii, aby pomohli naštartovať vývoj webových aplikácií. Bez ohľadu na rámec, ktorý používate, budete chcieť pri štruktúrovaní svojej aplikácie pamätať na určité aspekty.

Tu je sedem kľúčových bodov, o ktorých uvažujem pred mapovaním aplikácie Node.js.

1. Správna adresárová štruktúra aplikácie

Pri rozhodovaní o adresárovej štruktúre svojej aplikácie by ste mali brať do úvahy vybraný návrhový vzor. Pomôže to rýchlejšie sa prihlásiť, nájsť kód a izolovať problémy. Ja osobne uprednostňujem pri vytváraní aplikácie Node.js vzor MVC. Pomáha mi rýchlejšie sa rozvíjať, poskytuje flexibilitu pri vytváraní viacerých zobrazení pre rovnaké údaje a umožňuje vymenovať aspoň niektoré asynchrónnu komunikáciu a izoláciu medzi súčasťami MVC.

Rád sledujem vyššie uvedenú adresárovú štruktúru, ktorá je založená na kombinácii Ruby on Rails a Express.js.

Súvisiace video: Tipy a triky pre Node.js

V tomto vysvetľujúcom videu sa naučte niekoľko techník, ktoré môžu zlepšiť vaše skúsenosti s vývojom uzlov.

2. Mapovanie ER diagramov na modely

Ako je definované v dokumente Techopedia, „Diagram vzťahov medzi entitami (ERD) je technika modelovania údajov, ktorá graficky ilustruje entity informačného systému a vzťahy medzi týmito entitami.“ Schéma ER načrtáva rôzne entity, ktoré sa budú podieľať na našom systéme, a definuje všetky interakcie medzi nimi tak, aby:

  • Čokoľvek, čo je abstraktnou alebo fyzickou „vecou“, sa stáva entitou v modeli
  • Model sa namapuje na tabuľku v našej databáze
  • Atribút alebo vlastnosť entity sa premieta do atribútu modelu, ktorý je zase stĺpcom v tabuľke

Napríklad, ak je vašou entitou používateľ, zodpovedajúcim modelom by bol „Používateľ“ s atribútmi ako meno, priezvisko a adresa v databáze, ako aj zodpovedajúca tabuľka a stĺpce.

Vďaka jednoduchej dátovej architektúre je celkom jednoduché sledovať rast databázy a súborov vždy, keď sa vytvorí nová schéma.

3. Použitie vzoru MVP

Implementácia MVC neznamená iba vytváranie priečinkov pre radiče, zobrazenia a modely. Musíte tiež rozdeliť svoj kód a logiku podľa MVC. Kód vo vašich modeloch by mal byť striktne obmedzený na definície schémy databázy. Vývojári všeobecne zabúdajú, že modely budú mať aj kód, ktorý bude vykonávať operácie CRUD. V tomto súbore by mala byť tiež prítomná akákoľvek funkcia alebo operácia, ktorá je špecifická pre tento model. V tomto súbore by sa mala nachádzať väčšina obchodnej logiky súvisiacej s modelom.

Častou chybou je vyhodenie všetkej obchodnej logiky do radičov. Ovládače by mali vyvolávať iba funkcie z modelov alebo iných komponentov, prenášať údaje medzi komponentmi a riadiť tok žiadosti, zatiaľ čo priečinok zobrazenia by mal mať iba kód na prevod objektov do formy čitateľnej pre človeka. Vo vnútri pohľadu by sa nemali robiť žiadne logiky, ako je formátovanie údajov alebo triedenie alebo filtrácia. Udržiavanie čistoty pohľadov poskytne nielen lepší dojem používateľa, ale tiež vám pomôže zmeniť pohľady bez toho, aby ste zmenili akýkoľvek iný komponent.

4. Rozdelenie logiky na moduly

Ako vývojárom sa vždy hovorí, že by sme mali kód organizovať do súborov a modulov. To neznamená, že by sme sa mali pokúsiť umiestniť celú aplikáciu do jedného súboru. Najlepším prístupom je rozdelenie kódu na základe logiky a funkčnosti. Zoskupenie funkcií súvisiacich s jednou entitou alebo objektom do jedného súboru a usporiadanie adresárovej štruktúry na základe logiky má mnoho výhod. Najprv vám ušetrí veľa času určovaním, ktorej funkcie sa dotknúť, keď bude treba opraviť chybu. Po druhé, pomáha oddeliť všetky komponenty v architektúre, uľahčuje nahradenie diskrétnych funkcií bez potreby úpravy ďalších riadkov kódu. Po tretie, pomôže to aj pri písaní testovacích prípadov.

5. Dôležitosť testovacích prípadov

Pri vytváraní testovacích prípadov je veľmi dôležité nikdy nezastavovať rohy - testy sú strážcami vašej kódovej základne. S pribúdajúcimi aplikáciami je ťažšie zapamätať si všetky scenáre, ktoré musíte pri kódovaní zahrnúť. Testovacie prípady vám pomôžu udržať stabilnú vašu kódovú základňu. Testovanie zabraňuje regresii a šetrí drahocenný čas a úsilie potrebné na vývoj. Pomáha vám zabezpečiť, aby nové funkcie boli tlačené bezchybne. Pomáha tiež vylepšiť kvalitu kódu tým, že chyby zachytí skôr, ako sa dostanú do výroby. A čo je najdôležitejšie, testovanie pomáha vzbudiť dôveru v to, že sa kód nezrúti.

6. Dôležitosť guľatiny

Denníky sú užitočné na ladenie a porozumenie stavu vašej aplikácie. Poskytujú cenné poznatky o správaní sa aplikácie. Tu je rýchly zoznam vecí, na ktoré treba pamätať pri využívaní denníkov:

  • Nájdite správnu rovnováhu, pokiaľ ide o ťažbu dreva. Mať „príliš veľa informácií“ nie je nikdy zlé, ale nadmerné zaznamenávanie údajov vašu prácu iba sťaží. Ihly ľahšie nájdete v menších stohoch sena. Na druhej strane, nedostatočné protokolovanie bude mať za následok príliš málo informácií dostupných na ladenie alebo diagnostiku.
  • Rozdeľte svoje offline a online protokoly, pričom najnovšie protokoly sa ukladajú na rýchle načítanie a spracovanie, zatiaľ čo staršie protokoly sa archivujú alebo ukladajú do súborov.
  • Zvážte frekvenciu a trvanie svojich denníkov, pretože to ovplyvní veľkosť úložiska, ktoré budete potrebovať. Väčšinou je potrebné množstvo ukladacieho priestoru a počet protokolov, ktoré máte priamo úmerné.

Pamätajte, že si nezaznamenávajte citlivé údaje, ako sú e-mailové ID, heslá, informácie o kreditných kartách a telefónne čísla. Je to nielen obrovské bezpečnostné riziko, ale často aj nezákonné.

7. Bude škála žiadosti?

Najhorším prístupom k vývoju aplikácií je premýšľať o tom, ako škálovať po získate premávku. Namiesto toho by ste mali vytvoriť architektúru, ktorá má schopnosť od začiatku rásť, aby šetrila čas a zvyšovala produktivitu.

Otáčanie serverov sa nemení; rozloženie záťaže medzi zdroje je. To neznamená, že by ste sa nemali umiestňovať nové servery, keď sa záťaž zvýši. Najskôr by ste mali vo svojich súčasných zdrojoch nastaviť vyrovnávanie zaťaženia, aby ste zvládli zvýšené zaťaženie. Keď vyrovnávanie zaťaženia nedokáže efektívne zvládnuť pracovné zaťaženie, je čas začať s horizontálnym škálovaním a umiestniť nové servery. Môžete to dosiahnuť prostredníctvom nezávislého procesu bez štátnej príslušnosti alebo prostredníctvom modulov. Každý proces alebo modul bude pracovať izolovane a nezávisle. Pomôže to nielen efektívne škálovať vaše aplikácie, ale aj to, že váš systém bude odolný voči chybám a bude sa dať ľahko zotaviť.

To, ako štruktúrujete webovú aplikáciu, je rovnako dôležité ako výber správnej technológie. Ak sú základy chybné, aplikácia nakoniec spadne, alebo odmietne zmeniť jej veľkosť, alebo sa v niektorých prípadoch nespustí vôbec. Nikdy sa neponáhľajte s vývojom nových funkcií alebo nových nápadov bez správneho plánovania a architektúry. Zlá štruktúra alebo architektúra je ako tikajúca časovaná bomba, ktorá čaká na výbuch.

Nové technologické fórum poskytuje miesto na preskúmanie a diskusiu o vznikajúcich podnikových technológiách v nebývalej hĺbke a šírke. Výber je subjektívny, založený na našom výbere technológií, ktoré považujeme za dôležité a pre čitateľov najväčší záujem. neprijíma marketingové záruky na zverejnenie a vyhradzuje si právo upravovať všetok prispievaný obsah. Všetky otázky posielajte na adresu [email protected].

$config[zx-auto] not found$config[zx-overlay] not found