Як я здобув досвід в чотирьох технологіях протягом двох місяців

Преамбула

Протягом останніх п'яти років я працюю бекенд-розробником. Мені подобається вишуканий дизайн та продумана ужитковність програмних виробів, але ще більше мені подобається вдихати в них справжнє життя, втілюючи їхні бекенд-здатності. Мої пізнання технологій фронтенду обмежувалося ASP.NET MVC, html, css/bootstrap та javascript/jquery.

Деякий час тому мені випало попрацювати над цікавою задачею — дослідити можливості технології, яка зветься SignalR, з прицілом на потенційне впровадження в продукті, який розробляється нашою компанією. Впровадження SignalR передбачає розробкуз бекенд-частини, що зветься "хабом", та фронтенд-клієнта, який може бути доданий в застосунок будь-якого типу — веб, мобільного чи десктопного. Щоб зробити своє дослідження більш ґрунтовним, я вирішив створити кілька різних простих клієнтів, що дозволило би спостерігати їхню взаємодію та побачити, як SignalR розподіляє повідомлення для різних користувачів на різних клієнтах. Розпочав я з примітивного консольного клієнта і, зрештою, закінчив ще двома веб-клієнтами, які побудовані на React та Blazor технологіях, та десктоп-клієнті, побудованому на WPF.

Вкотре я відчув задоволення від того, що маю підписку на Pluralsight. Завдяки цій освітній платформі з тисячами курсів, я здобув загальне розуміння цих фреймворків протягом лічених днів. Звичайно, деяки речі довелося пропрацьовувати окремо, особливо в галузі автентифікації/авторизації у Azure Entra Id (в минулому Azure Ad), але всі ці складнощі зрештою були подолані.

Отже, що я можу сказати в підсумку цього дослідження?

І React, і Blazor були започатковані гігантами IT-галузі Facebook та Microsoft як внутрішні проєкти, які пізніше були виставлені на широкий загал як повнофінкціональні фреймворки для фронтенд-розробки. В мене практично не виникло складнощів з впровадженням потрібних мені здатностей в застосунках, написаних на кожному з них — це підключення до SignalR-хабу та додавання аутентифікації/авторизації Entra Id. І React, і Blazor мають сутності, що звуться "компонентами", в яких розміщується своєладна логіка для вирішення окремого завдання; ці компоненти використовуються в html-розмітці поряд зі стандартними теґами.

Особисто для мене певна різниця полягає в тому, що компоненти React, будучи впровадженими відповідно до модульних стандартів сучасної javascript, вимагають проголошення експортних сутностей у кожному модулі. Також ціково, що код рендерингу html зазвичай є частиною інструкції return, що повертає значення функції, а сам код, що виконує певні обчислення, розміщується в тілі цієї функції. В той час як Blazor пропонує набагато більш звичний для c#-розробника підхід з файлами Razor-розмітки та code-behind логікою (і так, невеликі частини коду логіки також можнуть бути присутніми прямо у файлі розмітки). "Під капотом" файли розмітки та їхні відповідні code-behind файли перекладаються у часткові класи c#, а отже вся структура проєкту особисто мені стає більш зрозумілою.

По-справжньому видатною особливістю Blazor є те, що цю технологію можна використовувати для розробки застосунків з трьома різними типами UI: вжиток на сервері, вжиток на клієнті з webassemly та прогресивні веб-застосунки (ПВЗ). Застосунки з UI зі вжитком на сервері дозволяють напряму працювати з базами даних та не перейматися безпекою паролів, обмінюючись змінами в DOM з клієнтами, що під'єднані через той-таки SigbalR; застосунки з UI зі вжитком на клієнті з webassemly дозволяють створювати справжні SPA, які потребують  бекенд лише для початкового запуску та, як розширення, обробки викликів АПІ; ПВЗ є кшталтом застосунків webassemly, які "обгорнуті" відповідними до конкретної ОС застобами, що перетворює їх на повнофункціональний окремий застосунок, що окремо встановлюється та не вимагає постійного під'єднання до інтернету.

Розробка WPF-застосунку дала мені доволі великий новий досвід. По-перше, це клас ObservableCollections, інтерфейс INotifyPropertyChange та події c# — речі, які природним чином не є вживаними на бекенді. Однак для роботи цілісного UI, що містить багато різних візуальних елементів, спосіб, яким фреймворк WPF використовує ці можливості, справляє враження. По-друге, synchronization context та Dispatcher — пишучи асинхронний код для десктоп-застосунку, я спостерігав його падіння лише через те, що намагався змінити якийсь UI-елемент з бекенд-треду. І, нарешті, мова розмітки XAML, що використовується як у WPF, так і у більш сучасних UI-технологіях WinUI та MAUI, справляє враження такого собі Bootstrap на стероїдах :)

Хоча в цьому проєкті я використав Entra Id для автентифікації/авторизації і кожен із застосунків було зареєстровано в Azure, в дійсності я запускав їх всі локально. React-застосунок я розробляв у Visual Studio Code, всі інші — у Visual Studio. Відповідно до постановки задачі, було два REST API — зовнішній для обслуговування звичайних бізнес-запитів, та внутрішній, котрий обробляв довготривалі завдання. Коли якийсь зовнішній запит мав запустити якесь довготривале завдання, зовнішній API робив виклик на внутрішній, де це завдання і виконувалося. Коли в процесі виконання завдання проходило певний етап, про який мав був бути сповіщений користувач, хаб SignalR надсилає йому повідомлення за допомогою сервісу Azure SignalR — власне, це єдина частина проєкту, яка дійсно виконувалася у хмарі.

Отже, на завершальній стадії цей PoC-проєкт складався з хмарного сервісу SignalR, двох API та чотирьох клієнтських застосунків — React, Blazor, WPF desktop та windows console. Проєкт задумано як обробник довготривалих процесів, що запускаються на бекенді та сповіщають користувача, коли задача проходить якусь конкретну стадію. Використані процеси — послідовність Фібоначчі (яку я відключив, оскільки ємність чисел у форматі int32 не дозволяє мати їх достатньо багато, я зберіг цю опцію для вправ з фронтендом), та породження додатніх та від'ємних чисел з інтервалом у 5 секунд.

І ось він — мій зоопарк клієнтів SignalR :)