[Перевод] 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? Оставьте внизу комментарий.
Оригинал статьи можно посмотреть здесь.
