Год за годом мир Руби благословлялся - завидное количество фреймворков для разработки веб-приложений.
Однако двое из них в последнее время стали явными лидерами в этой области.
Большинство читателей этого сайта слышали о Рубин на рельсах .
Он был разработан Дэвид Хайнемайер Хенссон в 2004 году и представляет собой структуру MVC, которая помогает повысить производительность и сделать разработчиков счастливыми.
Синатра был создан Блейком Мизерани в 2007 году и представляет собой предметно-ориентированный язык, который оборачивает легкий уровень HTTP-запросов и ответов поверх Rack. Его минималистичный подход изящн и элегантен.
Статистика по RubyGems.org ясно показывает, насколько популярны оба эти фреймворка: Rails был загружен 7 миллионов раз, а Sinatra — 1,5 миллиона.
Именно Rails привел меня в веб-разработку на Ruby, но за последние несколько лет я гораздо чаще использовал Sinatra (а теперь 7 причин, почему я люблю его ).
Фактически оказалось, что все, что мне нужно для создания приложения, — это Синатра и несколько драгоценных камней.
Это заставило меня задуматься о том, можно ли взяться за какой-нибудь проект с Синатрой.
Когда лучше всего использовать Sinatra, а когда Rails — лучший выбор? Пытаясь найти ответ на этот вопрос, я спросил известных разработчиков Ruby, что они думают по этому поводу.
Константин Хаас , который в настоящее время поддерживает Sinatra, считает, что каждый из инструментов соответствует требованиям приложений своего типа:
Каждый из них решает свой набор задач, хотя на самом деле они взаимодействуют в этой области.Дэвид Хайнемайер Хенссон также считает, что у каждого есть свое место, но считает, что при выборе между ними следует руководствоваться размером вашего приложения:В то время как Rails — это платформа, ориентированная на написание веб-приложений на основе моделей, Sinatra — это библиотека для обработки HTTP на стороне сервера.
Если вы думаете о HTTP-запросах/ответах, то Sinatra — идеальный инструмент. Если вам нужна полная интеграция и как можно больше шаблонов библиотек, то Rails — отличный выбор для вас.
Sinatra отлично подходит для микростиля, но Rails — нет. Пока вы придерживаетесь минимализма, Sinatra превосходит Rails. Если пойти дальше, Rails превзойдет Синатру.Действительно, большинство людей, вероятно, согласятся, что Rails больше ориентирован на крупные проекты, а Sinatra лучше подходит для микроприложений и API. Дэвид продолжает, объясняя правило выбора между Rails и Sinatra, которое он усвоил с опытом:
Если ваше приложение имеет 5-10 конечных точек, то выгодно использовать Sinatra для индивидуального решения.Рик Олсон С Гитхаб подтверждает, что Sinatra действительно отличный выбор для небольших проектов:Особенно когда сама структура контроллера умещается на 1-2 страницах кода, отлично, если ее можно запустить в одном файле.
Sinatra действительно отлично работает как API, а также на небольших сайтах (внутренние приложения, задания Github и т. д.).Дэвид Хайнемейер Ханссон объясняет, почему Rails становится таким хорошим выбором, когда дело доходит до создания крупных веб-приложений:
Rails позволяет людям выбирать между лучшими технологиями («лучшими» называют это я и сообщество Rails), и именно в этом заключается большая часть его успеха.Константин Хаас делится своим энтузиазмом по поводу Rails и его философии:Я меняю Rails каждую неделю, чтобы лучше соответствовать тому, что я считаю идеальной средой.
.
Я люблю Рейлс.Приобретение функций, которые вам на самом деле не нужны в Rails, определенно требует затрат, но последняя компенсируется тем фактом, что вы получаете большое количество функций, в которых Действительно нуждаться.Rails изменил наше представление о веб-приложениях.
Rails решает за вас проблемы, которые не может решить Sinatra, поскольку он может делать больше предположений о вашем приложении.
Все уже настроено для вас, нужно вам это или нет, самый большой недостаток архитектуры Rails — это предположение, что все должно обрабатываться одним инструментом.
В конце концов, это может окупиться, особенно если речь идет о большом проекте.
Однако не все согласятся, что большой проект можно реализовать только на Rails. Джеффри Грозенбах от Скринкасты Peepcode считает, что это «устаревшая точка зрения, которая была верна только для Синатры в 2008 году, но определенно не в наши дни».
Он заметил отличное применение Gaug.es , построенный на Sinatra, как пример, который доказывает, что он (Sinatra) более чем пригоден для создания оперативных масштабных сайтов.
Несмотря на вышесказанное, Константин Хаас указывает на потенциальную проблему при использовании Sinatra для создания больших приложений:
Создание более сложных приложений с помощью Sinatra (или, скорее, использование Sinatra среди других приложений) заставит разработчика тратить значительно больше времени на обдумывание архитектуры и инструментов.Некоторые разработчики, вероятно, увидят в этом преимущество, если предпочтут иметь строгий контроль над тем, что происходит в их приложении, и знать, как все это сочетается друг с другом.Это одновременно преимущество и недостаток.
Джеффри Грозенбах считает, что эта жертва окупается:
Стабильность — величайшее преимущество Синатры.Далее он объясняет, почему Sinatra — отличный кандидат для создания приложений:Вы жертвуете своими собственными проектными решениями ради удобства нескольких генераторов Rails. Написание на Sinatra может обеспечить разработчикам и бизнес-API стабильность, поскольку структура меняется редко.
У вас есть свой код, и вы сами решаете, когда его изменить.
Каждое мое новое приложение начинается с Sinatra и, обычно, я прихожу к выводу, что кроме Sinatra вместе с несколькими плагинами Rack мне больше ничего не нужно, небольшая библиотека CouchDB и Backbone.js в качестве фронтенда.Су Шеонг Чанг от Yahoo и автор Клонирование интернет-приложений с помощью Ruby следует простой модели разработки:
Синатра делает все, что мне нужно, на базовой платформе, а все остальное либо уже предоставлено облачными платформами и сервисами (например, Heroku и ее экосистема аддонов), либо я могу реализовать это с помощью гемов.Фактически, эту идею можно использовать как лучший подход к использованию Sinatra — создание собственной пользовательской среды, которая точно соответствует вашим потребностям.А для всего остального я могу написать код сам.
Начните с Sinatra, затем добавьте драгоценные камни, реализующие функции, необходимые вам для создания собственной пользовательской платформы.
Что-то подобное реализовано в проекте Падрино .
Дэвид Хайнемайер Ханссон не видит в этом смысла:
Разбивать все на мелкие кусочки и заставлять разработчиков собирать все самостоятельно — это полная противоположность всему, для чего был создан Rails, и тому, как он выиграл фреймворк.Хотя контроль над тем, что происходит внутри вашего приложения, может быть хорошей идеей, Константин Хаазе предупреждает, что это может отнять у вас много времени:На достижение этой цели были потрачены десятки тысяч человеко-часов.
Попытка воспроизвести это – глупая затея.
Главный недостаток Синатры, который не решает для вас проблему, состоит именно в том, что Синатра ее не решает. Вы должны разобраться в этом сами.А если у разработчиков ограничен бюджет, то этого времени у них может просто не быть.Это может привести к тому, что вы потратите неоправданно много времени, пытаясь решить эту проблему.
Дэвид Хайнемайер Ханссон обеспокоен тем, что использование Синатры в попытке изобрести велосипед рискует потерять огромное количество времени:
Скорее всего, вся работа, которую вам придется проделать, чтобы воспроизвести решения, уже представленные в Rails, немедленно подорвет простоту использования Sinatra. Мне жаль человека, который пытается построить Basecamp, GitHub, Shopify или любое другое крупное приложение только на Sinatra. Rails — огромный и запутанный инструмент, поскольку он содержит решения большинства проблем, с которыми сталкивается большинство людей при работе над созданием приложения такого размера.Райан Бейтс, ведущий Железнодорожные перевозки считает, что преимуществом использования Rails является экономия времени при запуске проекта с нуля:Попытка воссоздать все эти решения вручную совсем не проста.
Стандартное приложение Rails предоставляет многое из того, что мне нужно, но для этого потребуется дополнительная установка в Sinatra. А это дает дополнительную скорость при разработке на Rails.Такого же мнения придерживается Рик Олсон, который считает, что Rails облегчил реализацию проекта GitHub.
Я думаю, что в первый год Rails был основным инструментом для основателей [GitHub].Чад Фаулер (сооснователь RubyConf) называет мантру Rails о «конфигурационном соглашении» как еще одну причину, по которой Rails ускоряет разработку крупных проектов:Они смогли воспользоваться некоторыми высокоуровневыми функциями Rails и быстро выполнить итерацию.
Генераторы и структуры Rails предоставляют соглашения, которых нет в Sinatra.Проблема в том, что эти соглашения иногда сродни смирительной рубашке, указывает на такие случаи Рик Олсон:
Rails хорош, если вы принимаете его догматические условности и придерживаетесь «золотого пути».В отличие от него, у Синатры нет никаких ограничений, Сатиш Талим от Рубиовое обучение дал отличную цитату Арона Кинта , что объясняет это:
«Синатра следует абстрактному шаблону: NNNVSH («Нам не нужны вонючие шаблоны»).Там наиболее привлекателен Sinatra, который позволяет определить, как и как структурировать приложение от начала до конца.NNNVSH означает, что Sinatra более чем гибок и не предопределяет, как вы будете организовывать предметную область или бизнес-логику.
Он не имеет явной структуры папок, абстракции базы данных по умолчанию и ограничений на то, где и как его можно использовать».
Использование Синатры может принести свободу, поскольку вы не ограничены размером, структурой или рабочим процессом.
Вы можете создать API, веб-приложение или упаковать свой код в гем.
Для некоторых может стать сюрпризом, что Дэвиду Хайнемайеру Ханссону также нравится простота Синатры:
Раньше я использовал Sinatra, и он мне очень понравился.Так есть ли у Sinatra преимущество, которое он хотел бы привнести в Rails?Он предлагает совершенно другой подход, который отлично подходит для решения задач гораздо меньшего круга, но решает их очень хорошо.
На самом деле в Sinatra нет ничего такого, что заставило бы меня перепроектировать Rails по-другому.Однако он все же признает, что Rails почти полностью скопировал одну из самых крутых возможностей Синатры:
Мы хотели добавить в Rails однофайловый режим, но передумал, зачем нам оптимизировать то, что Sinatra и так хорошо делает?Нет сомнений в том, что Rails имеет массу возможностей, но часто некоторые из них вам не нужны или которые работают не совсем так, как вы хотите.
Как отмечает Чад Фаулер, в Rails 3 была предпринята попытка сгладить эту проблему, насколько это возможно, путем разделения некоторых функций, что может привести к созданию более легкого и настраиваемого продукта:
Rails сам по себе не так уж и тяжел, особенно если учесть его текущую возможность масштабирования по желанию.В Rails 3 представлено множество опций конфигурации, которые позволяют адаптировать ваше приложение под задачу, которую вам необходимо выполнить.
Хотя навести порядок можно, Константин Хаас предупреждает, что оставить все как есть часто кажется слишком заманчивым, что приводит к раздуванию:
В моей практике приложения Rails часто становятся одним монолитным приложением.Дэвид Хайнемайер Хенссон не видит в этом проблемы и считает, что независимо от того, используете вы все функции или нет, Rails подойдет в любом случае:[Отказ от Rails] приводит к модульности, гибкости, скорости тестирования и масштабируемости.
Однако вы можете добиться той же архитектуры, если тщательно проектируете свои Rails-приложения, но дело в том, что поступить иначе (не делать этого) слишком заманчиво.
Физическое удаление фрагмента кода Rails, который вы не используете, не принесет ничего полезного.Rails становится легче, и Sinatra показал, что он может справляться с тяжелыми задачами, а это значит, что они все больше переплетаются.Никто не заставляет вас использовать все возможности.
[Многие функции Rails] совершенно необязательны и могут быть полностью отключены, если они вас сильно беспокоят.
Чад Фаулер считает, что и Sinatra, и Rails действительно можно использовать в самых разных проектах:
Я думаю, что на самом деле каждый из них можно использовать в любом из противоположных случаев.В целом все согласятся, что «нужно выбрать правильный инструмент для работы», но их сочетание означает, что решение часто сводится к личному выбору.Я думаю, в конце концов, это субъективный выбор.
Sinatra может дать вам больше контроля над архитектурой, но стоят ли дополнительные усилия вашего (или, что более важно, вашего клиента) времени? Райан Бейтс подводит итог относительно типов личности и того, какую структуру они выбирают:
Я думаю, в конечном итоге это зависит от того, предпочитаете ли вы начинать с легкого и добавлять по мере необходимости или начинать с тяжелого, а затем удалять по мере необходимости.Джеффри Грозенбах предполагает, что существует два совершенно разных типа разработчиков:
Я думаю, что среди разработчиков Ruby есть существенная разница: есть те, кто предпочитает небольшой размер, легкий, быстрый, явный и расширяемый; а есть те, кто предпочитает фреймворки с полным набором возможностей.Но, возможно, вам не придется выбирать между ними.Sinatra удовлетворяет потребности первого, а Rails — второго.
Так что я не думаю, что Синатра вытеснит Rails. Это просто другая философия, которая нравится разработчикам определенного типа.
Автор, Дэйв Кеннеди , участник Ruby Source, отмечает, что Rails и Sinatra в целом неплохо работают вместе:
Если в процессе разработки 2 фреймворка начали дополнять друг друга, то это значит, что я сейчас работаю над мультитенантным приложением, которое интенсивно использует Sinatra внутри Rails, классная штука.Многие люди поняли, что благодаря возможности встраивать Sinatra в приложения Rails 3+ вы действительно можете получить лучшее из обоих миров.Синатра позволил мне модульизировать мое приложение, чего раньше я не мог сделать просто.
Чад Фаулер считает, что концепция выбора между одним и другим бессмысленна сама по себе:
Вам не придется слишком беспокоиться о выборе; это сделано за вас благодаря возможности встраивать приложения Sinatra в приложения Rails 3.Джеффри Грозенбах считает, что это придаст приложениям более модульный вид:
Многие люди встраивают приложения Sinatra в приложения Rails. Это имитирует структуру платформы Django, где (основное) приложение состоит из множества более мелких приложений, каждое из которых отвечает за определенную его часть (и часто может повторно использоваться другими приложениями).Дэвид Хайнемайер Ханссон также считает, что это будет хорошим способом выполнить поставленные задачи:
Вы даже можете иметь микроприложение Sinatra внутри платформы Rails. Это используется на Github для решения нескольких проблем.Рик Олсон объясняет, как часто эта пара используется в тандеме на GitHub:Замечательная модель.
Я очень рад, что Рэк и Синатра так тесно интегрируются с [Rails].Все согласятся, что каждая из этих двух платформ занимает особое место в экосистеме Ruby. По сути, они хорошо работают вместе и в определенной степени во многом дополняют друг друга.Вместо того, чтобы подчинять Rails своей воле для реализации конкретной функции, вы можете перенаправить запрос в Sinatra или конечную точку Rack и сделать именно то, что вам нужно.
Многие люди, похоже, считают, что эти две структуры лучше всего работают вместе и в общем смысле служат различным потребностям.
Разные типы разработчиков делают свой выбор по вкусу, если решение лежит в области сопряжения инструментов.
Каждый из двоих делает только то, что у него хорошо получается, и каждый представляет собой исключительный пример хорошей практики; настолько хорош, что эти инструменты копировались на другие языки бесчисленное количество раз.
Джон Нунемейкер GitHub красиво и лаконично резюмирует это:
У каждого из них есть свое место.Нам, как сообществу, невероятно повезло иметь такие хорошо развитые инструменты, такую хорошую поддержку и открытый исходный код. И Rails, и Sinatra превосходно справляются со всеми аспектами задачи, поэтому можно с уверенностью сказать, что благодаря им мы имеем лучшее из обоих миров.Rails — лучший вариант, если вам просто нужно разобраться в проблеме.
Для простых вещей Синатра — лучший выбор, а также когда вы хотите все контролировать и придерживаться собственных взглядов.
Как вы думаете — используете ли вы каждый из них или предпочитаете один другому? Задумывались ли вы о создании собственного фреймворка в качестве альтернативы Rails? Оставьте комментарий ниже.
Оригинал статьи можно посмотреть Здесь .
Теги: #ruby #Sinatra #ruby onrails #Разработка сайтов #ruby #ruby onrails
-
Защита Vps-Сервера На Базе Windows 2008 R2
19 Oct, 24 -
Это Позор!
19 Oct, 24 -
Бесплатная Сотовая Связь Началась!
19 Oct, 24
