Я нещодавно відвідав конференцію Rails World у Торонто, де зібралося 1,000 учасників з понад 50 країн, серед яких творець Ruby, Юкіхіро Мацуомото ("Matz") та творець Ruby on Rails ("Rails"), Девід Хайнемайєр Ханссон ("DHH"). Організатором події була Аманда Періно з Rails Foundation. Конференція була присвячена тому, як Rails став "Фреймворком для однієї людини" — від "Hello World до IPO".
Rails не слідує деяким трендам у програмній індустрії. Ось десять тем, які були протилежними до основних трендів на конференції — де Rails пливе проти течії 🏊:
Розмова біля вогнища між Matz та DHH, яку веде CEO Shopify, Тобіас Лютке. Один із учасників, Натан Фабер-Гуд, поділився у додатку Campfire своїми відповідними "спадкуваннями класів".
1. Server-side html > server-side json
Це вибір між швидкістю та функціональністю frontend javascript. Rails був повним стеком фреймворку з 2004 року, використовуючи серверно-рендерене html, написане у вигляді erb partials. Однак після виходу SPA (Single Page Application) на React у 2013 році, стало популярним "SPA-все", де сервер надсилає json. SPA є найкращим способом створювати багаті javascript-досвіди для користувача, наприклад, як у Miro, Figma чи Photoshop. Однак більшість веб-застосунків не потребують такого багатого досвіду користувача, і SPA мають повільний початковий час завантаження. Щоб виправити ці недоліки SPA, у 2023 році React представив серверно-рендерене html. З серверним html в React та використанням Rails Hotwire і Turbo, здається, що маятник повільно повертається від SPA до серверно-рендереного html.
Короткий виступ про міграцію з React на Hotwire
2. #NoBuild > Webpack
NoBuild — це написання Html без використання попередньо оброблювальних пайплайнів, таких як Gulp і Webpack, які мінімізують ваш код в один великий бандл. Наприклад, Once.com повністю #nobuild.
Перевага таких пайплайнів, як Webpack, полягає в тому, що один мінімізований бандл менший за кілька немінімізованих html-файлів, що дозволяє передавати їх швидше в браузер клієнта. Однак, HTTP/2 з 2015 року використовує одне TCP-з’єднання для передачі кількох потоків даних одночасно, що зменшує необхідність одного бандлу.
Переваги #NoBuild:
- Може бути швидшим для браузерів клієнта завдяки продуктивності кешування; коли відбувається нове розгортання додатку, це не анулює весь бандл додатку, а тільки змінені файли.
- #прозорість людочитного html-коду
- Розробники наближаються до основ браузера
- Тривалість коду: Html, на відміну від інструментів для побудови, призначений для роботи "вічно"
"Craigslist з 1995 року виглядає майже незмінно, тим часом Webpack вже не працює через 5 хвилин!"
3. #NoPaaS > AWS
AWS та інші постачальники хмарних платформ як послуги (PaaS) чудово підходять для масштабованості під змінний трафік, як, наприклад, на Чорну п’ятницю. Однак більшість малих і середніх бізнесів (SMB) не потребують такої масштабованості, і платять AWS 40% прибуткової націнки за право орендувати частини їх серверів. Rails 8 намагається зробити само-хостинг додатків простішим, дешевшим і зручнішим за PaaS. Він вводить Kamal для "безшовного" розгортання. Потрібен SSL? Це так просто, як ssl: true. Можливо, вам знадобиться PaaS коли-небудь, але не на перший день.
Презентація інструменту розгортання Kamal від Дона МкБріна
4.
Реляційні БД > Redis (Active Job)
Для фонових завдань Active Job Rails 8 додав Solid Queue, щоб усунути вимогу до Redis як залежності. Раніше Rails вимагав окремого розгортання Redis для запуску періодичних завдань. Роза Гутьєррес на Rails World показала, як вдосконалення SKIP LOCKED 2017 року в Postgres та MySQL дозволили цим реляційним базам даних обробляти повторювані завдання. Hey.com використовує Solid Queue для запуску 20 мільйонів фонових завдань на день.
Презентація Рози Гутьєррес на Rails World про Solid Queue
5. Реляційні БД > Безсхемні бази
MongoDB провела спонсорську презентацію на Rails World. Виступ підкреслив, що незважаючи на те, що Rails не підтримує MongoDB "з коробки", вони змогли креативно перевизначити CLI Rails, використовуючи Thor, щоб полегшити створення нових Rails і Mongo додатків за допомогою $ railsmdb new app_name. Хоча це працювало, це також підкреслило, що підтримка MongoDB в Rails базується на слабо підтримуваному зовнішньому гемі (відносно ActiveRecord).
6. Купувати програмне забезпечення один раз > Платити щомісяця
З початку 2000-х років усі платять щомісяця за програмне забезпечення. Once.com, створений тими ж людьми, що й Rails та 37signals, продає програмне забезпечення за одноразову плату. Вони продають Campfire, застосунок, схожий на Slack, за $299. Rails World використовував само-хостовану версію Campfire для живого комунального чату.
7. PWA > App Store
Campfire — це Прогресивний веб-застосунок (“PWA”), вебсайт, який, коли прикріплений до смартфону користувача, працює як рідний застосунок. Багато функцій рідних застосунків можна реалізувати за допомогою PWA, як показано на https://whatpwacando.today. Rails будує гем для веб-сповіщень на смартфонах під назвою Action Notifier.
8. Файли власності > Інструменти для модульності
Як Rails-додатки зростають з часом і перетворюються на так звані “мудяні кулі”, організації задаються питанням, що далі? Чи залишатися з монолітом або мігрувати до мікросервісів? У Shopify ми пішли шляхом модульності нашого моноліту, і з того часу GitHub, Gusto та інші пішли нашим шляхом. Але після 6 років настав час запитати себе: “Чи вирішили ми проблему, яку ставили перед собою? Чи стало це краще ніж раніше?”
Ейлін Учителле почала з проблем великих монолітів:
- Архітектурні, тобто відсутність меж та велика кількість
/models - Операційні, тобто ненадійні тести і повільне CI
- Організаційні, тобто труднощі з пошуком власників коду
Інструменти, як-от Packwerk, можна використовувати для явного оголошення меж пакунків і залежностей. Однак вони можуть створювати додаткові проблеми:
- Обсесія примітивами, тобто передача ідентифікаторів об'єктів замість самих об'єктів, що веде до збільшення кількості викликів бази даних.
- Обсесія власністю, що може шкодити співпраці.
- Обсесія пакетами, тобто створення пакетів для всього.
- Копіювання коду з одного пакету в інший, щоб уникнути нових залежностей.
- Кругові залежності
Справжня проблема полягає в тому, що ці додатки будуються тисячами інженерів різного рівня досвіду протягом 20 років, а інженерів часто наймали швидше, ніж їх встигали ввести в курс справи.
Файли власності працюють так само, як пакети для встановлення власності, і пакети не зменшать тривалість CI.
Основна доповідь 2-го дня “Міф модульного моноліту”
9. Відкрите програмне забезпечення > Комерціалізоване OSS
Перетворення вашого популярного відкритого програмного забезпечення на бізнес є спокусливим! Багато проєктів відкритого програмного забезпечення нещодавно стали комерціалізованими через зміни ліцензій (Redis, Terraform), хмарні пропозиції (Vercel/Next.js, Laravel), або примусові виплати, що вимагають 8% прибутку назад (WordPress).
Альтернативна модель, яку використовує Rails, полягає в тому, що його учасники заробляють на життя, працюючи в прибуткових компаніях, які використовують Rails. Функціональність Rails витягується з робочого коду в Basecamp, Hey.com, Github та інших.
10. Без типів > Типізовані
“Перше, що я б зробив [якщо б я був на чолі Ruby, а Matz був на чолі Rails], це створив би конституцію Ruby, і перше правило було б — ніколи не вводити статичне типізування”.
Це твердження, здається, суперечить проєктам Sorbet і RBS, які додають типову безпеку до Ruby. З іншого боку, у Javascript, Turbo 8 припинив підтримку TypeScript. Matz, здається, погоджується, “писати типи явно не для людей”.
Не обговорювалося на Rails World 2024, або принаймні на жодній з доповідей, на яких я був, питання маjestyчний моноліт проти мікросервісів.
Rails World 2025 повернеться до Амстердаму. Поділіться, які з цих тем набудуть популярності до наступної конференції, а які — ні! Ось офіційний підсумок Rails World 2024.
Перекладено з: Rails World Toronto: Hello World to IPO