Як Phoenix вбиває React



Близько півтора років тому ми написали внутрішній інструмент для корпоративних анонсів. Спочатку в ньому використовувався Phoenix для бекенду і React для фронтенда. Тим самим ми отримували переваги Redux та каналів Phoenix при доставки оновлення в браузер в реальному часі.
Це дозволило отримати чудовий живий інтерфейс, але знизило швидкість розробки і стало причиною малої кількості що беруть участь в процесі розробників. Близько трьох місяців тому ми прийняли рішення викинути React і повернутися до серверного рендерингу.
Чому ми вирішили замінити React
Оновлення в реальному часі дозволяє краще зануритися в роботу з додатком, але при цьому має додаткові витрати.
Вартість розробки
Замість того, щоб додавати нову можливість в одному місці, нам потрібно було займатися їй і в частині API, і в частині UI. Це також означало, що кожен розробник, що бажає додати свій вклад у проект повинен знати і React, і Phoenix, що відбивало в них бажання спробувати включитися в роботу.
Тестування
Іншим хворим місцем при роботі з кодом React було тестування. Так як додаток і клієнт були розділені, потрібно було бути впевненими, що відповіді нашій тестовій імітації сервера завжди актуальні. На практиці це не було серйозною проблемою, але кілька разів все ж вставило палиці в колеса, зменшивши нашу довіру тестів.
Внесення вкладу в проект
Нарешті, ми хотіли б, щоб більше людей могло брати участь у роботі над проектом. Ми виявили, що реалізація функціоналу в двох місцях набагато трудозатратнее порівняно з роботою в єдиному місці. А намагатися координувати бекенд — і фронтенд-розробників досить утомливо. Це особливо важливо, оскільки робота над цим додатком відбувається в наш «час для розвитку».
Процес заміни
Завдяки тому, що у нас вже був готовий до використання API, ми змогли переписати сторінки Phoenix і розвернутися на продакшені, не зачіпаючи існуючий на React фронтенд. Так як додаток здебільшого являє собою CRUD, більшість сторінок були просто перекопійовано один-в-один, лише замінюючи
className
на
class
блоки
{}
на
<%= %>
.
В місцях, де нам був потрібен JavaScript, ми пішли второваною доріжкою «вкраплення» шматочків на ньому. Кращий приклад такого підходу — живе оновлення коментарів. Всякий раз, коли коментар створюється на бэкенде, ми транслюємо його всім користувачам. Замість того, щоб відправляти JSON, ми створюємо
live-html
канал, через який передаємо оновлення користувачами у вигляді HTML. Ось JavaScript код прямо з програми:
import socket from './socket'

const channel = socket.channel('live-html', {})

channel.join()
.receive('ok', function(resp) { console.log('Joined successfully', resp) })
.receive('error', function(resp) { console.log('Unable to join', resp) })

channel.on('new-comment', payload => {
$(`[data-announcement-id='${payload.announcement_id}'] .comments-list`)
.append(payload.comment_html)
})

Це дивно невелика кількість коду на JavaScript, забезпечує величезний шматок функціональності додатку. Подібна стратегія генерації HTML на сервері і транслювання його клієнтам набагато простіше, ніж написання повноцінного фронтенд-додатки з такими ж можливостями.
Ми також додали сюди Turbolinks, що зробило оновлення сторінки дуже плавним і дозволило нам отримувати відчуття SPA.
Результати
Повна міграція була відносно безболісною. Ми прийшли до того, що за кілька місяців до проекту долучилося більше людей, ніж за весь рік використання фронтенда на React. Тести стало писати набагато легше, в той же час вони стали набагато надійніше. Адже тепер не потрібно боятсья, що тестові відповіді сервера відрізняються від справжніх.
Незважаючи на те, що багато співробітників компанії знали про походить міграції, ми не стали нікому говорити, що вилили зміни в продакшен. Жодна людина не згадав про помітної різниці. Також ніхто не зрозумів, що використовується ними додаток більше не засноване на React. Все завдяки швидкості Phoenix з його значно меншим часом віддачі сторінки і відсутності завантаження великого шматка даних фронтенд-додатки на React.
Засвоєні уроки
В кінці нашої роботи ми зрозуміли і довели собі, що можемо писати програми на Phoenix з серверним рендерінгом, які будуть так само чудово працювати, як і SPA-програми на окремому фреймворку. Мало того, що готовий продукт вийшов таким же класним, так ми ще й стали швидше додавати нові можливості, змогли бути впевненими в тестах і легше залучати розробників для участі в проекті. Загалом, я думаю, це була велика перемога.
А ви відмовлялися від будь-яких фронтенд-фреймворків останнім часом?
Висновок від Вуншей
Друзі! Наступна стаття про створення блогу на Феніксі через тиждень. Сьогодні ж ми вирішили обговорити іншу цікаву тему, пов'язану з цим фреймворком.
Нагадую, що ми проводимо конкурс з класним призом для перемоги в якому вам потрібно опублікувати класну статтю про Еліксир на Хабре. А також закликаю вас активніше підписатися на розсилку. Двічі на тиждень ми відправляємо нові статті на пошту, яких ще немає у відкритому доступі на сайті! Спасибі всім, хто залишається з нами!
* Заголовок для активації бурхливих обговорень, наповнених радістю і добром, в коментарях.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.