Pull to refresh

Comments 28

Из вашей статьи не понятно, чем это хозяйство лучше rails с гемами для построения API. Сделали бы какое-то сравнение, какие плюсы, какие минусы. А пока похоже на перевод туториала, что не так интересно.
Да собственно лучше только тем, что нет кучи middleware из коробки. Настолько я помню Grape появился раньше чем ActiveController::Metal. Ну и в сферическом вакуме запрос быстрее проходит через приложение.
Странно, что автор сравнивает Grape с Ruby on Rails, а не с Sinatra, который как раз используют когда надо пострелять по воробьям. Я не уверен, что если производительность критична, Grape – хороший выбор. Я, например, в таком случае писал бы на Go, ну или на NodeJS.
На Grape быстрее чем на Go и NodeJS написать законченный проект.

С Sinatra сранивать глупо потому, что синатра совсем уж голая относительно Grape. Grape все же удобный фрэимворк для API, легко можно замаунтить к приложение с рельсой если хочется.
Sinatra точно так же легко можно замаунтить в рельсы. Grape кроме этого существенно тормознее чем Sinatra
Так любое Rack приложение можно замаунтить в любом другом Rack приложении.
Пока основное отличие которое вижу — больший упор на конфигурирование. И да, думаю grape лучше сравнивать с sinatra или почившем espresso.
На hello worldах все фреймворки хороши.
А производительность то какая будет? Over 5000000000...e hello world'ов в секунду…
Основная фишка — заточенность и DSL? А как на тему реюза имеющегося кода?

Если в том же RoR'е есть набор моделек — оно оттуда без б подключается?

ps: Я не силён в деталях ruby-стэка
подключаете ActiveRecord и все
Не совсем понял, что вы имеете в виду под реюзом кода. Случай, когда Grape подключается к Rails и использует его модели? Если да, то это без проблем.
Я в первую очередь хотел показать, как можно жить без Rails и не отказывать себе ни в чем, хотя бы а рамках написания API.
Мне кажется без асинхронного программирования такой фреймворк имеет мало смысла.
Это вы зря, конечно. Но если вам хочется полной асинхронности, то я постараюсь в следующем посте сделать пример с асинхронным sleep() внутри роутов.
А к БД доступ то же будет асинхронный?
Просто красиво отдать данные это пол дела… их ещё ведь надо откуда то забрать.
Да, например mysql2, да и любой, поддерживающий eventmachine. Из gemfile видно, что у автора поста thin в ходу.
Это не такая тривиальная задача. Обычно sleep останавливает всю EM. Вроде как реализация sleep на fiber'ах есть в em-synchrony, но работает ли она из коробки не помню.
Работает, но как? Если поставить sleep на десять секунд, сделать вызов, и ещё один через пять секунд, ответ на второй приходит через пять или через десять секунд после первого?

P.S. Не совсем понимаю смысл вашего смайлика. Вы смщённо улыбаетесь, шутите, нервно улыбаетесь, троллите, или просто по жизни весёлый человек?
Если я правильно понял, решить проблему перезагрузки можно с помощью shotgun и ActiveSupport::Dependencies.autoload_paths?
Зависит от того, насколько вы терпеливы. Shotgun на каждый запрос будет заново загружать файлы проекта — если их у вас не 2 а 20, то это примерно 3 секунды.
Из-за специфики кода Grape его нелья перезагружать просто выгрузкой объявленных констант и повторным require изменившегося файла.
Когда я начал свои изыскания в этом вопросе, я первым делом прицепил Grape к Padrino, у которого достаточно неплохой релоадер. Это сработает в определенных пределах — простое приложение типа этого HelloWorld будет перезагружаться, но начнут задваиваться роуты — это можно увидеть подключив grape-swagger. Потом я попытался пропатчить Grape::API, чтобы заставить его нормально работать с Padrino::Reloader — то, что получилось в итоге, по времени релоада мало отличалось от shotgun.
Поэтому я написал отдельный гем, который делает это с учетом специфики Grape — он делает кучу манки-патча Grape::API класса для dev-окружения.
Можете создать тикет с задваиванием роутов на github.com/padrino/padrino-framework и выложить пример сломанного проекта? Я разработчик Padrino::Reloader.
Может быть вы меня не совсем правильно поняли — задваиваются роуты именно в случае релоада классов, унаследованных от Grape. Это не ошибка Padrino::Reloader, так Grape устроен.
Для view, часто используют джем rabl в связке с Grape. Я как-то делал тестовый проект, с описанием api для puzzless.com
Использовал grape, rack, rabl, AR. [source]
Хорошее решение. Тоже были мысли использовать grape без рельсов. Воспользуюсь вашими наработками, если вы не против.)
Да, на то он и open source (:

А вообще, если есть уже готовое рельсовое приложение и нужно к нему написать API, то я бы не стал заморачиваться с Grape, Sinatra или еще чем-то, а делал бы этот API частью приложение.
В рамках большого проекта restify очень уж неудобен. Express убивает всех зайцев, благо сейчас модулей выше крыши, от тех же strongloop. И если посмотреть исходники restify — там хаос, чего не встретишь в express. И все выше перечисленные плюсы в Grape из коробки есть в express: mounts, namespaces, middlewares, params!(Киллер фича express, теперь можно спокойно вешать на каждый параметр в роуте, свой middleware /hello/:_world). «Но это уже совсем другая история»©
Sign up to leave a comment.

Articles

Change theme settings