0

Railsアプリ用にSinatraでバックエンドAPIを構築するのは良い考えですか? それともパドリーノを使ったほうがいいですか？バックエンドがサービスとして API を提供するようにしたいので、いつでも、任意のクライアントに対して同じアプリを開発する必要がある場合は、そのバックエンド API (Web サービス) を使用できます。最善のアプローチは何ですか？私の目標は、バックエンドを Web サービスとして公開することであり、レールでさえそれを webapp に使用しています。さまざまなアプローチの欠点または利点は何ですか?

4

2 に答える 2

1

バックエンドをサービスとして使用することは、コードをより適切に分離できるため、優れたアプローチです。Sinatra と Padrino のどちらを使用するかは、バックエンドがどれだけの管理タスクを処理する必要があるかによります。

バックエンドが API のみの場合、Sinatra といくつかの API gem (例: RABL ) を組み合わせるのが最も簡単でしょう。

しかし、バックエンドに管理タスク用の独自のインターフェースを使用させたい場合 (または、フロントエンドで使用できるように意図されていない緊急ジョブの場合でも)、同じ gem を使用した Padrino の方がより良いアプローチになる可能性があります。複雑なウェブアプリ。

編集: RABL と Sinatra プレーン JSON 出力の例:

RABL README の簡単な例を見てみましょう。次のような出力を取得するには:

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

これを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

しかし、RABL はもう少し宣言的であるため、代わりに次のように記述します。

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) }

プレーンな JSON 出力はすぐに手に負えなくなると思いがちですが、RABL を使用すると、JSON をパーシャルと継承で分割し、より保守しやすくすることができます。

于 2012-10-23T10:58:07.890 に答える
1

ここではコードを提示しませんが、以下に提案したいことをいくつか示します。

Railsアプリ用にSinatraでバックエンドAPIを構築するのは良い考えですか? それともパドリーノを使ったほうがいいですか？

あなたのアプリが DB や他の同様の側面と通信する場合は、Padrino をお勧めします。パドリーノはあなたの時間を節約します。Sinatra を使用すると、その周りにスタックを構成することになります。Padrino はジェネレーターとヘルパーに関して多くの柔軟性を提供し、スタックを選択してアプリケーションを開発できるようにします。

バックエンドがサービスとして API を提供するようにしたいので、いつでも、任意のクライアントに対して同じアプリを開発する必要がある場合は、そのバックエンド API (Web サービス) を使用できます。

SOAP については取り組んだことがないので、話すことはできません。最近は REST の人気が高まっています。Sinatra や Padrino を直接使用してルートをマッピングする代わりに、Grapeのようなものを検討できます。

グレープドックより引用

Grape は、Ruby 用の REST に似た API マイクロ フレームワークです。RESTful API を簡単に開発するための単純な DSL を提供することで、Rack で実行したり、Rails や Sinatra などの既存の Web アプリケーション フレームワークを補完したりするように設計されています。複数の形式、サブドメイン/プレフィックスの制限、コンテンツ ネゴシエーション、バージョン管理など、一般的な規則のサポートが組み込まれています。

最善のアプローチは何ですか？

これは非常にオープンエンドな質問です。最善は多くの要因に依存します。

私の目標は、バックエンドを Web サービスとして公開することであり、レールでさえそれを webapp に使用しています。さまざまなアプローチの欠点または利点は何ですか?

Web アプリ以外の他のアプリケーションで API を使用する場合、これは確かに大きな利点があります。たとえば、モバイルアプリ。

私が見ている欠点は、ネットワークの遅延とネットワークのおしゃべりです。

しかし、ボリュームの数が多い場合、これはうまく機能するはずです。複数のインスタンスでアプリをスケールアウトする予定がある場合は、アプリのコーディング中に考慮すべき事項がいくつかあります。たとえば、セッション管理。

于 2012-10-26T21:32:02.207 に答える