Въпросът
Клишето „забързано ежедневие“ ни преследва отвсякъде: телевизионните гурута ни препоръчват всеки ден да гледаме небето против депресия и уроки, а известните хора ни дават банални и ексцентрични рецепти за освобождаване от стреса и безкраен духовен релакс.
Не знаем дали „забързаното ежедневие“ е толкова драматичен проблем, но едно е сигурно: в света на софтуерните разработки ритъмът е убийствен. До момента в Глобал Консултинг смогваме, като непрекъснато променяме основните си корпоративни информационни системи. Стараем се да го правим в синхрон със световните тенденции, с нуждите на клиентите ни, с изграждащите блокове и, не на последно място, архитектурните ни принципи. Защото всеки инфлуенсър в Instagram ще ви потвърди, че следването на принципи е важна работа.
Така, като част от един естествен процес, преди около година и половина дойде моментът за пореден път да си отговорим на един екзистенциален въпрос:
Как да обновим технологичната пирамида, която използваме при разработката на уеб потребителски интерфейси?
Към този момент информационните системи на Глобал Консултинг, при които потребителският интерфейс е изграден като уеб приложение, бяха реализирани основно на базата на ASP.NET MVC и съпътстващите я технологии, или нещо подобно на следния технологичен куп:
Куп, който, въпреки нищожните промени, които е претърпял през последните 5 години, е служил добре не само на Глобал Консултинг и клиентите ни, но и на още много хора и компании по света.
Целите, които си поставихме
Целта ни беше да имаме набор от софтуерни инструменти и технологии, чрез които да можем да създаваме уеб базирани приложения, които да „мултитаскват“ на няколко нива:
Да отговарят на повишените изисквания на клиентите
За добро или лошо, клиентите стават все по-претенциозни. А ние се адаптираме, като правим потребителското изживяване по-богато, а екранните сценарии, реализирани с HTML5 и JavaScript, по-сложни. Инструментите и технологиите трябва да изглеждат добре на екрани с различна разделителна способност. Да са по-сигурни отвсякога. Да могат, за разлика от хората, да работят в режим 24/7 и да отговарят ефективно на пикове в активността на потребителското натоварване.
Да могат да се разполагат във виртуална и облачна инфраструктура
Очакваме от уеб приложенията да могат да работят както в ИТ инфраструктурата на клиентите ни, така и в облачна среда. Не, нямаме предвид среда, в която няма слънце и черните облаци вещаят градушка, а частен облак, изграден с виртуализационни средства или публична облачна услуга. Технологиите, използвани за изграждане на нашите уеб приложения, трябва да бъдат оптимизирани за високопроизводителна работа, в среда с ограничени и конкурентни ресурси.
Изискванията ни не стигат дотук. От уеб базираните приложения искаме още:
Платформата да не е тясно свързана с Windows
Microsoft Windows е супер, но за нас е важно уеб приложенията на Глобал Консултинг да могат да работят и върху Linux базирани сървъри, за да може да се възползваме от модерни схеми за разполагане на нашите приложения, например в Docker контейнери.
Да използваме в максимална степен досегашното know-how на екипа
Не че искаме да се хвалим прекомерно, но екипът ни има повече от 20-годишен опит в изграждането на информационни системи, въвеждането им в експлоатация, тяхното поддържане и развиване.
Съответно щеше да е скандално нецелесъобразно да пренебрегнем този опит и да започнем да се обучаваме отначало. Новите технологични инструменти, които щяхме да използваме, трябваше в максимална степен да стъпят на опита ни и да позволят сравнително плавно продължаване на поддръжката и развитието на вече съществуващите системи на Глобал Консултинг.
Решението
В решението ни имаше една лесна част, относно която нямахме притеснения, и една, която беше съпътствана от съмнения, почесване по главите и любопитство какво ще „изскочи от шапката“. Новите уеб приложения в Глобал Консултинг (и новите версии на съществуващи приложения), към днешна дата се реализират с използването на следните програмни инструменти:
Лесната част…
…беше преминаването към използването на ASP.NET Core.
Опитът ни за последната година и половина показа, че преходът е практически безпрепятствен. Процесът на работа си вървеше гладко и не открихме скрити капани по пътя. На фона на опита, който сме натрупали до този момент с .NET, ни трябваше съвсем малко „надграждане“, за да можем да използваме пълноценно възможностите и предимствата на .NET Core. От чисто програмистка гледна точка, няма никаква разлика дали кода на C# е насочен към .NET Core или към пълната .NET Framework.
Има някои софтуерни дизайн шаблони, чиято реализация дори се постига по-лесно при ASP.NET Core, отколкото с традиционното ASP.NET – като използването на “Clean” (Onion) многослойна архитектура, Dependency Injection и др. Това е така, защото тези дизайн шаблони са вградени на архитектурно ниво в новата версия на .NET.
Архитектурата на ASP.NET Core позволява приложението да се насочва за компилиране и изпълнение както към .NET Core, така и към пълната .NET Framework.
И в случай че вече сте изгубили нишката, нека отбележим какво се случи в резюме:
- Преходът към ASP.NET Core / .NET Core ни позволи да постигнем целите, които си бяхме поставили при отговора на въпроса от преди година и половина. Ако сте забравили за кой въпрос става дума, питахме се как да обновим технологичната пирамида, която използваме при разработката на уеб потребителски интерфейси
- Преходът е безболезнен, рутинен и твърде скучен, за да му се отделя повече място в един блог пост.
Интересната част…
…дойде от изоставянето от традиционни уеб приложения, при които почти цялата презентационна логика (потребителският интерфейс), която генерира HTML и JavaScript, заедно с бизнес логиката, се изпълняват на уеб сървъра. Реално всяко по-съществено потребителско действие генерира пълна заявка към уеб сървъра, където тя се обработва и връща HTML резултат към клиента, което по-често предизвиква пълно зареждане на цялата уеб страница в браузера. Да, възможно е да има отделни фрагменти от потребителския интерфейс, които обогатяват потребителското изживяване и работят изцяло в браузера с помощта на jQuery и AJAX заявки. Но те са малко или много изолирани, използването им е фрагментирано, и в един момент, когато тези фрагменти станат прекалено много, усилията за поддръжката и развитието им стават неоправдано големи.
От въпросните традиционни уеб приложения преминахме към…
…Single Page Applications (SPAs), при които презентационната логика се изпълнява изцяло в браузъра, а бизнес логиката се изпълнява на уеб сървъра. Това е придвижване с една стъпка напред, при практическата реализация на уеб приложения, на един от основните принципи на софтуерното инженерство – Separation of Concerns.
Обикновено при SPA приложенията има една статична начална страница (index.html), от която първоначално в клиентския браузър се зареждат всички необходими за функционирането на цялото уеб приложение JavaScript и CSS ресурси. В процеса на работа комуникацията между SPA приложението в браузъра и бизнес логиката на уеб сървъра се осъществява посредством JSON Web API заявки.
При тези уеб приложения, постигането на богато потребителско изживяване е заложено по подразбиране. То е интегрирано във framework-а, използван за разработката на приложението – всички потребителски елементи в страницата (HTML тагове и CSS) се създават и управляват динамично от JavaScript чрез манипулация на DOM-а в браузера. Добре е да отбележим, че усилията за поддръжката и развитието на богатия потребителския интерфейс са много по-малко отколкото при традиционния подход.
Angular? Какво е това?
Към днешна дата, когато се говори за разработка на уеб приложения като SPA, най-често се визират React, Angular и VueJS. Тази тема може да придобие размерите на апокалиптичен скандал сред по-страстните привърженици на едната или другата технология. Дори бихме казали, че Angular VS React VS Vue JS е нещо като съвременната, IT версия на враждата между Монтеки срещу Капулети…Или Левски срещу ЦСКА, ако повече ви харесва. Онлайн може да срещнете някои интересни мемета и картинки по темата 😊
Ние няма да участвамe в този спор, поне не и в този блог пост.
Тук само ще споделим нашите мотиви да се спрем на Angular.
Angular е пълен Framework за разработка на SPA
В него изначално е включено всичко (или почти всичко), което ви е необходимо за разработка на пълни SPA уеб приложения – MVC engine, HTTP Client, Routing, строга и ясно дефинирана система за използването на модули, собствена UI библиотека – Angular Material, Angular Flex Layout, собствено множество от клиентски инструменти за ползване от разработчиците др.
Да, в сравнение с други технологии може да е малко „по-тежък“, но все пак целта ни не е да носим раница в планината, а да разработваме, развиваме и поддържаме корпоративни уеб приложения (сравнително големи и сами по себе си „тежки“ уеб приложения). В този смисъл за нас това е точният инструмент.
Angular и известни софтуерни дизайн шаблони
Angular споделя много от софтуерните дизайн шаблони познати на програмисти с background ASP.NET MVC / ASP.NET Core и други обектно-ориентирани framework-ци. Например:
Споменатото вече Model-View-Controller. При всеки един Angular компонент имаме разделение на HTML шаблон и програмен код на компонента написан на TypeScript и отделни класове с Data модели, описани също така с TypeScript.
TypeScript
TypeScript е много адекватен начин да сложим ред, познат ни от обектно-ориентираните езици, в JavaScript! Макар да е възможно за хора, които нямат background в C# или Java, нещата да не изглеждат точно по този начин 😊.
В Angular изначално е силно застъпено използването на софтуерни услуги, dependency injection, модули.
Angular използва свежата библиотека RxJS, за да постигне високо ниво на реактивност при взаимодействието между отделните компоненти и при динамичното обменяне на информация между тях.
Angular – Google технология и не само…
Зад Angular, зад целия framework, с всичките му основни компоненти, стои един от съвременните гиганти в софтуерната индустрия – Google, с ясно изразена позиция да поддържа и развива технологията. Това е важен фактор, когато трябва да се избира инструмент за реализацията на корпоративна софтуерна система, която от своя страна също трябва да се поддържа и развива в един сравнително дълъг период.
Отделно друг съвременен софтуерен гигант – Microsoft, показва ясен ангажимент за подкрепа на Angular framework-а в свои технологии. Както в TypeScript, така и във възможността за интеграция на Angular SPA в технологичния стек на ASP.NET Core.
Иначе казано, с Angular се подсигуряваме на два фронта, и двата – достатъчно надеждни.
Angular e догматичен (opinionated) framework
Догматичен, защото с него няма как да правите каквото си искате. Когато става дума за Angular framework-а „има истина една, и тя е такава, каквато са я разказали от Google“. Тоест има ясен набор от правила и добри практики, които са дефинирани от разработчика на framework-а, и когато програмистите програмират на Angular трябва да ги следват. Точка. The end. Point finale.
Ако този подход не ви харесва или конкретните правила и практики, дефинирани от Google не ви допадат, Angular най-вероятно не е вашият SPA framework и трябва да се ориентирате към нещо друго, с което да си проектирате сауните (отново „ха-ха“).
Документацията на целия framework е много добра, обширна, поддържа се на едно място и се обновява своевременно спрямо промените на версиите на самия framework.
Все значими фактори, когато имате екип от програмисти, които трябва да работят по поддръжката и развитието на няколко корпоративни информационни системи и за които е императивно да спазват единен набор от практики при разработката и поддръжката на софтуера.
Предизвикателства
В ретроспекция, единственото по-сериозно предизвикателство, което срещнахме в Глобал Консултинг при прехода ни към използването на Angular, беше етапът на първоначалното запознаване на екипа с framework-а.
Всеки от нас, който до момента не се беше срещал в практиката си със SPA библиотеки, трябваше да отдели време, за да премине обучение по Angular. За щастие, в интернет има достатъчно ресурси под формата на курсове, а и както беше споменато по-горе, документацията за Angular е доста пълна и добра. A и тъй като обаче сме способни, схватливи и скромни професионалисти, нещата се случиха гладко и без особени катаклизми.