Programování

7 klíčů ke strukturování vaší aplikace Node.js.

Rahul Mhatre je technický architekt v Built.io.

Node.js rychle dohánějí jazyk Java, Ruby, Python a .Net jako preferovaný jazyk pro vývoj nových webových aplikací. Tým Node.js s každým dalším dnem dělá běh JavaScriptu lepším, rychlejším a pevnějším. A komunita uživatelů rychle roste.

Jak adopce stále roste, stále více vývojářů bude stoupat po křivce učení Node.js, bude čelit podobným problémům a kódování podobných funkcí. Naštěstí komunita Node.js přišla na pomoc s rámci a návrhovými vzory, které nejenže řeší běžné problémy, ale také pomáhají při strukturování aplikací.

Rámečky obecně implementují vzory MV, jako je MVC (model-view-controller), MVVM (model-view-viewmodel), MVP (model-view-presenter) nebo jen MV. Také vám řeknou, kde by měl být kód pro modely, pohledy a řadiče, kde by měly být vaše trasy a kam byste měli přidat své konfigurace. Mnoho mladých vývojářů a nadšenců Node.js opravdu nechápe, jak se návrhové vzory nebo diagramy OOP (Object Oriented Programming) mapují na řádky nebo strukturu kódu v jejich aplikaci.

To je místo, kde přicházejí rámce Node.js jako Express.js a Sails.js. Tyto a mnoho dalších jsou k dispozici, aby pomohly nastartovat vývoj webových aplikací. Bez ohledu na rámec, který používáte, budete chtít mít na paměti určité úvahy při strukturování aplikace.

Tady je sedm klíčových bodů, které uvažuji před mapováním aplikace Node.js.

1. Správná adresářová struktura aplikace

Při rozhodování o adresářové struktuře vaší aplikace byste měli vzít v úvahu návrhový vzor, ​​který jste vybrali. Pomůže to s rychlejším připojením, vyhledáním kódu a izolací problémů. Osobně dávám přednost použití vzoru MVC při vytváření architektury aplikace Node.js. Pomáhá mi rychleji se rozvíjet, poskytuje flexibilitu pro vytváření více pohledů pro stejná data a umožňuje jmenovat několik asynchronní komunikace a izolace mezi součástmi MVC.

Rád sleduji výše uvedenou adresářovou strukturu, která je založena na kombinaci Ruby on Rails a Express.js.

Související video: Tipy a triky Node.js

V tomto vysvětlujícím videu se naučte několik technik, které mohou zlepšit vaše zkušenosti s vývojem uzlů.

2. Mapování ER diagramů na modely

Jak je definováno v Techopedia, „Diagram vztahů mezi entitami (ERD) je technika modelování dat, která graficky ilustruje entity informačního systému a vztahy mezi těmito entitami.“ Diagram ER nastiňuje různé entity, které se budou účastnit našeho systému, a definuje všechny interakce mezi nimi tak, že:

  • Cokoli, co je abstraktní nebo fyzická „věc“, se stává entitou v modelu
  • Model se mapuje na tabulku v naší databázi
  • Atribut nebo vlastnost entity se převádí na atribut modelu, což je zase sloupec uvnitř tabulky

Pokud je vaše entita například uživatelem, pak by odpovídajícím modelem byl „Uživatel“ s atributy, jako je křestní jméno, příjmení a adresa v databázi, jakož i odpovídající tabulka a sloupce.

Díky jednoduché datové architektuře je docela snadné sledovat růst databáze a souborů kdykoli je vytvořeno nové schéma.

3. Použití vzoru MVP

Implementace MVC neznamená jen vytváření složek pro řadiče, pohledy a modely. Musíte také rozdělit svůj kód a logiku podle MVC. Kód uvnitř vašich modelů by měl být přísně omezen na definice schématu databáze. Vývojáři obecně zapomínají, že modely budou mít také kód, který bude provádět operace CRUD. V tomto souboru by měla být také přítomna jakákoli funkce nebo operace, která je specifická pro daný model. V tomto souboru by měla být většina obchodní logiky související s modelem.

Častou chybou je vysypávání veškeré obchodní logiky do řadičů. Řadiče by měly vyvolat pouze funkce z modelů nebo jiných komponent, přenášet data mezi komponentami a řídit tok požadavku, zatímco složka zobrazení by měla mít pouze kód pro převod objektů do formy čitelné člověkem. V pohledu by se neměla provádět žádná logika, jako je formátování dat nebo třídění či filtrace. Udržování čistých pohledů poskytne nejen lepší uživatelský komfort, ale také vám pomůže změnit pohledy beze změny jakékoli jiné komponenty.

4. Rozdělení logiky do modulů

Jako vývojářům se vždy říká, že bychom měli organizovat kód do souborů a modulů. To neznamená, že bychom se měli pokusit umístit celou aplikaci do jednoho souboru. Nejlepším přístupem je rozdělení kódu na základě logiky a funkčnosti. Seskupování funkcí souvisejících s jednou entitou nebo objektem do jednoho souboru a organizování adresářové struktury založené na logice má mnoho výhod. Nejprve to ušetří spoustu času určováním, které funkce se dotknout, když je třeba opravit chybu. Za druhé, pomáhá oddělit všechny komponenty v architektuře, což usnadňuje nahrazení diskrétních funkcí bez nutnosti úpravy dalších řádků kódu. Za třetí, pomůže také při psaní testovacích případů.

5. Význam testovacích případů

Při vytváření testovacích případů je velmi důležité nikdy nezkroutit - testy jsou strážci vaší kódové základny. Jak vaše aplikace roste, je těžší si zapamatovat všechny scénáře, které musíte pokrýt při kódování. Testovací případy vám pomohou udržet stabilní vaši kódovou základnu. Testování zabraňuje regresi a šetří cenný čas a úsilí při vývoji. Pomůže vám zajistit, že nové funkce budou bezchybně tlačeny. Pomáhá také zlepšit kvalitu kódu tím, že zachytí chyby dříve, než přejdou do výroby. A co je nejdůležitější, testování pomáhá vzbudit důvěru v to, že kód nepadne.

6. Důležitost kulatiny

Protokoly jsou užitečné k ladění a porozumění stavu vaší aplikace. Poskytují cenné poznatky o chování aplikace. Zde je rychlý seznam věcí, na které je třeba při používání protokolů pamatovat:

  • Najděte správnou rovnováhu, pokud jde o protokolování. Mít „příliš mnoho informací“ není nikdy špatné, ale nadměrné protokolování vaši práci jen ztěžuje. Jehly lze snáze najít v menších kupách sena. Na druhou stranu bude nedostatečné protokolování mít za následek příliš málo informací k ladění nebo diagnostice.
  • Rozdělte své offline a online protokoly, přičemž nejnovější protokoly jsou uchovány pro rychlé načtení a zpracování, zatímco starší protokoly jsou archivovány nebo uloženy do souborů.
  • Zvažte frekvenci a dobu trvání vašich protokolů, protože to ovlivní velikost úložiště, které budete potřebovat. Většinou je velikost požadovaného úložiště a počet protokolů přímo úměrná.

Nezapomeňte, že nezaznamenávejte citlivá data, jako jsou e-mailová ID, hesla, informace o kreditní kartě a telefonní čísla. Není to jen obrovské bezpečnostní riziko, ale často ilegální.

7. Bude měřítko aplikace?

Nejhorším přístupem k vývoji aplikací je přemýšlet o tom, jak škálovat po získáte provoz. Místo toho byste měli vytvořit architekturu, která má schopnost růst od začátku, aby šetřila čas a zvyšovala produktivitu.

Otáčení serverů není měřítko; distribuce zátěže mezi zdroje je. To neznamená, že byste neměli vytvářet nové servery, když se zatížení zvýší. Nejprve byste měli nastavit vyrovnávání zátěže v rámci svých současných prostředků, abyste zvládli zvýšené zatížení. Když vyvažování zátěže nemůže efektivně spravovat pracovní zátěž, je čas začít s horizontálním škálováním a vytvářet nové servery. Toho lze dosáhnout prostřednictvím nezávislého procesu bez státní příslušnosti nebo prostřednictvím modulů. Každý proces nebo modul bude fungovat izolovaným a nezávislým způsobem. To pomůže nejen efektivně škálovat vaši aplikaci, ale také zajistí, že váš systém bude odolný vůči chybám a snadno se obnoví.

Struktura webové aplikace je stejně důležitá jako výběr správné technologie. Pokud jsou základy chybné, aplikace se nakonec zhroutí nebo odmítne škálovat nebo se v některých případech vůbec nespustí. Nikdy se nepokoušejte vyvíjet nové funkce nebo nové nápady bez řádného plánování a architektury. Špatná struktura nebo architektura je jako tikající časovaná bomba, která čeká na výbuch.

Nové technologické fórum poskytuje místo, kde můžete prozkoumat a diskutovat o nově vznikajících podnikových technologiích v nebývalé hloubce a šíři. Výběr je subjektivní, založený na našem výběru technologií, které považujeme za důležité a pro čtenáře nejzajímavější. nepřijímá marketingové materiály ke zveřejnění a vyhrazuje si právo upravovat veškerý přispěný obsah. Všechny dotazy zasílejte na [email protected].

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