いくつかのクライアント側の JavaScript アプリに Solr または ElasticSearch を使用することを検討しています。あるインスタンスでは、API を直接呼び出すことができました。
私はこの概念にかなり慣れていませんが、最初に頭に浮かんだことの 1 つは、API に対して削除コマンドを発行する人などのセキュリティ関連の問題をどのように回避するかということです。クライアントがやり取りする小さな PHP や Sinatra API のように、検索 API をレイヤーの背後に隠すことは適切ですか?
ありがとう！
クライアントがやり取りする小さな PHP や Sinatra API のように、層の後ろに検索 API を隠すことは適切ですか?
セキュリティを気にするなら、答えは間違いなくYESです。
NodeJS は、クライアント リクエストの承認、elasticsearch/solr へのクエリの送信、およびクライアントへの返信 (データ処理の有無にかかわらず) など、この種の作業に最適です。多くの接続がある場合、PHP はあまり適していません (nodejs が最適です)。
Elasticsearch のブログで、この記事の第 2 部を参照してください。プロキシの素敵な図と、プロキシの簡単なRuby コードがあります。
そこからの関連する引用：
これはすべて、elasticsearch が HTTP API を公開しているという事実を活用することで可能になります。その前にプロキシを配置することで、認証と承認のルーチンを個別のコンポーネントに分離し、スタック内の責任を効果的に分解し、個々の部分のテスト容易性を向上させることができます。
プロキシとして機能するレイヤーを追加できますが、これを行う最善の方法はレプリケーションを使用することです (2 つ以上のインスタンス - http://wiki.apache.org/solr/SolrReplication ) 。
このようにして、常に有効で強力な、通常は非公開のマスター インデックスを使用します。このマスター インデックスに対して追加、削除、および任意の操作を実行できます。また、マスター インデックスの単なるコピーであり、クエリ API を提供するだけのスレーブ インデックスもあります。