На протяжении многих лет мир Ruby наделен не только своей долей фреймворков для разработки веб-приложений. Однако недавно два из них стали явными лидерами в этой области. Большинство читателей этого сайта слышали о Ruby on Rails . Он был создан в 2004 году Дэвидом Хайнемайером Ханссоном и предоставляет MVC-фреймворк, который помогает повысить производительность при одновременном удовлетворении разработчиков. Sinatra был создан Blake Mizerany в 2007 году и является предметно-ориентированным языком, который оборачивает легкий слой HTTP-запросов и ответов поверх Rack. Это минималистичный подход, элегантный и стильный. Статистика на RubyGems.org определенно показывает, насколько популярны обе эти платформы: у Rails 7 миллионов загрузок, а у Sinatra 1,5 миллиона.
Именно из-за Rails я занялся веб-разработкой на Ruby, но в последние годы я использую Sinatra гораздо чаще (и вот 7 причин, почему я люблю его ). На самом деле я обнаружил, что Синатра, наряду с несколькими драгоценными камнями, это обычно все, что мне нужно при создании приложения. Это заставило меня задуматься, подходит ли Синатра для решения какого-либо проекта. Когда лучше всего использовать Sinatra и когда Rails является правильным выбором? Чтобы ответить на мой вопрос, я обратился к мыслям некоторых выдающихся разработчиков Ruby.
Konstantin Haase является текущим сопровождающим Sinatra и считает, что они оба обслуживают различные типы приложений:
Они оба решают разные проблемы, даже если они частично совпадают. В то время как Rails является средой, ориентированной на написание управляемых моделями веб-приложений, Sinatra — это библиотека для работы с HTTP на стороне сервера. Если вы думаете с точки зрения HTTP запросов / ответов, Sinatra является идеальным инструментом. Если вам нужна полная интеграция и как можно больше шаблонов, Rails — это то, что вам нужно.
Дэвид Хайнемайер Ханссон также считает, что им обоим есть место, но считает, что именно размер вашего приложения должен влиять на то, какое из них использовать:
Синатра отлично подходит для микро-стиля, Rails нет. Пока вы остаетесь микро, Синатра будет побеждать Рельсов. Если вы выйдете за пределы микро, Rails победит Синатру.
Фактически, большинство людей склонны согласиться с тем, что Rails лучше подходит для больших проектов, тогда как Sinatra лучше подходит для небольших микро приложений или API-интерфейсов. Далее Дэвид указывает на общее правило выбора, использовать ли Rails или Sinatra:
Если у вашего приложения 5-10 конечных точек, есть реальная выгода, если вы просто добавите свое собственное с помощью Sinatra. По сути, если вся ваша структура контроллера может поместиться в одной или двух страницах кода, запускать его в одном файле — это хорошо.
Рик Олсон из Github подтверждает, что Синатра действительно делает отличный выбор для небольших вещей:
Sinatra действительно хорошо работает для API и небольших сайтов (внутренние приложения, GitHub Jobs и т. Д.).
Дэвид Хайнемайер Ханссон (David Heinemeier Hansson) объясняет, почему Rails является таким хорошим выбором, когда речь идет о создании больших веб-приложений:
Большая часть успеха Rails состоит в том, чтобы предоставить людям подборку лучших технологий («лучшие» определены мной и сообществом Rails)….
Я меняю Rails каждую неделю, чтобы лучше соответствовать тому, что я хочу, чтобы была идеальная структура.
Константин Хаазе разделяет его энтузиазм по поводу Rails и его философии:
Я люблю Rails. Rails подталкивает нас к тому, что мы думаем о веб-приложениях. Rails решает проблемы для вас, Sinatra никогда не может, так как она может сделать больше предположений относительно вашего приложения. Вы получаете все настроенные для вас, если вам это нужно или нет, самый большой недостаток в архитектуре Rails состоит в том, чтобы предположить, что все должно быть решено с помощью одного инструмента.
Кажется, что есть некоторые компромиссы, когда вы получаете некоторые функции, которые вам не нужны в Rails, что компенсируется тем фактом, что вы получаете множество функций, которые вам действительно нужны. Это может в конечном итоге стоить того, особенно когда речь идет о создании большого проекта. Однако не все согласны с тем, что Rails является единственным выбором для большого проекта. Джеффри Грозенбах из Peepcode Screencasts считает, что это «устаревшее представление, которое едва ли было верным для Синатры в 2008 году, но определенно не сейчас». Он выделил отличное приложение Gaug.es , которое было создано на Sinatra в качестве примера, который доказывает, что оно более чем способно построить крупномасштабную производственную площадку.
Несмотря на это, Константин Хааз подчеркивает потенциальную проблему с использованием Sinatra для создания больших приложений:
Написание более сложного приложения для Sinatra (точнее, приложения, использующего, помимо прочего, Sinatra), требует от разработчика уделять больше времени размышлениям об архитектуре и инструментах. Это и преимущество, и недостаток.
Некоторые разработчики наверняка увидят в этом преимущество, поскольку они предпочитают жесткий контроль над тем, что входит в их приложение, и понимание того, как все это сочетается. Джеффри Грозенбах считает, что это компромисс, который определенно стоит того:
Огромным преимуществом Синатры является ее стабильность. Вы торгуете удобством нескольких генераторов Rails для собственных дизайнерских решений. Письменность в Синатре может дать разработчикам и компаниям стабильность API, потому что структура редко изменяется. Вы владеете своим кодом и решаете, когда он должен измениться.
Далее он говорит, что Синатра является идеальным кандидатом, когда дело доходит до создания приложения:
Я запускаю все свои новые приложения в Sinatra и обычно обнаруживаю, что мне не нужно больше, чем Sinatra, вместе с несколькими плагинами Rack, простой библиотекой CouchDB и Backbone.js для внешнего интерфейса.
Сау Шеонг Чанг из Yahoo и автор клонирования интернет-приложений с Ruby следует аналогичной модели разработки:
Sinatra выполняет все, что мне нужно для базовой платформы, и все остальное, что мне нужно, я могу либо использовать гемы, либо уже предоставляется облачными платформами и сервисами (такими как Heroku и ее эко-система дополнений). Что-нибудь еще осталось, я могу написать это сам.
На самом деле, эта идея может быть продвинута дальше, используя Sinatra, чтобы создать собственную платформу, которая идеально соответствует вашим потребностям. Начните с Sinatra, а затем добавьте драгоценные камни, которые предоставляют функции, необходимые для создания вашей собственной платформы. В некотором смысле это то, что сделал проект Padrino .
Дэвид Хайнемайер Ханссон не видит смысла в этом:
Разбиение всего на мелкие кусочки и то, что разработчики собирают все самостоятельно, — это полная противоположность тому, что такое Rails и как он выиграл фреймворк. Десятки тысяч человеко-часов потратили на то, чтобы привести нас к этому. Попытка воспроизвести это глупое поручение.
Но хотя иметь больше контроля над тем, что входит в ваше приложение, может быть хорошей идеей, Константин Хааз предупреждает, что это может занять много вашего времени:
Самый большой недостаток в том, что Синатра не решает проблему для вас, ну, в общем, Синатра не решает проблему для вас. Вы на самом деле должны иметь дело с этой проблемой. Вы могли бы в конечном итоге тратить слишком много времени на это.
И это время, которое разработчики могут просто не иметь в своем распоряжении, если они работают с ограниченным бюджетом. Дэвид Хайнмайер Ханссон обеспокоен тем, что использование Sinatra требует тратить столько времени на попытки изобретать велосипед:
Преимущества, которые Sinatra предлагает вам в простоте, скорее всего, будут быстро компенсированы всей работой, которую вы должны выполнять для репликации решений, которые уже предоставляет Rails. Мне жаль человека, который попытался бы собрать все из Basecamp, GitHub, Shopify или любого другого крупного приложения только в Синатре. Rails вовлечен и большой, потому что он содержит решения для большинства проблем, с которыми столкнется большинство людей, создающих приложения такого масштаба. Попытка воссоздать все эти решения вручную — это антипростота.
Райан Бейтс, ведущий Railcasts, считает, что преимуществом использования Rails является экономия времени при запуске проекта с нуля:
Приложение Rails по умолчанию предоставляет много всего, что мне нужно, что требует дополнительной настройки в Sinatra. Это может привести к более быстрой разработке в Rails.
Это мнение подтверждается Риком Олсоном, который считает, что Rails упростил запуск GitHub:
Я думаю, что Rails был основным активом для основателей [GitHub] в первый год. Они смогли воспользоваться некоторыми функциями Rails более высокого уровня и быстро выполнять итерации.
Чед Фаулер (соорганизатор RubyConf) Чад Фаулер (соорганизатор RubyConf) приводит Rails в качестве еще одной причины, по которой Rails ускоряет разработку больших проектов:
Генераторы и структура Rails обеспечивают соглашения, которых нет у Синатры.
Проблема в том, что эти соглашения иногда могут казаться прямыми, как отмечает Рик Олсон:
Rails — это хорошо, если вы согласны с самоуверенными соглашениями Rails и остаетесь на «золотом пути».
Напротив, у Синатры нет никаких ограничений, как показано в этой замечательной цитате Аарона Квинта, предоставленной Сатишем Талимом из Ruby Learning :
«Синатра следует абстрактному шаблону: WDNNSP (нам не нужен вонючий шаблон). WDNNSP означает, что Sinatra не поддается гибкости и не содержит предвзятых мнений относительно организации вашего домена или бизнес-логики. У него нет неявной структуры папок, нет базы данных по умолчанию и никаких ограничений на то, как и где вы ее используете ».
Большая часть привлекательности Sinatra заключается в том, что вы можете выбрать, каким образом ваше приложение структурировано во всех отношениях. Использование Sinatra может быть полезным, поскольку вы не ограничены размером, структурой или рабочим процессом. Вы можете создать API, веб-приложение или упаковать свой код как драгоценный камень.
Некоторых может удивить, что Дэвид Хайнемайер Ханссон также фанат простоты Синатры:
Я использовал Синатру в прошлом, и мне это очень нравится. Он предлагает совершенно другой подход, который отлично подходит для гораздо меньшего объема задач, но делает это действительно хорошо.
Так есть ли что-нибудь, что Синатра приносит на стол, что он хотел бы добавить в Rails?
В Синатре нет ничего, что заставляло бы меня переделывать Rails другими способами.
Однако он признает, что Rails почти скопировал одну из самых крутых возможностей Синатры:
Мы рассмотрели возможность добавления в Rails однофайлового режима, но отклонили его, потому что зачем нам оптимизировать то, что Синатра уже делает так хорошо?
Rails, безусловно, предоставляет огромное количество функций, но часто включает в себя множество ненужных — или они работают не совсем так, как требуется. Rails 3 пытается смягчить это в максимально возможной степени, отделяя некоторые из различных функций, которые могут привести к более легкому и более настраиваемому опыту, как указывает Чед Фаулер:
Сам по себе Rails не такой уж и «тяжелый», особенно благодаря возможности в наши дни подрезать его, как вы считаете нужным.
В Rails 3 появилось множество опций конфигурации, которые позволяют адаптировать ваш опыт к вашим желаниям. Несмотря на то, что Константин Хаазе умеет вырубать флот, он предупреждает, что часто слишком заманчиво держать все это там, что приводит к вздутию:
По моему опыту, приложения на Rails часто и как одно монолитное приложение. [не использование Rails] приводит к модульности, гибкости, быстрому тестированию и масштабируемости. Тем не менее, вы можете достичь той же архитектуры при тщательном конструировании Rails-приложений, но это очень соблазнительно.
Дэвид Хайнмайер Ханссон не видит в этом проблемы и считает, что Rails хорошо подходит, используете ли вы все функции или нет:
Нет ничего практичного в физическом удалении фрагмента кода в Rails, который вы не используете. Никто не заставляет вас использовать все функции. [Многие функции в Rails] не являются обязательными и могут быть полностью отключены, если они вас потеряют неправильно.
Рельсы становятся легче, и Синатра показал, что может выполнять тяжелую работу, что означает, что между ними все больше и больше перекрытий. Чад Фаулер считает, что на самом деле и Sinatra, и Rails могут использоваться для самых разных проектов:
Я думаю, что по правде говоря, каждый может быть использован для обоих концов спектра. Я полагаю, что это в конечном итоге субъективный выбор.
Похоже, что общий консенсус заключался в том, чтобы «выбрать правильный инструмент для работы», но совпадение между этими двумя способами означает, что решение, которое использовать, часто сводится к личному выбору. Синатра может позволить вам лучше контролировать архитектуру, но являются ли дополнительные усилия хорошим использованием вашего (или, что более важно, вашего клиента) времени? Райан Бейтс резюмирует, какой тип человека с большей вероятностью выберет какую основу:
В конце концов, я думаю, это зависит от ваших предпочтений: хотите ли вы начинать легче и добавлять по мере необходимости, или начинать тяжелее и убирать что-то, чтобы сделать светлее, если это необходимо.
Джеффри Грозенбах предлагает, по сути, два разных типа разработчиков:
Я думаю, что есть огромный разрыв между разработчиками Ruby, которые предпочитают маленькие, легкие, быстрые, явные и расширяемые, и теми, кто предпочитает полнофункциональные фреймворки. Синатра обеспечивает первое, Rails предоставляет второе. Поэтому я не думаю, что Синатра вытеснит Rails. Это просто другая философия и привлекательность для определенного типа разработчика.
Но, возможно, вам не нужно выбирать один над другим. Другой автор Ruby Source Дэйв Кеннеди отмечает, что Rails и Sinatra действительно хорошо работают вместе:
Во всяком случае, недавние разработки сделали 2 рамки бесплатными. Тем не менее, я работаю над мультитенантным приложением, которое в настоящее время интенсивно использует Sinatra в приложении Rails, некоторые довольно интересные вещи. Синатра позволил мне модульно оформить свое приложение так, как я раньше не мог сделать так легко.
Многие люди отмечают, что возможность монтировать приложения Sinatra в Rails 3+ означает, что вы действительно можете получить лучшее из обоих миров. На самом деле Чад Фаулер считает, что сама концепция выбора одного из других бессмысленна:
Возможность монтировать приложения Sinatra в приложениях Rails 3 делает выбор, о котором вам не нужно особо беспокоиться.
Джеффри Грозенбах считает, что это придаст приложениям более модульный вид:
Многие люди встраивают приложения Sinatra в приложения Rails. Это имитирует дизайн фреймворка Django, где приложение состоит из множества небольших приложений, которые обрабатывают определенные части приложения (и часто могут использоваться повторно между приложениями).
Дэвид Хайнемайер Ханссон также считает, что это хороший способ сделать что-то:
Вы даже можете иметь приложения micro Sinatra внутри своей структуры Rails. GitHub имеет это для нескольких вещей. Хорошая модель.
Рик Олсон рассказывает, как GitHub часто использует пару в тандеме:
Я очень благодарен, что Rack и Sinatra так тесно интегрированы с [Rails]. Вместо того чтобы пытаться навязать Rails свою волю для конкретной функции, вы можете направить запрос к конечной точке Sinatra или Rack и делать именно то, что вам нужно.
Все согласны с тем, что в обеих экосистемах Ruby есть место для обеих этих платформ. На самом деле, они невероятно хорошо работают вместе и во многом дополняют друг друга в определенной степени. Многие люди, кажется, считают, что две структуры работают лучше всего вместе и удовлетворяют различные потребности в целом. Там, где есть некоторые совпадения, они обращаются к разным типам разработчиков. Они оба делают то, что делают так хорошо, и являются исключительными примерами хорошей практики — настолько, что они были скопированы до смерти на других языках. Это блестяще и кратко резюмировал Джон Нунемейкер из GitHub:
У них обоих есть свое место. Rails лучше, если вы просто хотите добиться своей цели. Синатра лучше подходит для простых вещей и для тех случаев, когда вы хотите все контролировать и использовать свои собственные мнения.
Как сообществу нам так повезло, что у нас есть такие хорошо разработанные инструменты, которые так хорошо поддерживаются и имеют открытый исходный код. И Sinatra, и Rails настолько хорошо охватывают все базы, что действительно дают нам лучшее из обоих миров.
Как вы думаете — вы использовали Rails и Sinatra, вы предпочитаете другим? Рассматриваете ли вы Rolling свой собственный фреймворк вместо использования Rails? Оставьте комментарий ниже.