Технології заради технологій: чому 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. Розповіді в курилці, як і публікації на модних платформах, не потребують пруф-оф-концепту, пам " ятайте про це.

Не довіряйте технічним публікаціям тільки тому, що вони розміщені на авторітетних сайтах. Це найголовніша порада, яка за своєю важливістю перекриває всі інші.

Цю статтю для вас написавши бекендер. Висновки робіть самі.

Опубліковано: 15/06/20 @ 10:00
Розділ Різне

SEO Блог