Grape: no single rails

In this post, I’d like to introduce you to Grape, a web framework written in ruby, designed for quick and easy API development, and also a little discussion on the fate of Rails in light of the latest trends in web development.

Ruby = Ruby On Rails

Somehow it happened that when mentioning ruby ​​as a means of web development (and simply as a scripted YaP), many people who have something to do with this very web development appear in the head if not a logo with notorious white railings a red background, the magic phrase Ruby on Rails for sure.
I do not argue whether it is good or bad - this article is not for an argument. One thing I can say with certainty - RoR has had a huge impact on the development of web frameworks in general, and this contribution is extremely difficult to overestimate.

BUT

But life does not stand still.
The web is becoming dynamic, mobile applications are becoming more and more important;
Yes, and the sites themselves need a qualitatively new approach to the organization of user interactions and content delivery.
AngularJS, Ember, Meteor.js, Derby.js - technology, anticipating another breakthrough in site building, which can be compared with the "invention" of AJAX in the good old days.
Ruby developers need a powerful yet easy-to-learn API development tool that RoR once became for regular websites.
')

Let's get down to business!

Indeed, enough reasoning. Meet - Grape
This is a framework sharpened by API development, no Swiss knives.
But we must pay tribute, he knows how to do the API very well.
I will try to list its main advantages:

1. DSL, sharpened by the description of the API
2. API versioning out of the box
3. parameterization of methods with built-in validation
4. automatic generation of OPTIONS (who met with CORS - will appreciate)
5. transparent work with API formats
6. built-in DSL for documentation

This is not a complete list of tools that facilitate the life of an API developer when it uses Grape.

Code time

To begin with, I’ll give an example of a simple application that will return {hello: 'world'} to the address /hello/world.json

Gemfile

source 'https://rubygems.org' gem 'grape', github: 'intridea/grape' gem 'rack', '~> 1.5.2' gem 'thin', '~> 1.6.2' 

hello_world.rb

 require 'grape' class HelloWorld < Grape::API format :json namespace :hello do get :world do {hello: 'world'} end end end 

config.ru

 require_relative 'hello_world' run HelloWorld 

On my i5 with 16 GB of memory and HDD, this application starts somewhere in 400-700 ms. Here is a list of used gems:

 Using i18n 0.6.11 Using json 1.8.1 Using minitest 5.4.1 Using thread_safe 0.3.4 Using tzinfo 1.2.2 Using activesupport 4.1.6 Using descendants_tracker 0.0.4 Using ice_nine 0.11.0 Using axiom-types 0.1.1 Using builder 3.2.2 Using coercible 1.0.0 Using daemons 1.1.9 Using equalizer 0.0.9 Using eventmachine 1.0.3 Using hashie 3.3.1 Using multi_json 1.10.1 Using multi_xml 0.5.5 Using rack 1.5.2 Using rack-accept 0.4.5 Using rack-mount 0.8.3 Using virtus 1.0.3 Using grape 0.9.1 from git://github.com/intridea/grape.git (at master) Using thin 1.6.2 

As you can see, in Grape there is a wonderful thing called namespace. It is a group, resource, resources, segment - all for the convenience of reading the code.
However, it can be used without parameters. It would seem, why? Here is an example:

 namespace :authorized do before { authorize! } get :some_secret_data ... end group do before { authorize! } get :some_secret_data ... end 

It's like in the movie - “everything that happened in Las Vegas - stays in Las Vegas.”
Within groups, as well as namespaces, you can define before and after blocks that will be executed only for the routes specified in these groups (and deeper).

Here is an example demonstrating the use of parameters:

 params do requires :first_name, type: String requires :last_name, type: String optional :birth_date, type: DateTime end post :register do ... end 

As for me, so it is clear without words. Management will not even get to the route if the request does not provide parameters that meet the described conditions. The most wonderful thing is that all of these with minimal modifications can be used to document the API. For example:

 desc 'User signup' params do requires :first_name, type: String, desc: 'First name' requires :last_name, type: String, desc: 'Last name' optional :birth_date, type: DateTime, desc: 'Date of birth' end post :register do ... end 

We immediately kill a whole bunch of hares - the code is documented on the spot; connecting the grape-swagger we get the swagger-compatible documentation. Changed the code - the documentation has changed.

One of the many wonderful pieces that conquered me in Grape is mount. Allows you to mount the previously described API in a new place:

mount.rb

 class Mount < Grape::API get :mounted do {mounted: true} end end 

mount.rb

 require 'grape' require_relative 'mount' class HelloWorld < Grape::API format :json namespace :hello do mount Mount get :world do {hello: 'world'} end end end 

As we all understand, our route from the Mount class will be available at /hello/mounted.json

"I am plagued by vague doubts ..."

Of course, the volume of the average article, which does not cause the hawler of a stable yawning reflex, is hardly enough to talk about all the pros and cons of the framework. My task in the first place was to cause interest in you - the project documentation is not bad, difficulties with further study should not arise.
Also on the githab page you can find a list of gems that can be used in conjunction with grape.

Epilogue

Until recently, the project had a slight problem with the automatic reloading of the modified code in dev mode. All Rails developers are used to this and in my opinion this is a must have feature. In issues on the githaba, this problem was voiced several times and some solutions were suggested on Rack :: Reloader for use in conjunction with Rails.
I allow myself to mention my own solution, which saw the light just a couple of weeks ago, namely the grape-reload gem, intended for use in plain-rack stacks.
For grape version 0.9.0 and earlier, you can use the version of the gem 0.0.3, for the later and master framework branches, use the master branch of the heme repository.

If you are interested in further articles on this framework - do not forget to mention this in the contact list. All ruby, posony!

PS In the near future I will write an article on creating an API for todo-lists, using the database. I admit that from this introductory article it is not clear what is the difference between this framework and Rails and why I do not compare it with Sinatra.
Also in the next article I will try to make a benchmark application on ActiveSupport :: Metal and Grape.