Технології заради технологій: чому Front-end не розв’язує завдань Back-end
Привіт, мене звати Захар, і я алкоголік веброзробник. Я починав кар’єру програмістом у тролейбусному депо, написав плагін для Grafana, яким користуються в Dropbox, розробив багатопотокову систему кешування для sixt.com, а також безліч нудної нецікавої фігні для безлічі нудних нецікавих компаній. Усе як у всіх.
У цій статті порушу тему технологій заради технологій, адже цей біль об’єднує значно більше розробників, ніж ви можете подумати. Публікація буде цікавою насамперед моїм колегам з веброзробки. Але якщо так склалося, що ви працюєте в іншому напрямі — не страшно. Ніколи не пізно перепрофілюватися.
Ілюстрація Уляни Патоки
Проблема
Отже, уявімо собі вебпроєкт. Стандартний такий legacy-сайт на кілька десятків тисяч сторінок. Проєкт, який перевантажений плагінами, контролерами, інтерфейсами, екстеншенами, темплейтами та іншими англіцизмами. 150 таблиць у базі даних, сотні тисяч рядків коду і тисячі файлів застарілого фреймворку. Уявили? Молодці. Я впевнений, що багато читачів працювали з чимось схожим, можливо, навіть неодноразово.
Структури таких проєктів завжди заплутані ще на етапі планування, а документацію як явище нехтували всі покоління розробників. Додавання нового функціоналу тягне за собою редагування десятків файлів, виправлення навіть найпростіших проблем займає дні, релізи підсистем планують на пів року вперед і все одно щонайменше двічі переносять. Але головна проблема не в цьому.
Наш проєкт написаний на PHP. Тому це лише питання часу, коли в компанії заведеться візіонер, який запропонує переписати все з нуля. Та так, щоб викинути все погане старе і написати все прекрасне нове — кращого слогану годі й шукати. Нагорі дають зелене світло, візіонер «кусає» інших розробників, решта — справа техніки.
Стейкхолдери отримали якісні презентації, підписи поставлено, бюджет виділено, під проєкт сформовано нову команду сильних і досвідчених фронтенд-інженерів. І пішло-поїхало.
Так, стоп. Чому лише фронтендерів? Та тому, що бекенд більше не потрібен.
У нинішні часи розподіл на бекенд і фронтенд, як це було останню сотню років, уже не актуальний. Навіщо множити рівні абстракцій, якщо можна просто взяти React і написати все на JavaScript?
Рішення
Jamstack обрали без тендерів і поза конкурсом як наймодернішу та найперспективнішу схему розробки. Вся бізнес-логіка відтепер житиме лише на клієнт-сайді. Сьогодні всі так роблять.
На жаль, крім логіки рендеру контенту, вебсайту потрібен і сам контент. Контенту на проєкті «вагон і маленький візок», і його потрібно десь зберігати. Це досить нудне завдання, але, на щастя, фронтенд-розробникам не потрібно перейматися такими дрібницями. Для цього існують докеризовані Headless CMS у вигляді напівфабрикатів, які треба раз розгорнути десь на сервері, а далі воно вже якось самостійно працює.
Редактори контенту з легкістю наклікають в адмінці необхідну структуру контенту, а експортом даних можна зайнятися пізніше, коли все буде готове до релізу. Зрештою, що може піти не так в перенесенні тексту з однієї адмінки в іншу, правда ж?
Інтеграція
Сказано — зроблено. Стек обрали, фреймворки встановили, бібліотеки під’єднали. Пруф-оф-концепт готовий уже за два тижні, MVP — одразу після того. Вже за два місяці від початку роботи нова версія проєкту опиняється на новенькому git-based хостингу. Анімації анімуються, кнопки кнопкаються, попапи попапаються, а швидкість рендеру тестових сторінок досягає 0.003 секунди за дюжину.
Керівництво щиро усміхається у вуса, ключові розробники отримують премії, legacy-проєкт ось-ось закриють, і більше нікому не доведеться мати справу з цим пекельним монолітом. І ось невдовзі настає фінальний етап — міграція даних і запуск. Тут проєкт успішно та без затримок йде в продакшн, CEO особисто телефонує розробникам і дякує за прекрасну роботу. Акції компанії зростають на 32%.
Гарна історія з гарним закінченням — це завжди приємно, але є одне «але».
Провал
Фінального етапу так і не сталося. Ні за місяць, ні за пів року. Проєкт і досі лежить на окремому інстансі, кнопки досі кнопкаються, а тестові дані рендеряться за 0.003 секунди за дюжину. На нову систему перенесено менше як один відсоток даних. Цукерберг не зателефонував.
Усі нові фічі стабільно релізять на старенькому бегемоті, який кульгає, кашляє, але все-таки стабільно працює. Хай навіть і на PHP. У той час як лінійний менеджмент усе частіше обережно запитує про нову версію вебсайту. Тільки так, щоб з нормальним бекендом цього разу.
Чому так сталося і хто в цьому винен? Розберімося.
Front-end is the new Full Stack
Можливо, раніше вам уже доводилося чути цю мантру на різноманітних мітапах і хакатонах. Вона і стала причиною провалу всього проєкту.
Річ у тому, що відмова від повноцінного сервер-сайду накладає на проєкт певні обмеження. На тлі популяризації тренду serverless-технологій ці обмеження здаються багатьом незначними й не вартими уваги. Зрештою сервер-сайд нудний і нецікавий. Що значить фронтенд теж нудний? Всі люблять фронтенд, не вигадуй.
Насправді я не впевнений, хто в цьому винен. Умовний React, бо спонукає людей розширювати функціонал за допомогою бібліотек, чи умовний npm, який нав’язує розробникам ідею підходу до роботи як до конструктора. Але це вже неважливо.
Так склалося історично, що фронтенд-розробка набирала обертів останніх N років катастрофічно швидко, і кількість фреймворків, плагінів, генераторів коду, сніпетів і мікробібліотек збільшувалася в геометричній прогресії. Всі знають жарт про JavaScript-фреймворк, який застарів ще на момент написання документації до нього. Але крім погоні за версіями, ця тенденція має побічний ефект, який нелегко помітити з першого погляду.
Прихована загроза
Розвиток фронтенд-технологій не просто збільшує кількість шляхів виконання завдань, а й розширює зону відповідальності девелопера.
Раніше було достатньо знати HTML i CSS, щоб працювати верстальником. Пізніше, років за 10, до цього списку додався базовий JavaScript. Ще за три роки з’явилося обов’язкове знання jQuery. Згодом виник Angular.js. Тоді Backbone, Knockout, Ember, Polymer, Aurelia, React, Vue, Preact, CoffeeScript, Webpack, npm, yarn, GraphQL, Gatsby, you name it.
З кожною новою бібліотекою додавалося все більше нетипових для клієнт-сайду завдань у розсилках вимог рекрутерів. З кожним форком нового фреймвоку кількість задач, які притаманні лише бекенду, потихеньку зменшувалася.
Зі збільшенням переліку базвордів зміщувався і напрям розвитку фронтенду. Сучасному спеціалісту більше недостатньо вміти працювати з дизайном і браузерами, йому тепер потрібно вміти спілкуватися з API, мутувати дані, стежити за стейт-менеджментом, планувати архітектуру сторінок і переходів. Водночас робити все це за допомогою взаємозамінних компонентів, враховуючи вимоги від SEO-департаменту, оптимізуючи час завантаження та навантаження на CPU... Ну ви зрозуміли.
Бекенд без бекенду
Останній бастіон впав після появи моди на serverless — підхід, який інкапсулює весь бекенд у вигляді чорної коробки з API, який може лежати де завгодно. Хоч на LAMP, хоч у «хмарі». Бекенд можуть наповнювати і люди, і нейромережі. Він може бути один або їх можуть бути тисячі — усе це більше не відіграє ролі. Великі рожеві GraphQL тентаклі відішлють вам будь-які дані в будь-якій формі з єдиного ендпойнту, тільки попросіть.
Тож, трішечки гіперболізуючи, можна заявити, що єдине завдання, яке все ще не підвладне клієнт-сайду, це бази даних і SQL. Але тут діло принципу. Чого тільки не вигадають хитрі фронти, щоб не писати right join. Та бази даних нецікаві, і з цим нічого не вдієш. Все інше — метушня, для якої існує щонайменше три JS-бібліотеки на GitHub.
Але що робити, коли відповідного API-провайдера нема в жодному рейтингу на зразок «топ-64 API-провайдерів сьогодні до обіду?» Доведеться користуватися напівфабрикатами.
Завбачливо запаковані на заводі дбайливими та відлюдькуватими бекендерами, вони запустяться на вашому AWS від найменшого копняка. Рибка в сітці. Так? Чи ні? Чи так? Я заплутався.
Front-end без причини
На жаль, як показує практика — ні. Більшість типових для бекенду рішень все ще не вийшли зі стадії бети на клієнті. GraphQL досі сиріший за курку в шоу Гордона Рамзі, Server Side Rendering збоїть при використанні неправильних плагінів, а зоопарк мікробібліотек змушує 80% часу поєднувати між собою виклики тих чи інших компонентів, які написані невідомо ким і невідомо де. Ви їх підключили тільки тому, що побачили в першому посиланні пошуковика.
Навіть якщо ви довго та скрупульозно вибирали бібліотеку для розв’язання конкретної задачі, яка зайняла б у вас 6 рядків чистого JavaScript, ви робили це за кількістю зірочок на GitHub. Всі ми такі.
Отже, за 6 місяців роботи над суперсучасним вбивцею PHP-фреймворку, тільки на JavaScript, ми маємо 43 підключених модулі, кілька тисяч захардкоджених роутів, безліч темплейтів і гору наперед підготовлених GraphQL-запитів, які завжди витягують з бекенду одні й ті самі дані для кожного компоненту на сторінці. А також рафіновану CMS, яка не вміє і 10% з того, що вміє старенький пенсіонер PHP на опенсорсному фреймворку минулого десятиліття.
І тут доводиться викручуватися. Контент підганяють під систему, а не систему під контент. Реалізація підганяється під трендову концепцію, сова підганяється під глобус. Зате ви завжди можете виступити на фронтенд-конференції з доповіддю про використання альфа-версії нової технології на найбільш бойовому проєкті. Мовляв, усе круто, залишилось допрацювати напилком.
Замість висновків
На жаль, висновків у мене для вас нема. Життя бентежне, тренди заразні, модність технології все ще важливіша за її реальні можливості, а згадка базворду на TechCranch усе ще авторитетніша за відсутність сотні відкритих issues на GitHub.
Але в мене для вас є певні побажання. Про всяк випадок.
Працює? Не чіпай. Очевидна істина, яка не для всіх очевидна. Якщо вам раптом захотілося переписати робочий модуль на сучаснішій технології, згадайте про вояджери, які досі цілком собі крутять дані на Cobol. І ніхто від цього ще не вмер. Ну, крім більшості людей, які знали Cobol.
Уникайте технологій, яким менше як два роки. Жарт про застарілі фреймворки смішний лише перші 24 місяці. Після цього йде рутина і стабільність. Справді більшість бібліотек і форків фреймворків не доживуть до такої дати, але Vue.js на ринку вже 7 років. А React ще довше. Чи використовують їх сьогодні? Питання риторичне. Залиште експерименти з бета-версіями та ультрасучасними технологіями для амбіційних джуніорів, які їх і написали. Продакшн не терпить експериментів зі стабільністю.
Уникайте мікробібліотек. Пишіть усе самі. Так, можливо це займе більше часу, але у вас ніколи не буде проблем з неочікуваним апдейтом, який зламав усе, що можна було зламати. Мікросервіси більше не в моді, стабільні моноліти знову перемагають мільйони рухомих частин і безліч ліній дотику між бібліотеками від різних вендорів.
Не робіть те, що з самого початку здається неправильним. Хардкод-роут, зміна архітектури через відсутність функціоналу в бібліотеці, зміна логіки проєкту через баг модуля, піца з ананасами. Якщо ви відчуваєте, що це не нормально, намагайтеся не робити цього. Здебільшого вам вдасться домовитися про додаткові години для завдання, яке допоможе зробити все так, як треба, а не так, як у всіх.
Не оцінюйте технологію за її популярністю. Сьогодні всі ваші колеги говорять про фреймворк X, а завтра перемкнуться на фреймворк Y. Розповіді в курилці, як і публікації на модних платформах, не потребують пруф-оф-концепту, пам’ятайте про це.
Не довіряйте технічним публікаціям тільки тому, що вони розміщені на авторитетних сайтах. Це найголовніша порада, яка за своєю важливістю перекриває всі інші.
Цю статтю для вас написав бекендер. Висновки робіть самі.
