7 клавиша за структуриране на вашето приложение Node.js

Rahul Mhatre е технически архитект в Built.io.

Node.js настига бързо Java, Ruby, Python и .Net като предпочитан език за разработване на нови уеб приложения. Екипът на Node.js прави времето за изпълнение на JavaScript по-добро, по-бързо и по-стабилно с всеки изминал ден. А потребителската общност нараства бързо.

Тъй като приемането продължава да расте, все повече и повече разработчици ще се изкачат по кривата на обучение Node.js, изправяйки се пред подобни проблеми и кодирайки подобни функционалности. За щастие общността Node.js се притича на помощ с рамки и дизайнерски модели, които не само решават често срещани проблеми, но и помагат в структурирането на приложения.

Рамките обикновено прилагат MV модели като MVC (модел-view-controller), MVVM (model-view-viewmodel), MVP (model-view-презентатор) или просто MV. Те също така ви казват къде трябва да бъде кодът за модели, изгледи и контролери, къде трябва да бъдат вашите маршрути и къде трябва да добавите своите конфигурации. Много млади разработчици и ентусиасти на Node.js всъщност не разбират как схемите на проектиране или диаграмите на OOP (обектно ориентирано програмиране) се свързват с линиите или структурата на кода в тяхното приложение.

Това е мястото, където се появяват Node.js рамки като Express.js и Sails.js. Те и много други са на разположение, за да стартират разработването на уеб приложения. Независимо от рамката, която използвате, ще искате да имате предвид някои съображения, когато структурирате приложението си.

Ето седемте ключови точки, които обмислям, преди да картографирам приложението Node.js.

1. Правилната структура на директорията за приложението

Докато решавате структурата на директориите за вашето приложение, трябва да вземете предвид избрания от вас модел на проектиране. Това ще помогне за по-бързо включване, намиране на код и изолиране на проблеми. Аз лично предпочитам да използвам MVC модел, докато създавам приложение Node.js. Помага ми да се развивам по-бързо, осигурява гъвкавост за създаване на множество изгледи за едни и същи данни и позволява асинхронна комуникация и изолация между компонентите на MVC, за да назовем само няколко.

Обичам да следвам структурата на директориите, показана по-горе, която се основава на комбинация от Ruby on Rails и Express.js.

Свързано видео: Node.js съвети и трикове

В това обяснително видео научете няколко техники, които могат да подобрят вашия опит за разработка на Node.

2. Картографиране на ER диаграми към модели

Както е дефинирано в Techopedia, „Диаграма на връзката между обекта (ERD) е техника за моделиране на данни, която илюстрира графично обектите на информационната система и връзките между тези обекти.“ Една диаграма очертава различните обекти, които ще участват в нашата система, и определя всички взаимодействия между тях, така че:

  • Всичко, което е абстрактно или физическо „нещо“, се превръща в обект в модел
  • Модел се съпоставя с таблица в нашата база данни
  • Атрибут или свойство на обект се превежда в атрибут на модел, който от своя страна е колона в таблица

Например, ако вашият обект е потребител, тогава съответният модел ще бъде „Потребител“ с атрибути като първо име, фамилия и адрес вътре в базата данни, както и съответна таблица и колони.

Използването на проста архитектура на данните прави доста лесно проследяването на вашата база данни и растежа на файлове по всяко време, когато се създава нова схема.

3. Използване на шаблона MVP

Внедряването на MVC не означава просто създаване на папки за контролери, изгледи и модели. Също така трябва да разделите кода и логиката си според MVC. Кодът във вашите модели трябва да бъде строго ограничен до дефиниции на схеми на база данни. Разработчиците обикновено забравят, че моделите също ще имат код, който ще изпълнява CRUD операции. Също така, всяка функция или операция, които са специфични за този модел, трябва да присъстват в този файл. По-голямата част от бизнес логиката, свързана с даден модел, трябва да бъде в този файл.

Често срещана грешка е изхвърлянето на цялата бизнес логика в контролери. Контролерите трябва да извикват само функции от модели или други компоненти, да прехвърлят данни между компоненти и да контролират потока на заявката, докато папката за изглед трябва да има само код за конвертиране на обекти в четлива от човека форма. В рамките на изгледа не трябва да се прави логика като форматиране на данни или сортиране или филтриране. Поддържането на изгледите чисти не само ще осигури по-добро потребителско изживяване, но и ще ви помогне да промените изгледите, без да променяте други компоненти.

4. Разбиване на логиката на модули

Като разработчици винаги ни се казва, че трябва да организираме кода във файлове и модули. Това не означава, че трябва да се опитаме да поберем цялото приложение в един файл. Разделянето на вашия код въз основа на логика и функционалност е най-добрият подход. Групирането на функции, свързани с един обект или обект, в един файл и организирането на структурата на директориите въз основа на логиката има много предимства. Първо, това ще спести много време при определяне на коя функция да се докосне, когато трябва да се поправи грешка. Второ, помага да се отделят всички компоненти в архитектурата, улеснявайки замяната на дискретна функционалност, без да е необходимо да се модифицират други редове код. Трето, това също ще помогне при написването на тестови казуси.

5. Значението на тестовите случаи

Много е важно никога да не изрязвате ъгли, когато изграждате тестови случаи - тестовете са пазителите на вашата кодова основа. С нарастването на приложението ви става по-трудно да запомните всички сценарии, които трябва да покриете, докато кодирате. Тестовите случаи ви помагат да поддържате стабилна базата на кодовете си. Тестването предотвратява регресията, спестявайки ценно време и усилия за разработка. Помага ви да гарантирате, че новите функции ще бъдат изтласкани без грешки. Той също така помага за подобряване на качеството на кода, като улавя грешки, преди да тръгнат към продукцията. И най-важното, тестването помага да се вдъхне увереност, че кодът няма да се срине.

6. Значението на дневниците

Дневниците са полезни за отстраняване на грешки и разбиране на състоянието на вашето приложение. Те предоставят ценна информация за поведението на приложението. Ето кратък списък на нещата, които трябва да имате предвид, когато използвате лога:

  • Намерете правилния баланс, когато става въпрос за регистриране. Наличието на „твърде много информация“ никога не е лошо, но прекомерното регистриране само ще затрудни работата ви. Иглите са по-лесни за намиране в по-малки купа сено. От друга страна, недостатъчното регистриране ще доведе до твърде малко налична информация за отстраняване на грешки или диагностика.
  • Разделете вашите офлайн и онлайн дневници, като най-новите регистрационни файлове се съхраняват за бързо извличане и обработка, докато по-старите регистрационни файлове се архивират или изхвърлят във файлове.
  • Помислете за честотата и продължителността на вашите дневници, тъй като това ще повлияе на количеството място за съхранение, от което се нуждаете. Повечето пъти количеството съхранение, от което се нуждаете, и броят на дневниците, които имате, са право пропорционални.

И не забравяйте, не регистрирайте чувствителни данни като имейл имена, пароли, информация за кредитни карти и телефонни номера. Това е не само огромен риск за сигурността, но често и незаконно.

7. Ще скалира ли приложението?

Най-лошият подход към разработването на приложения е да помислите как да мащабирате, след като спечелите трафик. Вместо това трябва да изградите архитектура, която има способността да расте от самото начало, за да спести време и да повиши производителността.

Въртенето на сървъри не е мащабиране; разпределението на товара между ресурсите е. Това не означава, че не трябва да създавате нови сървъри, когато натоварването се увеличи. Първо, трябва да настроите балансиране на натоварването в рамките на текущите си ресурси, за да се справите с увеличения товар. Когато балансирането на натоварването не може ефективно да управлява натоварването, е време да започнете хоризонтално мащабиране и да създадете нови сървъри. Можете да постигнете това чрез независим процес без гражданство или чрез модули. Всеки процес или модул ще работи по изолиран, независим начин. Това не само ще помогне ефективно на мащаба на вашето приложение, но също така ще направи системата ви устойчива на грешки и лесно да се възстанови.

Начинът, по който структурирате уеб приложение, е толкова важен, колкото и изборът на правилната технология. Ако основите са дефектни, приложението в крайна сметка ще се срине или ще откаже да мащабира или в някои случаи изобщо не може да стартира. Никога не бързайте с разработването на нови функции или нови идеи без подходящо планиране и архитектура. Лошата структура или архитектура е като тиктакаща бомба със закъснител, която чака да експлодира.

Форумът New Tech предоставя място за изследване и обсъждане на нововъзникващите корпоративни технологии в безпрецедентна дълбочина и широчина. Изборът е субективен, базиран на нашия избор на технологиите, които смятаме, че са важни и представляват най-голям интерес за читателите. не приема маркетингово обезпечение за публикуване и си запазва правото да редактира цялото съдържание. Изпращайте всички запитвания на [email protected]