6

私たちは、XML、JSON、および場合によっては他のコンテンツタイプを提供するRESTfulAPIを構築しています。

私のチームは、（優先度の高い順に）次のようなフレームワークを探しています。

  1. 十分に文書化されている
    • 理想的には、優れたチュートリアルと、活発なコミュニティとナレッジベースを備えています
  2. 合理的なデザインパターンに従う
    • ほとんどの場合、フレームワークに一貫性が必要です。呼び出しているメソッド呼び出しに基づいて変更されない命名規則。
  3. 安全
    • 開発者にGET、POST、PUT、およびDELETE変数の何らかの形式の検証を実行させることに焦点を当てています
  4. 安定
    • フレームワークがあまり頻繁に変更されていないという意味で、これの一部は成熟度です。
    • 他の部分は、恐ろしく巨大ではない、十分に文書化されたバグリストです。
  5. スケーラブル/パフォーマンス指向
    • 世界中に5万人を超えるユーザーがいて、非常に高い可用性を必要としています。私たちのアプリがダウンした場合、人々は彼らの家にインターネットを持っていません。したがって、これは非常に重要な環境です。
    • 理想的には、10台のサーバーで同じコードベースを起動し、ロードバランサーを追加し続けることができます。どのサーバーがどのメソッド上にあるかを定義する必要はありません。
  6. Linux/MySQL環境とうまく統合します
    • MSサーバーは1つではありません。私たちはそれを変えていません。申し訳ありませんが.Netファン:-D

私はこれが漠然とした目標であることを認識しています。これらのニーズをすべて満たすフレームワークは1つではありません。実際、さまざまな方法、形、形式でそれらを満たすフレームワークはおそらくたくさんあります。

これは言語に依存しません。私たちはすでにPHPの経験がありますが、人生でWebアプリケーションを作成したことがない開発者もいるため、Python、Ruby、またはJavaを学ぶことは許容されます。

4

14 に答える 14

5

ここで手足に出て、RubywithSinatraを提案します。

なんで？

  1. Sinatraは「十分に文書化されている」わけではありませんが、「十分に文書化されている」のです。他のフレームワークよりもはるかに単純であることを考えると、それほど多くのドキュメントは必要ありません。また、WebサーバーとしてRack上に構築されているため、いくつかの一般的なドキュメントを共有しています。しかし、あなたが知る必要があるのはウェブサイトにあり、それはよく書かれていて、私が見つけたエラーは含まれていません（つまり、それはすべて最新です）。

    知っておく必要のあることのほとんどは、Sinatra Book、Readme、およびFAQにあります。本の進行中の性質にもかかわらず、その内容は非常に正確で有用です。それでも質問が足りない場合は、IRCチャットルームfreenode.net＃sinatraに立ち寄ってください。

  2. Sinatraは、機能/ルートベースのロジックメソッドで使用するか、Sinatra::Applicationオブジェクトをオーバーライドすることで使用できます。ロジックとメソッドをさまざまなファイルに分割するか、すべてを1つにまとめて使用することができます。それはすべてあなた次第です。

  3. シナトラは、それ自体が安全です。Sinatraは、変数を解析してユーザーに渡す以外に、変数がどれほど有効であるかを気にしないため、ユーザーから送信されたすべての変数を検証する必要があります。したがって、変数の有効性を強制するか、後悔します。 ;-)

  4. Sinatraは、過去4か月間、変更を加えていませんが、確かにメンテナンスとマイナーアップデートが行われています。さらに、バグリストが大きくて脅威的であるとは思いませんでした。アプリを構築するために必要なものはほぼすべて揃っています。

  5. SinatraはPassengerと一緒に展開する必要はありませんが、高速になるように簡単にカスタマイズできます。Enterprise RubyやThinなどを使用する場合は、NginixまたはLightHTTPdのいずれかにプロキシできます。2台のサーバーを使用した場合、1台をプライマリ（プロキシと多数のスレッドを使用）、もう1台をデータベースサーバー（MySQLと多数のスレッドを使用）にして、それらを解放することができます。このようにして、タスクはサーバー全体に分散されます。それは私が乗客が思うよりあなたにもっと多くのコントロールを与えるでしょう。（パフォーマンスの向上は言うまでもありません。）

    Passenger（Dreamhost上）は、Rack、Mongrel、またはThinのいずれかで実行中のスレッドと比較すると、パフォーマンスが比較的低いことがわかりました。とは言うものの、ロードされると、アプリケーションはその環境でも応答します。私がそれを予測した場合、コードを再デプロイしてスレッドを再起動するだけでよいため、アプリケーションのスケーリングに問題はありません。Capistranoに入れることができないものは何もありません。

  6. Linux上のRubyは高速で、実装に問題はありません。MySQLとRubyは非常に簡単で、 ActiveRecordやSequelなどの非常に優れたORMパッケージがいくつかあります。シナトラはあなたが嫌い​​なものを選ばせることはありません。

あなたの質問への回答に加えて、私にはいくつかの理由があります。

  1. シナトラは学習曲線が簡単で、習得も非常に簡単です。Rackは古いバージョンだったので、私が抱えていた最大の問題はそれをDreamhostサーバーに取り込むことでしたが、Rackのベンダーバージョンでは問題はなくなりました。可能であれば、Sinatraの最新のRailsプロジェクトをActiveRecordで書き直して、自分自身のメンテナンスを容易にします。すでにあまりにも多くの努力が費やされました。

    その使いやすさと学習のしやすさのおかげで、すべてのコードジェネレーターを備えたRailsよりも、コードジェネレーターを備えていないSinatraの方が生産性が高いことがわかりました。そして、それは何かを言っています。

  2. SinatraはRackのミドルウェアをサポートしているため、それを使用して実行できることは非常に柔軟です。

  3. IRCでSinatraコミュニティの有用性を平均するとしたら、大雑把な比較と同じように、彼らは平均的なRailsユーザーよりもフレームワークに精通していると言えます。その理由は、Railsは、初心者やビジネスプログラミングをまったく持っていない人にとってよりアクセスしやすいからです。

  4. SinatraはRuby1.9をサポートします。現在Sinatraで1.9がどれだけサポートされているかはまだ完全にはわかりませんが、最初はRackを待っていたのは確かです。 4月25日の時点で、これはもはや問題ではないため、おそらくSinatraはすでに1.9の準備ができています。事実、2009年半ばに1.9のサポートが進行中であることは知っていますが、それがどのくらいの期間になるかはわかりません。

    少しの努力でSinatraをRuby1.9で動作させることができると仮定すると（バージョン0.9.2はすでにRack 1.0をサポートし、Rackのコードではプロキシ1.9によって）、1.9をサポートするパブリック1.0の前に、Ruby側でのパフォーマンスは素晴らしいものになります。できない場合でも、EnterpriseRubyが速度を向上させます。

于 2009-05-22T22:09:14.463 に答える
4

DjangoとRailsはどちらも、ほとんどの基準にほぼ適合しています。ただし、DjangoのドキュメントはRubyonRailsのドキュメントよりもはるかに優れていると思います。Djangoのドキュメントは驚くべきものです（そして私はここで双曲的ではありません）。

ただし、Djangoのスケーラビリティについてはわかりません。Railsがかなりうまくスケーリングすることは知っていますが（ある程度まで）、Djangoについても同じことが言えるかどうかはわかりません。（私はそれができないと言っているのではありません。私はDjangoを使用して大規模なアプリケーションを作成したことがないので、正直にわからないと言っているだけです。）

密かにそれを望む場合に備えて、Djangoにもポニーがあります。

于 2009-05-21T14:20:08.173 に答える
3

上手。スケーラビリティを得るのは簡単なことではありません。Googleのような応答時間の場合、MapReduceのようなものが必要です。Ok。自分をからかってはいけません。超スケーラビリティは初心者には何の意味もありません。

他のすべての点に関しては、シーサイドが明らかに最高です。セキュリティに関しては、 seaside.stをチェックして、私が知っている他のすべてのフレームワーク（RailsやSeamなど）よりも本質的に安全である理由を確認してください。シーサイドは十分に文書化されていますが、シーサイドの内部を調べるのはとても簡単で便利なので、コミュニティが答える質問はほとんどありません。シーサイドは長年安定しているので、大丈夫だと思います。

パフォーマンス指向の場合：商用のSeaside、GLASSを実行すると、統合されたはるかに高速なデータベースソリューションと、メモリを速度と交換して多くの速度。

Seasideは非常によく構築されているため、多くの人がSeasideアプリの作成はデスクトップアプリケーションよりも簡単です。それを試してみてください、あなたはそれを気に入るはずです。

PS：記録として、SeasideはRESTfulではありません。

于 2009-05-21T14:19:18.097 に答える
2

Django、Pythonフレームワークを見ることができます。これは非常によく文書化されたフレームワークであり、データベースに自動CRUD管理者インターフェイスがあり、オンラインで無料の本もあります。もちろん、実際に購入することもできます:)

于 2009-05-21T14:24:24.640 に答える
1

それらすべてを試して、正しい答えを見つけてください！

さて、「それらすべてを支配するための1つのフレームワーク」を提案する人々は、それらすべてを試したことはないでしょう！

于 2009-05-21T14:06:11.743 に答える
0

Ruby on Railsはプラグインの負荷で広範に文書化されており、スケーラビリティーですでにテストされています（BaseCampおよびRailsで作成された他のソリューションを参照）

于 2009-05-21T14:12:33.557 に答える
0

Javaを検討している場合は、 Jerseyをお勧めします。これはうまく機能し、5つの目標をすべて達成できると思います...

于 2009-05-21T14:14:56.653 に答える
0

そのような枠組みがあったとしたら、それは唯一無二だと思います。

于 2009-05-21T14:05:00.683 に答える
0

PHPの場合、私はZendフレームワークが大好きでした（ただし、私にとっては実際にはフレームワークではありません）。最高の機能の1つは、各コンポーネントが他のコンポーネントから独立していることです...したがって、気に入らない部分がある場合は、使用しないでください。また、JSONについても言及しています...Zendは双方向でJSONを完全にサポートしています...

于 2009-05-21T14:07:20.523 に答える
0

優先順位のリストを見ると、1つのルートが「正しい」方法であるとは言い難いです。PHP側では、私はCakePHPでかなりの時間を費やしてきました。これは、あなたが探していることの多くを実現します。しかし、PHPが嫌いな人である私は、その領域の何も避けて操縦することをお勧めします。

それはすべてスタイルと経験についてです。私はRubyOnRailsを使用しましたが、これは最も洗練された言語ではありませんが、非常にうまく機能します。JavaでSpring/Hibernateスタックを使用したり、箱から出してすぐにほとんどすべてを処理する.Netを使用したりするほど成熟していませんでしたが、非常にうまく機能します。私はJava/.Netベースのプロジェクトを好みます。なぜなら、それは私がプログラミングしたい方法にはるかによく適合するからです。

「正しい」答えはなく、良い答えがたくさんあります。たとえば、ASP.NetMVCは良い選択です。ずっと前に、私はJavaでSpringを使用しましたが、これも仕事を遂行するのにかなり効果的でした。PHPでさえ間違った選択ではありません。私が2つのプロジェクトしか行っていないRubyOnRailsは、非常に簡単に理解でき、他の言語でのかなり複雑なタスクをかなり簡単にします。

于 2009-05-21T14:15:40.320 に答える
0

膨大な量のドキュメントでは、J2EEに勝るものはないと思います。また、めちゃくちゃスケーラブルで安定していると考えられています。

さて、そこから本当に望ましいものへ…。

于 2009-05-21T14:20:18.190 に答える
0

Javaがツールキットに含まれている場合は、Stripesを確認してください。

見事に大きなコミュニティはありませんが、安定していて熱狂的です。良いドキュメント、いくつかは古くなっていますが、システムは「古いもの」が関連していても非常に安定しています。本当に素敵な、最近の（昨年末）本。ストライプは、本が「すべてをカバー」できるほど十分に小さいです。

これはアクションフレームワークであり、プレゼンテーション領域ではあまり機能しません（ほとんどの場合、フォームを保存し、完全にオプションのテンプレート/レイアウト機能を備えています）。JSPまたはFreeMarker、あるいは実際には他のものを使用できます。また、Webサービスも実行できます（ただし、Jerseyのようなものほどではありません）。

バックエンドに依存しませんが、JPA統合プロジェクトがあります。

最後に、必要に応じて、他のすべてのJava /JavaEEキットを活用できます。Stripesはスタック全体を消費しないため、必要なパーツを柔軟に選択できます。フルボートJavaEE、トランザクション、セッションBean、JMS。Springで動作します（Springを「意識」しており、統合が良好です）JPA、iBatis、Hibernate、raw JDBC、Lucene、JSR-170コンテンツリポジトリなど。

素晴らしいキットです。

于 2009-05-22T21:27:16.153 に答える
0

2014年の回答については、Laravel / Slim Framework（PHP）、Ruby on Rails / Sinatra（Ruby）、Django / Flask（Python）、Grails（Groovy、JVMベースの言語）、Play！をお勧めします。フレームワーク（Java / Scala）またはSails.js / Kraken.js（Javascript）。

「/」を使用して2つのフレームワークについて言及している言語では、最初に言及したフレームワークが少し大きく、2番目のフレームワークが少し小さくなっています。

これが5年後に同様の質問をする人々に役立つことを願っています。

于 2014-06-10T13:51:26.620 に答える
-1

cppcmsを試してください

高性能のWeb開発フレームワークです

于 2013-08-14T09:43:34.553 に答える