Решил тут портировать одно PHP приложение на Ruby. Не сколько с целью портировать для практического использования, сколько с целью получить опыт. Сначала начал делать как CGI приложение, отлаживая в консоли. Потом захотелось увидеть в браузере, увидел, захотелось потестировать на скорость — ужаснулся. Решил искать варианты. Вот, что нашёл:
1. TCPServer — как-то не вдохновляет
2. Различные веб-сервера и модули к апачу/nginx — понял, что разницы особой нет
3. Rack — из-за него и нет разницы :) как я понял аналог WSGI в Python
4. Sinatra — вроде всё просто и сходу не скажешь чего не хватает, похож на WebOb с первого взгляда или типа голого PHP :) Написал и сразу понял чего не хватает — работы с формами и привязка их к БД
5. RoR — как-то всё сильно инкапсулировано, по-моему для первого знакомства мало годится, это как начинать изучать PHP с symfony или Yii. Вроде едет, а что под капотом происходит…
Вот стою на распутье, как быть дальше. 1 и 2 отпадает — raw HTTP обрабатывать не хочется. Колеблюсь между Rack и Synatra. Или всё же Rails? :-/ Что больше научит решать различные реальные проблемы, но в тоже время не создавая искусственных? Может ещё какой вариант?
Вы же сами ответили на свой вопрос.
У Вас по сути стоит выбор между 3, 4 и 5
4 — сразу высказали два минуса, 5 — сразу обречли на непригодность использования в качестве знакомства… Какой вариант остался?
У 3 эти же минусы, что у 4, плюс ещё много :) Плюс не исключаю мысли, что ruby way заключается не только в DRY, но и в повсеместном использовании готовых компонентов, без понимания как они собственно работают. Мой way обычно такой — написать свой «велосипед», зайти в тупик, поискать аналоги, заценить их код (уже с пониманием какие проблемы как он решает) и или выбрать один из аналогов, или в свой велосипед добавить понравившиеся идеи.
Вы просто так описали минусы четвертого что кажется что в третьем этого нет =) Я вообще не рубист, но в любом случае считаю что на рельсы сначала нельзя становиться, в любом языке надо сперва ощутить сам язык а уж потом инстументы для конкретных задач. Так что я б попробовал начать с чего-то простого, оценил бы все прелести конкретно языка, и затем уж лез бы в дебри.
Rack — интерфейс между веб-сервером и веб-фреймворком. Стандарт де-факто. Без него никуда.
Passenger — модуль для apache/nginx для запуска Rack.
Thin, Ebb,… — веб-сервера, не требующие apache/nginx.
Sinatra/Padrino/Rango/RoR/… — веб-фреймворк.
Я бы начал с Sinatra + Thin.
Потом можно подключить к Siantra Padrino (по функциональности практически Rails, но гораздо более модульный и человеческий), и постепенно на него перейти совсем.
RoR всё равно нужно хорошо знать.
Для продакшн применения используют разные варианты. На текущем у меня nginx+Passenger+RoR.
Стоит также изучить:
— DataMapper/ActiveRecord/Sequel для связи с БД;
— HAML/Erb для шаблонов;
— Compass/SASS для шаблонов CSS.
Вы просто не поняли всей красоты Синатры. Это фреймворк который не навязывает вам выбор ORM и шаблонизатора. Он даже не навязывает вам паттерн MVC (Но вы можете его использовать). Вот неплохой пример приложения на Sinatra.
Так же могу посоветовать посмотреть на фреймворк Padrino. Как написано у них на сайте, это «The Elegant Ruby Web Framework». И это правда. Padrino, как и Sinatra не навязывает используемые библиотеки. Так вы можете самостоятельно выбрать ORM, шаблонизатор html и css, тип базы данных (поддерживаются не только реляционные БД) и библиотеки для тестирования. При этом Padrino имеет генераторы в стиле Rails и по сравнению с Синатрой сильно сокращает рутину.
Я знаю что такое не full-stack фреймворки :) По сути выбираю между практически CGI, чтобы более плотно изучить на практике (читай — написать самому) разные внутренности типа роутингов, шаблонизаторов, ORM или всё же воспользоваться готовыми. Прочитал статьи — стал склоняться к Cинатре (в уме дав себе обещание не только использовать API, но и смотреть исходники того, что использую). А тут вы искушаете Падрином (или -ой? :) ), учитывая что он работает поверх Синатры и его модули могут использовать в Синатра-проектах без использования самого Падрина (или -ы? ). Спасибо за ответ, пошёл читать гайды по Padrino
