Sinatra as backend (API) for Rails app or padrino or any hybrid solution?

Question

Is it a good idea to build backend APIs in Sinatra for Rails app. Or is it better to use Padrino? I want to have my backend provides API as service, so that anytime, if I have to develop same app for any client, I can use that back-end API (web services). What is the best approach? My goal is to expose back-end as web services and even rails uses it for webapp. What are the disadvantages or advantage of different approaches?

Answer 1

Having backend as a service is a good approach, as it leads to better decoupled code. Whether to use Sinatra or Padrino, I think, depends more on how much admin tasks the backend should handle.

If backend is API-only, then probably Sinatra together with some API gem (e.g. RABL) will be easiest.

But if you want the backend to wield it's own interface for administrative tasks (or even for emergency jobs that are not meant to be available on front-end), then Padrino with the same gem could be better approach, as it handles a bit more complex webapps.

EDIT: an example of RABL vs Sinatra plain JSON output:

Lets take the simple example from RABL README. To get the output like:

[{  "post" :
  {
    "id" : 5, title: "...", subject: "...",
    "user" : { full_name : "..." },
    "read" : true
  }
}]

You would need to put this in Sinatra:

get '/' do
  posts = # find some posts somewhere
  user =  # detect current user
  json posts.map do |post|
    { post:
      {
        id: post.id,
        title: post.title,
        subject: post.subject,
        user: post.user.full_name
        read: post.read_by?(user)
      }
    }
  end
end

But RABL is a bit more declarative, so instead, you just write:

get '/' do
  @posts = # find some posts
  @user  = # detect current user
end

# app/views/posts/index.rabl
collection @posts
attributes :id, :title, :subject
child(:user) { attributes :full_name }
node(:read) { |post| post.read_by?(@user) }

I tend to think that the plain JSON output gets out of hands pretty soon, but with RABL you can break out your JSON with partials and inheritance and keep it more maintainable.

Answer 2

While I will not present any code here, following are few things I would like to suggest.

Is it a good idea to build backend APIs in Sinatra for Rails app. Or is it better to use Padrino?

In case your app is going to talk to DB and other similar aspect, I suggest Padrino. Padrino will save you time. Using Sinatra, you will end up configuring stack around it. Padrino provides a lot of flexibility in terms of generators and helpers which allows you to cherry pick stack and develop your application.

I want to have my backend provides API as service, so that anytime, if I have to develop same app for any client, I can use that back-end API (web services).

I can't talk about SOAP, as I have not worked on it. REST is more popular these days. You can consider something like Grape instead of directly using Sinatra or Padrino to map routes.

Quote from Grape Doc

Grape is a REST-like API micro-framework for Ruby. It's designed to run on Rack or complement existing web application frameworks such as Rails and Sinatra by providing a simple DSL to easily develop RESTful APIs. It has built-in support for common conventions, including multiple formats, subdomain/prefix restriction, content negotiation, versioning and much more.

What is the best approach?

This is a very open ended question. Best would depend on a lot of factors.

My goal is to expose back-end as web services and even rails uses it for webapp. What are the disadvantages or advantage of different approaches?

Certainly this has significant advantage if APIs are to be consumed by other applications apart from your web app. For example Mobile apps.

Disadvantage that I see is network latency and network chattiness.

But then with high number of volumes this should work great. If you plan to scale out app on multiple instances you may want to consider few things while coding the app. For example session management.