Rails або Sinatra: найкраще з двох світів?

З року в рік на світ Ruby сходило благословення — тут з'явилося завидну кількість фреймворків для розробки веб-додатків. Однак двоє з них нещодавно стали явними лідерами цієї сфери. Більшість читачів цього сайту чули про Ruby on Rails. Він був розроблений Девідом Хайнемайером Хенссоном в 2004 і являє собою MVC фреймворк, який допомагає підвищити продуктивність і зробити при цьому розробників щасливими. Sinatra був створений Блейком Мизерани в 2007, є предметно-орієнтованою мовою (domain-specific language), який виступає обгорткою для рівня легковагих HTTP запитів та відповідей поверх Rack. Його мінімалістичний підхід витончений і елегантний. Статистика на RubyGems.org наочно показує наскільки популярні обидва цих фреймворку: Rails був викачаний 7 мільйонів разів, а Sinatra — 1.5 мільйона. Саме Rails втягнув мене в веб-розробку на Ruby, але протягом кількох останніх років я набагато частіше використовував Sinatra (і ось 7 причин за яких я його люблю). На перевірку виявилося, що мені для побудови додатка потрібен лише Sinatra разом з кількома гемами. Це змусило мене замислитись над тим, а чи можна з Sinatra подужати будь-який проект. Коли краще всього використовувати Sinatra, а коли найкращим вибором буде Rails? Намагаючись знайти відповідь на це питання, я запитав у знаменитих Ruby розробників, що вони думають з цього приводу.

Костянтин Хаас, який в даний момент займається підтримкою Sinatra, вважає що, кожен з інструментів відповідає вимогам додатків свого виду:
Кожен з них вирішує різний ряд проблем, навіть не дивлячись на те, що вони, в дійсності, сполучаються на цьому терені. В той час, як Rails є фреймворком, який з фокусирован на написанні модельно-орієнтованих веб-додатків, Sinatra — бібліотека для обробки HTTP на серверній стороні. Якщо ви мислите термінами запитів/відповідей HTTP, то Sinatra стане ідеальним інструментом. Якщо вам необхідна повна інтеграція і як можна більше бібліотечних шаблонів, то Rails в цьому випадку буде для вас чудовим вибором.
Девід Хайнемайєр Хенссон також вважає, що для кожного з них є своє місце, але вважає, що, вибираючи між ними, слід керуватися розміром свого додатка:
Sinatra чудово підходить для мікро-стилю, а ось Rails — ні. До тих пір, поки ви дотримуєтеся мінімалізму, Sinatra перевершує Rails. Якщо ви виходите за рамки оного, то Rails б'є Sinatra.
Дійсно, більшість людей швидше погодяться що Rails більш орієнтований на великі проекти, в той час як Sinatra краще підійде для микроприложений і API. Девід продовжує, пояснюючи правило вибору між Rails і Sinatra, яке він придбав з досвідом:
Якщо у вашому додатку 5-10 кінцевих точок, то вигідно використовувати Sinatra для власноручного рішення. Особливо, коли сама структура контролерів може поміститися на 1-2 сторінках коду, — чудово, якщо це можна запустити одним файлом.
Рік Олсон Github підтверджує, що Sinatra справді є чудовим вибором для невеликих проектів:
Sinatra дійсно чудово працює як API, а також на малих сайтах (внутрішні програми, Github Jobs і т. д.)
Девід Хайнемайєр Хенссон пояснює, чому Rails стає настільки хорошим вибором, коли справа стосується побудови великих веб-додатків:
Rails дозволяє людям робити вибір між кращими технологіями («кращими» їх охрестив я і спільнота Rails) і в цьому криється велика частина його успіху… Я зраджую Rails кожну тиждень, щоб він краще відповідав ідеальному, в моєму уявленні, фреймворку.
Костянтин Хаас ділиться своїм ентузіазмом з приводу Rails і його філософії:
Я люблю Rails. Rails творив наше уявлення про веб-додатках. Rails вирішує для вас такі проблеми, які Sinatra вирішити не в силах, оскільки він може зробити більше припущень про вашому додатку. Для вас вже все встановлено незалежно від того, знадобиться воно вам чи ні, найбільший недолік в архітектурі Rails — прийняття того, що все повинно вирішуватися з допомогою одного інструменту.
Отриманими можливостями, які вам, загалом-то, в Rails і не потрібні, безумовно супроводжують втрати, останні, однак, компенсуються тим, що ви отримуєте велику кількість можливостей, в яких справді потребуєте. Зрештою, це може себе виправдати, особливо коли справа стосується великого проекту. Однак, не всі погодяться з тим, що великий проект може бути реалізований тільки на Rails. Джоффрі Грозенбах Peepcode Screencasts вважає що це «застарілий погляд, який справедливий лише для Sinatra в 2008, але, безумовно, не в наші дні». Він звернув увагу на чудове додаток Gaug.es, побудоване на Sinatra, як на приклад, що доводить, що він (Sinatra) більш ніж підходить для створення експлуатованих великомасштабних сайтів.

Незважаючи на вищесказане, Костянтин Хаас звертає увагу на потенційну проблему при використанні Sinatra для створення великих програм:
Створення більш складних додатків на Sinatra (або, швидше, використання Sinatra серед числа інших додатків) змусить розробника значно більше часу витратити на обдумування архітектури та інструментарію. Це як перевага, так і недолік.
Деякі розробники напевно до цього поставляться як до переваги, якщо вони воліють строго контролювати те, що відбувається в своєму додатку і усвідомлювати те, як це все відповідає одне одному. Джоффрі Грозенбах вважає, що це жертва, яка себе виправдовує:
Стабільність — найбільша перевага Sinatra. Ви жертвуєте власними дизайнерськими рішеннями заради вигод від декількох генераторів Rails. Написання на Sinatra може подарувати розробникам і бізнес API стабільність, оскільки фреймворк змінюється рідко. Ви володієте своїм кодом, і ви вирішуєте, коли його варто змінити.
Він продовжує пояснювати, чому Sinatra є чудовим кандидатом для побудови додатків:
Кожне з моїх нових додатків починається з Sinatra і, зазвичай я приходжу до висновку, що крім Sinatra разом з кількома Rack плагінами, мені більше нічого і не потрібно, невелика бібліотека і CouchDB Backbone.js як фронт-енду.
Соу Шеонг Чанг Yahoo автор Клонування Інтернет Додатків з Ruby дотримується простої моделі розробки:
Sinatra виконує все що мені потрібно на базовій платформі, а все інше вже забезпечено хмарними платформами і сервісами (наприклад, Heroku і його екосистема аддонов), або я можу реалізувати з допомогою гемов. А для всього залишився я можу написати код власноруч.
Насправді цю ідею можна було б використовувати як більш досконалий підхід у застосуванні Sinatra — створення свого власного спеціального фреймворку, який повністю задовольняє ваші потреби. Почніть з Sinatra, а потім додайте геми, які реалізують потрібні вам можливості, щоб створити власний індивідуальний фреймворк. Щось подібне реалізовано у проекті Padrino.

Девід Хайнемайєр Хенссон не бачить у цьому сенсу:
Розбивка всього на маленькі частинки і примус розробників до власноручного збору всього і вся є антитезою їх всього того, заради чого створювався Rails і того, як він переміг у грі фреймворків. Були витрачені десятки тисяч людино-годин заради того, щоб ми досягли цієї мети. Спроба це відтворити — порожня витівка.
Хоча контроль над тим, що відбувається всередині вашого додатка може бути гарною ідеєю, Костянтин Хаасе попереджає, що це може відняти багато часу:
Головним недоліком Sinatra, який не вирішує за вас проблему, є саме те, що Sinatra її не вирішує. Ви повинні самостійно з нею розібратися. Це може призвести до того, що ви затратите невиправдано велику кількість часу, намагаючись її вирішити.
А якщо у розробників обмежений бюджет, то у них цього часу банально може і не бути. Девід Хайнемайєр Хенссон стурбований, що застосування Sinatra при спробі заново винайти колесо загрожує втратою величезної кількості часу даремно:
Швидше за все, вся та робота, яку вам належить зробити, заради відтворення рішень, вже наданих в Rails, негайно перекреслить простоту використання Sinatra. Мені шкода того чоловіка, який намагається самотужки побудувати Basecamp, GitHub, Shopify або які-небудь інші великі програми у Sinatra. Rails — величезний і заплутаний інструмент, оскільки він містить вирішення більшості проблем, з якими стикаються більшість людей, які трудяться над створенням програми такого масштабу. Спроба відтворити всі ці рішення вручну — все що завгодно, але тільки не простота.
Райан Бейтс, провідний Railcasts вважає, що перевагу при використанні Rails полягає в заощадженні часу, коли проект починається з нуля:
Стандартний додаток Rails надає багато з того що мені потрібно і що вимагало б додаткових установок в Sinatra. А це надає додаткову швидкість при розробці на Rails.
Цю ж думку висловлює Рік Олсон, який вважає, що Rails полегшив втілення проекту GitHub.
Я думаю, що протягом першого року Rails був головним інструментом для засновників [GitHub]. Їм вдалося скористатися перевагами деяких можливостей Rails більш високого рівня і швидко виконати ітерацію.
Чад Фоулер (зі засновник RubyConf) цитує мантру Rails про «угоду щодо конфігурації» як ще одну причину завдяки якій Rails прискорює розробку великих проектів:
Генератори і структури Rails дають угоди, які не надає Sinatra.
Проблема в тому, що ці угоди іноді схожа гамівній сорочці, Rick Olson звертає увагу на такі випадки:
Rails хороший, якщо для вас прийнятні його догматичні угоди і ви дотримуєтеся «золотого шляху».
На відміну від нього у Sinatra немає яких-небудь обмежень, Сатіш Талім Ruby Learning привів чудову цитату Арона Квінта, яка це пояснює:
“Sinatra слід абстрактного шаблоном: НННВШ (Нам Не Потрібні Смердючі Шаблони). НННВШ означає, що Sinatra більш ніж гнучкий і не зумовлює те, яким чином ви будете організовувати доменну або бізнес логіку. У нього немає явно заданої структури папок, відсутня абстракція баз даних за промовчанням, немає обмежень щодо того, де і як його застосовувати".
Sinatra найбільш привабливий там, що дозволяє визначати як і яким чином від і до структурувати додаток. Побудова на Sinatra може дати свободу, тому що ви не обмежені у розмірі, структурі або потоці робіт. Ви можете побудувати API, веб-додаток або запакувати свій код в гем.

Можливо, деяких здивує той факт, що Девід Хайнемайєр Хенссон теж обожнює простоту Sinatra:
В минулому я застосовував Sinatra і мені він дуже подобався. Він пропонує зовсім інший підхід, який чудово підходить для вирішення завдань значно меншого кола, однак вирішує їх дійсно чудово.
Так чи є у Sinatra таку перевагу, які б йому захотілося перенести в Rails?
По суті, в Sinatra немає нічого такого чого б мені захотілося переробляти Rails по-іншому.
Проте він все ж визнає, що в Rails практично повністю скопійована одна з найкрутіших можливостей Sinatra:
Ми хотіли додати в Rails режим єдиного файлу (single-file mode), але відмовилися від цього, навіщо нам оптимізувати те, з чим Sinatra і так чудово справляється?
Поза всяким сумнівом, Rails надає величезну кількість можливостей, але нерідко серед них є ті, в яких ви не потребуєте або вони не працюють саме так, як вам необхідно. У Rails 3 була зроблена спроба згладити це настільки, наскільки це можливо — шляхом роз'єднання деяких з можливостей різного виду, що в результаті може дати більш легкий і конфігурується продукт, на що і звертає увагу Чад Фоулер:
Сам по собі Rails не такий вже і «важкий», особливо якщо взяти до уваги його поточну можливість зменшення в розмірі на свій розсуд.
Rails 3 привніс багато конфігураційних опцій, що дозволяють підлаштувати додаток під виконувану для вас завдання. Незважаючи на те, що існує можливість позбутися від мотлоху, Костянтин Хаас попереджає, що залишити все як є нерідко здається занадто привабливим, що призводить до роздування:
В моїй практиці програми на Rails часто стають єдиним монолітним додатком. [Відмова від Rails] дає в підсумку модульність, гнучкість, швидкість на тестах і масштабованість. Однак ви можете домогтися такої ж архітектури, якщо будете акуратно конструювати Rails програми, справа в тому, що вчинити інакше (не робити цього) дуже заманливо.
Девід Хайнемайєр Хенссон не бачить в цьому проблеми і вважає, що незалежно від того, чи користуєтеся ви усіма можливостями чи ні, Rails підійде в будь-якому випадку:
Фізично видаливши ділянку коду Rails, який ви не використовуєте, ви не отримаєте нічого корисного. Ніхто не змушує вас користуватися всіма можливостями. [Багато можливостей Rails] цілком опціональні і можуть бути повністю відключені, якщо вони вам настільки заважають.
Rails стає легше, а Sinatra показав що може впоратися з важкими завданнями, це означає що вони все більше сполучаються. Чад Фоулер вважає, що насправді і Sinatra і Rails можуть застосовуватися в широкому колі проектів:
Я думаю, що насправді кожен з них можна використовувати в будь-якому з протилежних випадків. Вважаю, що в кінці кінців, це суб'єктивний вибір.
В цілому всі погодяться, що «для роботи повинен бути підібраний відповідний інструмент», але їх сполучення означає, що рішення часто зводиться до персонального вибору. Sinatra може дати більше контролю над архітектурою, але чи будуть додаткові зусилля гідною тратою часу (чи вашого клієнта, що більш важливо)? Райан Бейтс підводить підсумок щодо типів особистості і того який фреймворк вони вибирають:
Я вважаю, що врешті-решт це залежить від того що ви оберете: почати без нічого і додавати за потребою, або почати з важкого, а потім видаляти що-небудь, якщо необхідно позбутися ваги.
Джоффрі Грозенбах припускає, що існує два абсолютно різних типу розробників:
Я думаю, що серед Ruby розробників є істотна відмінність: є ті, хто воліють малий розмір, легковажність, швидкість, эксплицитность (explicit) і розширюваність; а є ті, хто віддає перевагу фреймворки з повним набором можливостей. Sinatra задовольняє запити перше, а Rails — друге. Так що я не думаю, що Sinatra витіснить Rails. Просто це інша філософія, яка подобається певного виду розробників.
Але, можливо, вам не буде потрібно робити вибір між ними. Автор, Дейв Кеннеді, член Ruby Source, звертає увагу, що Rails і Sinatra загалом досить непогано разом працюють:
Якщо в процесі розробки 2 фреймворку стали один одного доповнювати, то це говорить про те, що я зараз працюю над многоарендным додатком (multi-tenant), яке інтенсивно експлуатує Sinatra всередині Rails, крута річ. Sinatra дозволив мені надати своєму додатком модульність, перш зробити це настільки просто було мені не по силам.
Багато людей зрозуміли, що завдяки можливості вбудовувати Sinatra в Rails 3+ додатки, дійсно можна отримати найкраще з того, що пропонують два світу. Чад Фоулер вважає, що концепція вибору між одним і іншим безглузда сама по собі:
Вам не варто надто турбуватися про вибір, він здійснюється за вас завдяки можливості вбудовувати Sinatra додатки у додатки на Rails 3.
Джоффрі Грозенбах вважає, що це надасть додаткам більш модульний вигляд:
Багато людей вбудовують Sinatra додатки у додатки на Rails. Це імітує дизайн фреймворку Django, де (основне) додаток складається з безлічі більш дрібних додатків, кожне з яких відповідає за певну частину в ньому (і часто можуть бути повторно використані іншими додатками).
Девід Хайнемайєр Хенссон також вважає, що це було б непоганим способом для виконання завдань:
У вас навіть може бути микроприложение на Sinatra всередині Rails структури. Таке застосовується на Github для вирішення декількох завдань. Чудова модель.
Рік Олсон пояснює наскільки часто на GitHub використовується ця пара в тандемі:
Я дуже радий, що Rack і Sinatra настільки тісно інтегруються з [Rails]. Замість того, щоб підлаштовувати Rails під свою волю заради специфічної можливості, ви можете перенаправити запит на Sinatra або кінцеву точку Rack і виконати саме те що необхідно.
Всі погодяться з тим, що для кожного з цих двох фрейморков в екосистемі Ruby є певне місце. По суті, вони чудово працюють, і певною мірою доповнюють один одного безліччю способів. Схоже, чимало людей вважає, що найкращим чином два фреймворку працюють саме разом, і задовольняють різні потреби в загальному плані. Різні види розробників здійснюють свій вибір за смаком якщо рішення лежить у полі сполучення інструментів. Кожен з двох робить лише те, з чим добре справляється, і кожен є винятковим прикладом хорошої практики; настільки хорошою, що ці інструменти були скопійовані в інші мови незліченна безліч разів. Джон Нунемакер з GitHub красиво і лаконічно це підсумував:
У кожного з них є своє місце. Rails буде кращим варіантом у тому випадку, якщо вам просто необхідно розібратися із завданням. Для простих речей кращим вибором буде Sinatra, а також тоді, коли ви хочете все контролювати та дотримуватися власних поглядів.
Нам, як спільноті, невимовно пощастило, що у нас є настільки добре розроблені інструменти, з такою гарною підтримкою, та ще й у відкритому коді. І Rails і Sinatra чудово справляються з усіма аспектам завдань, тому можна з упевненістю сказати, що завдяки їм у нас є найкраще з двох світів.

А ви як вважаєте ви користуєтеся кожним з них, або віддаєте перевагу один іншому? Чи Думали ви над створенням власного фреймворку, як альтернативу Rails? Залиште коментар внизу.

Джерело: Хабрахабр

0 коментарів

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