У минулому сайт Psono.com працював на базі Odoo v11. Odoo — це чудова CMS, однак, як нам довелося дізнатися, оновлення системи є складним процесом. Особливо багато проблем під час тестування створював модуль сайту. До кінця 2020 року Odoo v11 досягне кінця свого життєвого циклу, тож нам довелося шукати рішення.
Ми розглядали різні варіанти: оновитись до Odoo v13 і вручну перенести весь контент та кастомізації, найняти когось для проведення міграції або ж повністю перейти на нову CMS. Ми вирішили повністю мігрувати Psono.com, а v11 залишити під фаєрволом (ще не вирішили, як саме це реалізуємо).
Причини, що стояли за цим рішенням:
- У нас є лише невелика кількість контенту, який потрібно мігрувати для Psono.com. В основному це кілька дописів у блозі.
- Міграція на Odoo v13 знову призведе до цієї ж проблеми через два роки, коли v13 досягне кінця підтримки — і можливо з набагато більшим обсягом даних.
- Ми були не дуже задоволені можливостями кастомізації сайтів Odoo v11. Все вкрай складно, їх шаблони зберігаються в базі даних.
- Вартість. Найняти когось для міграції обійдеться щонайменше у 5000 доларів США, а може й більше.
- Спільнота Odoo колись була дуже активною, але останніми роками через ліцензійні зміни та перенесення функцій і плагінів до платних рішень усе опинилося за "платним муром", і спільнота фактично зникла.
- Psono.com — це переважно статичний сайт зі статичним контентом. Якщо нам знадобиться динаміка, можемо підключати її через API.
Наш шлях
Після прийняття рішення про міграцію нам потрібно було визначитися з вибором фреймворку. Є класичні фреймворки типу hugo, який ми вже використовували, але його функціонал обмежений. Шукаючи альтернативи, ми звернули увагу на рішення з світу node / react.
Я хотів написати тут "відмінні рішення", але, чесно кажучи, жодне з сучасних інструментів фронтенду не заслуговує на це звання. Чому "зламані"? Пам’ятаєте часи, коли розробники могли створити сайт з index.html і підключенням jQuery через script-тег, і цього було достатньо, щоб почати? Тепер вам потрібен npm або yarn, потрібно розуміти package.json, webpack-сценарії, сучасні фреймворки на кшталт Angular чи React, кожен із яких працює зі своїм клієнтом. JSX чи typescript... Функції на зразок "гарячого перезапуску" рідко працюють коректно (файл не відстежується, якісь зміни потребують повного перезапуску, а іноді гарячий перезапуск спрацьовує зарано і доводиться оновлювати сторінку вручну). У підсумку доводиться вбивати сервери розробки та чекати хвилинами, поки вони знову запустяться (принаймні у великих проєктах). (Я сумую за часами, коли натискав F5 — і все вже працювало без проблем!). Не кажучи вже про новий фреймворк чи інструмент кожні пів року, тоді як старі зникають майже щодня. Про стан сучасної фронтенд-розробки я міг би ще довго розповідати… Але повернемося до теми.
За відсутності кращих альтернатив найкращими (на момент написання) були next.js та gatsby. Так їх і рекомендували в багатьох статтях. Обидва популярні — якщо порівнювати по GitHub зірках і комітах. Єдина різниця, яку ми знайшли під час початкової оцінки, — требування окремого серверного компонента у next.js, а gatsby створює статичні сайти (будь ласка, не судіть, якщо next.js теж уже без сервера! :D).
Ми трохи попрацювали з Gatsby — все виглядало добре. Далі ми шукали тему оформлення. Gatsby — відносно "новий" інструмент, тому усі доступні теми були доволі базовими. Через тридцять хвилин і тридцять доларів ми вже мали тему з гарним виглядом, яка покривала хоча б частину необхідних компонентів, і ми почали її модифікувати.
Сьогодні для хостингу можна обрати безліч провайдерів: Firebase, netlify, Cloudflare, Vercel, просте GCP Cloud storage або AWS Cloudfront, власні сервери, Docker-контейнери на Kubernetes (я мав це згадати!), ... (Пам’ятаєте старі часи, коли можна було просто за $5 на місяць орендувати web-майданчик із PHP й MySQL? :D ... але то вже інша історія...)
Після порівнянь, читання відгуків та перевірки комбінацій (наприклад, Cloudflare перед Firebase) ми спочатку спробували Cloudflare. Ми великі фанати їх сервісів, тож для нас це був природний вибір. Але, на жаль, їх інструмент wrangler виявився проблемним: спочатку він постійно видавав помилку, потім ми не могли пройти авторизацію... Після оновлення bash перші помилки зникли, але проблема з автентифікацією залишилася. Думаю, я десь помилився й після кількох годин вивчення документації та експериментів просто здався.
Netlify була ще однією кандидатурою, але там треба або підключити гіт-репозиторій і давати їм збирати проєкт (ми ж хотіли використовувати GitLab CI), або вручну завантажувати згенерований сайт. Можливо, у них є варіант відправляти збірку через API, але я не знайшов. Альтернативою міг би бути репозиторій, куди ми пушимо вже зібраний білд, але це видавалося зайвим ускладненням… Ще один мінус — модель ціноутворення: вони беруть досить помітну суму з кожного учасника (!) команди. При цьому це всього лише статичний сайт! Слова "4× bandwidth" у них на сайті одразу навіюють спогади про "webhosting з чесним використанням", коли за перевищення лімітів тебе блокували...
Четвертим сервісом ми спробували Firebase (який у нашому випадку є безкоштовним для очікуваного трафіку і запитів) — і все працювало "з коробки". Можливості перенаправлення URL у них обмежені, тож приведення старих URL до нових стало трохи нудним, але після кількох правил всі редіректи працювали. Їх ціни здаються адекватними, бо тарифи залежать від використаних ресурсів. Раджу уникати додаткових сервісів щоб не потрапити у vendor lock-in, але нам потрібен був лише хостинг.
Також ми коротко подивились на vercel. Але вимога увійти через Github-аккаунт і дати дозвіл “Act on my behalf” відштовхнула мене ще до реєстрації.
Найскладніше було з міграцією блогу. Ми просто вручну копіювали весь контент. Не найкраща ідея для великого блогу, але у нашому було лише п’ятнадцять постів. Gatsby підтримує різні підходи, але ми хотіли щось просте, аби нові пости могли створювати й люди без технічного бекграунду. Ми вибрали markdown, тож вчилися, як налаштувати Gatsby для читання таких публікацій. Це зайняло пів дня із ручною інтеграцією зображень. Ще пів дня — на налаштування шаблону блогу та картинок.
Після міграції всього вмісту й подальших модифікацій шаблону ми автоматизували деплой через Gitlab CI. Тепер простий push запускає збірку та публікацію на Firebase.
Чому Gitlab, а не Github? Github — історично лідер. Там не менше 80% розробників і проєктів. Gitlab же дає більше функцій. Саме тому ми перейшли на Gitlab, оскільки Github роками майже не розвивав свої можливості. З появою Github Actions ситуація кардинально змінилася (особливо після покупки Microsoft), але дорога до рівня Gitlab ще довга. Тому для нас, як команди, яка всі свої проєкти веде на Gitlab, це був очевидний вибір.
Висновок
І ось де ми зараз:
- Gatsby як CMS
- Комерційна тема
- Блог на markdown
- Gitlab CI для автоматизованих деплойментів
- Хостинг на Firebase
Ми цілком задоволені результатом — новий сайт виглядає значно краще!
