Як Phoenix вбиває React
Близько півтора року тому ми написали внутрішній інструмент для корпоративних анонсів. Спочатку в ньому використовувався Phoenix для бекенда і React для фронтенда. Тим самим ми отримували переваги Redux та каналів Phoenix при доставці оновлень у браузер у реальному часі.
Це дозволило отримати чудовий живий інтерфейс, але знизило швидкість розробки і стало причиною малої кількості розробників, що беруть участь. Близько трьох місяців тому ми вирішили викинути React і повернутися до серверного рендерингу.
Чому ми вирішили замінити React
Оновлення в реальному часі дозволяє краще зануритися в роботу з додатком, але має додаткові витрати.
Вартість розробки
Замість того, щоб додавати нову можливість в одному місці, нам потрібно було займатися ним і в частині API, і в частині UI. Це також означало, що кожен розробник, який бажає додати свій внесок у проект, повинен знати і React, і Phoenix, що відбивало в них бажання спробувати включитися в роботу.
Тестування
Іншим хворим місцем під час роботи з кодом React було тестування. Оскільки додаток та клієнт були розділені, потрібно було бути впевненими, що відповіді нашої тестової імітації сервера завжди актуальні. На практиці це не було серйозною проблемою, але кілька разів все ж таки вставило палиці в колеса, зменшивши нашу довіру тестам.
Внесення вкладу у проект
Зрештою, ми хотіли, щоб більше людей могло брати участь у роботі над проектом. Ми виявили, що реалізація функціоналу у двох місцях набагато трудомісткіша порівняно з роботою в єдиному місці. А намагатися координувати бекенд- та фронтенд-розробників досить втомлює. Це особливо важливо, оскільки робота над цим додаткомвідбувається у наш «час для розвитку».
Процес заміни
Завдяки тому, що ми вже були готові до використання API, ми змогли переписати сторінки на Phoenix і розвернутися на продакшені, не торкаючись існуючого на React фронтенду. Так як додаток здебільшого є CRUD, більшість сторінок були просто перекоповані один в один, лише замінюючи className на class і блоки <> на .
Ми також додали сюди Turbolinks, що зробило оновлення сторінки дуже плавним та дозволило нам отримувати відчуття SPA.
Результати
Повна міграція була відносно безболісною. Ми дійшли того, що за кілька місяців до проекту приєдналося більше людей, ніж за весь рік використання фронтенду на React. Тести стало писати набагато легше, водночас вони стали набагато надійнішими. Адже тепер не треба боятися, що тестові відповіді сервера відрізняються від справжніх.
Незважаючи на те, що багато співробітників компанії знали про міграцію, ми не стали нікому говорити, що вилили зміни в продакшен. Жодна людина не згадала про помітну різницю. Також ніхто не зрозумів, що використовуваний ними додаток більше не заснований на React. Все завдяки швидкості Phoenix з його значно меншим часом віддачі сторінки та відсутності завантаження великого шматка даних фронтенд-програми на React.
Засвоєні уроки
Наприкінці нашої роботи ми зрозуміли і довели собі, що можемо писати додатки на Phoenix із серверним рендерингом, які так само чудово працюватимуть, як і SPA-додатки на окремому фреймворку. Мало того, що готовий продукт вийшов таким самим класним, так ми ще й стали швидше додавати нові можливості, змогли бути впевненими у тестах та легше залучати розробників для участі у проекті. Узагалом, я думаю, це була велика перемога.
А ви відмовлялися від якихось фронтенд-фреймворків останнім часом?
Висновок від Вуншей
А у нас тут можна отримати грант на тестовий період Яндекс.Хмари. Варто лише у полі «секретний пароль» запровадити «Хабр»