Rahuls Matre ir Built.io tehniskais arhitekts.
Node.js ātri panāk Java, Ruby, Python un .Net kā vēlamo valodu jaunu tīmekļa lietojumprogrammu izstrādei. Node.js komanda ar katru dienu padara JavaScript izpildlaiku labāku, ātrāku un stingrāku. Lietotāju kopiena ar strauju klipu palielinās.
Tā kā adopcija turpina pieaugt, arvien vairāk izstrādātāju pakāpsies Node.js mācīšanās līknē, saskaroties ar līdzīgām problēmām un kodējot līdzīgas funkcijas. Par laimi, kopiena Node.js ir nākusi talkā ar ietvariem un dizaina modeļiem, kas ne tikai atrisina izplatītās problēmas, bet arī palīdz lietojumprogrammu strukturēšanā.
Rāmjos parasti tiek ieviesti MV modeļi, piemēram, MVC (modeļa skata-kontrolieris), MVVM (modeļa-skata-skata modelis), MVP (modeļa-skata-prezentētāja) vai tikai MV. Viņi arī norāda, kur jābūt modeļu, skatu un kontrolieru kodam, kur jābūt jūsu maršrutiem un kur jāpievieno konfigurācijas. Daudzi jaunie izstrādātāji un Node.js entuziasti īsti nesaprot, kā dizaina modeļi vai OOP (Object Oriented Programming) diagrammas piesaista koda līnijas vai struktūru viņu lietojumprogrammā.
Tieši šeit parādās Node.js ietvari, piemēram, Express.js un Sails.js. Šie un daudzi citi ir pieejami, lai palīdzētu sākt tīmekļa lietojumprogrammu attīstību. Neatkarīgi no izmantotā ietvara, strukturējot lietotni, vēlēsities paturēt prātā dažus apsvērumus.
Šeit ir septiņi galvenie punkti, kurus es apsvēru pirms Node.js lietojumprogrammas kartēšanas.
1. Pareizā direktorijas struktūra lietotnei
Izlemjot par savas lietotnes direktoriju struktūru, jums jāņem vērā izvēlētais noformējuma modelis. Tas palīdzēs ātrāk iekāpšanai, koda atrašanā un problēmu izolēšanā. Es personīgi gribētu izmantot MVC modeli, veidojot Node.js lietotni. Tas palīdz man attīstīties ātrāk, nodrošina elastību, lai izveidotu vairākus skatus vieniem un tiem pašiem datiem, kā arī ļauj asinhronu komunikāciju un izolāciju starp MVC komponentiem.
Man patīk sekot iepriekš parādītajai direktoriju struktūrai, kuras pamatā ir Ruby on Rails un Express.js kombinācija.
Saistītais video: Node.js padomi un ieteikumi
Šajā paskaidrojuma videoklipā uzziniet vairākas metodes, kas var uzlabot jūsu mezglu izstrādes pieredzi.
2. ER diagrammu kartēšana ar modeļiem
Kā definēts Techopedia, “Entītiju un attiecību diagramma (ERD) ir datu modelēšanas tehnika, kas grafiski ilustrē informācijas sistēmas entītijas un attiecības starp šīm entītijām.” ER diagrammā ir izklāstītas dažādas entītijas, kas piedalīsies mūsu sistēmā, un tiek definēta visa mijiedarbība starp tām:
- Viss, kas ir abstrakta vai fiziska “lieta”, kļūst par modeļa entītiju
- Modelis kartē tabulu mūsu datu bāzē
- Entītijas atribūts vai rekvizīts tiek pārveidots par modeļa atribūtu, kas savukārt ir kolonna tabulas iekšpusē
Piemēram, ja jūsu entītija ir lietotājs, tad atbilstošais modelis būtu “Lietotājs” ar tādiem atribūtiem kā vārds_vārds, uzvārds un adrese datu bāzē, kā arī atbilstošu tabulu un kolonnām.
Izmantojot vienkāršu datu arhitektūru, ir diezgan vienkārši izsekot datu bāzes un failu pieaugumam jebkurā laikā, kad tiek izveidota jauna shēma.
3. Izmantojot MVP modeli
MVC ieviešana nenozīmē tikai mapju izveidošanu kontrolieriem, skatiem un modeļiem. Jums arī jāsadala kods un loģika atbilstoši MVC. Jūsu modeļos esošajam kodam jābūt stingri ierobežotam ar datu bāzes shēmas definīcijām. Izstrādātāji parasti aizmirst, ka modeļiem būs arī kods, kas veiks CRUD darbības. Arī failā ir jābūt jebkurai funkcijai vai operācijai, kas raksturīga šim modelim. Lielākajai daļai ar modeli saistītās biznesa loģikas vajadzētu būt šajā failā.
Bieža kļūda ir visa biznesa loģika izgāšana kontrolieros. Kontrolieriem vajadzētu izsaukt tikai modeļu vai citu komponentu funkcijas, pārsūtīt datus starp komponentiem un kontrolēt pieprasījuma plūsmu, turpretī skata mapē jābūt tikai kodam, lai objektus pārveidotu cilvēkiem lasāmā formā. Skata iekšpusē nedrīkst veikt nekādu loģiku, piemēram, datu formatēšanu vai šķirošanu vai filtrēšanu. Skatu tīrība nodrošinās ne tikai labāku lietotāja pieredzi, bet arī palīdzēs mainīt skatus, nemainot nevienu citu komponentu.
4. Loģikas sadalīšana moduļos
Kā izstrādātājiem mums vienmēr saka, ka mums jāorganizē kods failos un moduļos. Tas nenozīmē, ka mums vajadzētu mēģināt visu lietotni ievietot vienā failā. Labākā pieeja ir koda sadalīšana, pamatojoties uz loģiku un funkcionalitāti. Funkciju, kas saistītas ar vienu entītiju vai objektu, grupēšanai vienā failā un direktoriju struktūras organizēšanai, pamatojoties uz loģiku, ir daudz priekšrocību. Pirmkārt, tas ietaupīs daudz laika, nosakot, kurai funkcijai pieskarties, ja ir jānovērš kļūda. Otrkārt, tas palīdz atdalīt visus arhitektūras komponentus, veicinot diskrētas funkcionalitātes nomaiņu bez nepieciešamības modificēt citas koda rindas. Treškārt, tas arī palīdzēs rakstīt pārbaudes lietas.
5. Pārbaudes gadījumu nozīme
Veidojot pārbaudes gadījumus, ir ļoti svarīgi nekad negriezt stūrus - testi ir jūsu kodu bāzes sargi. Palielinoties lietojumprogrammai, kļūst grūtāk atcerēties visus scenārijus, kas jāaptver kodēšanas laikā. Pārbaudes gadījumi palīdz saglabāt koda bāzes stabilitāti. Testēšana novērš regresiju, ietaupot vērtīgu izstrādes laiku un pūles. Tas palīdz jums nodrošināt, ka jaunās funkcijas tiks pārvietotas bez kļūdām. Tas arī palīdz uzlabot koda kvalitāti, nozvejojot kļūdas, pirms tās nonāk ražošanā. Un pats galvenais, testēšana palīdz radīt pārliecību, ka kods neizdosies.
6. Baļķu nozīme
Žurnāli ir noderīgi, lai atkļūdotu un izprastu lietojumprogrammas stāvokli. Tie sniedz vērtīgu ieskatu par lietotnes darbību. Šeit ir īss saraksts ar lietām, kas jāpatur prātā, izmantojot saražotos žurnālus.
- Atrodiet pareizo līdzsvaru mežizstrādes jomā. Ja jums ir “pārāk daudz informācijas”, nekad nav slikti, bet pārmērīga mežizstrāde tikai padarīs jūsu darbu grūtāku. Adatas ir vieglāk atrast mazākos siena kaudzēs. No otras puses, nepietiekama reģistrēšanās rezultātā būs pieejams pārāk maz informācijas, lai atkļūdotu vai diagnosticētu.
- Sadaliet bezsaistes un tiešsaistes žurnālus, kur jaunākie žurnāli tiek glabāti ātrai izgūšanai un apstrādei, savukārt vecākie žurnāli tiek arhivēti vai ievietoti failos.
- Apsveriet savu žurnālu biežumu un ilgumu, jo tas ietekmēs nepieciešamo krātuves apjomu. Vajadzīgās krātuves apjoms un reģistrēto žurnālu skaits visbiežāk ir tieši proporcionāls.
Un atcerieties, nepierakstiet sensitīvus datus, piemēram, e-pasta ID, paroles, kredītkartes informāciju un tālruņa numurus. Tas ir ne tikai milzīgs drošības risks, bet arī bieži nelegāls.
7. Vai pieteikuma skala?
Sliktākā pieeja lietojumprogrammu izstrādei ir domāt par to, kā mērogot pēc jūs saņemat satiksmi. Tā vietā jums vajadzētu izveidot arhitektūru, kurai ir iespējas augt jau no paša sākuma, lai ietaupītu laiku un palielinātu produktivitāti.
Serveru paplašināšana nav mērogošana; slodzes sadalīšana pa resursiem ir. Tas nenozīmē, ka, palielinoties slodzei, nevajadzētu radīt jaunus serverus. Pirmkārt, jums jāiestata slodzes līdzsvarošana pašreizējos resursos, lai tiktu galā ar palielinātu slodzi. Kad slodzes līdzsvarošana nespēj efektīvi pārvaldīt slodzi, ir pienācis laiks sākt horizontālu mērogošanu un radīt jaunus serverus. To var panākt, izmantojot neatkarīgu bezvalstnieku procesu vai moduļus. Katrs process vai modulis darbosies izolēti, neatkarīgi. Tas ne tikai palīdzēs efektīvi palielināt lietojumprogrammas mērogu, bet arī padarīs jūsu sistēmu izturīgu pret kļūdām un viegli atjaunojamu.
Tīmekļa lietojumprogrammas strukturēšana ir tikpat svarīga kā pareizās tehnoloģijas izvēle. Ja pamati ir kļūdaini, lietojumprogramma galu galā sabruks vai atteiksies veikt mērogošanu vai dažos gadījumos to vispār neizdosies palaist. Nekad nesteidzieties ar jaunu funkciju vai jaunu ideju izstrādi bez pienācīgas plānošanas un arhitektūras. Slikta struktūra vai arhitektūra ir kā atzīmējama laika bumba, kas gaida eksplodēšanu.
Jauno tehnoloģiju forums nodrošina vietu, kur bezprecedenta dziļumā un plašumā izpētīt un pārrunāt topošās uzņēmuma tehnoloģijas. Izvēle ir subjektīva, balstoties uz mūsu izvēlētajām tehnoloģijām, kuras, mūsuprāt, ir svarīgas un interesē lasītājus. nepieņem mārketinga nodrošinājumu publicēšanai un patur tiesības rediģēt visu ieguldīto saturu. Nosūtiet visus jautājumus uz [email protected].
