スプレーフレームワーク（spray.cc）は、ScalaとAkkaを使用してRESTサービスを構築するための楽しく生産的な方法のようです。私はJava+Springの学校から来ました。ここでは、すべてが十分に文書化されており、成熟しており、コミュニティからのサポートも良好です。
スプレーは遊ぶのが楽しいですが、それは荒いエッジを持っています。私は実際のアプリケーションでそれを使用することに懐疑的です。
実稼働環境でSprayを使用した人はいますか？スプレー周辺のオープンソースコミュニティはどうですか？簡単に助けを得ることができますか？
更新： SprayはBlueEyes（https://github.com/jdegoes/blueeyes）とどのように比較されますか？
私たちは電話会社のミドルウェアアプリケーションでSprayを使用していますが、Sprayは本番環境に対応していると思います。
BlueEyesには、Akkaや優れたドキュメントとのシームレスな統合はないと思います。Webコンテナまたはakkaカーネル内にデプロイできるかどうかはわかりません。スプレーのいくつかの機能はBlueEyesからもコピーされています。
-ジェスタン
まだ生産を行っていませんが、新しいスタートアップのShopolateにスプレーを使用しています。これまでのところ、私たちのテストは優れたスループットを示しており、それを使用した開発は非常に効率的です。
これまでのところバグは見つかりませんでした。
スプレーフォーラムでの質問への回答はすぐに届きますが、それでもまだ開始コミュニティです。ドキュメントは非常に完全で明確であることがわかりました。大きな利点の1つは、基礎となる設計の軽量/エレガンスです。これにより、スプレーのソースコードを非常に簡単に把握して拡張できます。
これまでのところ私たちに影響を与えた唯一の欠点は、機能の比較的小さなセットですが、それは着実に増加しています。
BlueEyesがわからないので、質問の2番目の部分に答えることができません。
スプレーは本当に素晴らしいフレームワークであり、その背後には非常に賢い人がいます。機能と同時ユーザーの両方の観点から適切に拡張できる単純なコードを提供します。読みやすいアプリケーション（優れた構造、どのURLがどの機能にマップされているかを簡単に見つけることができるなど）を作成したい場合は、Sprayが最適です。
しかし、すべてが素晴らしいわけではありません。
アッカとの緊密な結合は両面刀です。単純なアプリケーションの場合、不必要な複雑さが加わります。スプレーに行く前にアッカを受け入れたい場合は慎重に考えてください。
現時点では、Spray（1.1M4）のディレクティブに関するドキュメントは非常に限られているため、ほとんどの場合、高度なScalaコードを読んで、頭を悩ませています。
これまでのところ、下位互換性は真剣に受け止められていません。アップグレードするときは、すべてのコードに触れることを期待してください。これは、Sprayと同じくらいAkkaとScala自体のせいです。これが気に入らない場合は、SpringMVCのような退屈で信頼できるものを使用してください。
使用されるScala言語構造は正しく解析するのが非常に難しいため、ほとんどのIDEが失われ、実際のコンパイラーがその仕事をするのを待ってから、何に反対しているのかを知る必要があります。コードは読みやすいと前に言いましたが、それは高レベルにすぎません。何が起こっているのかを簡単に把握できますが、実際に何が起こっているのかを把握するには、頭の中にたくさんのスタックスペースが必要になります。
私は本番環境でSprayを使用していて、（おそらく）それを使い続けていますが、簡単な乗り心地ではありません。同等の措置で欲求不満と喜びを期待してください。