[FEATURE] Add GRPC/Protobuf support to Java client
メンテナーはふだん 1 日以内に返信
まだ誰も着手していません。
評価
- 難易度
- 5/5
- 見積もり時間
- 1週間以上
- 初心者へのやさしさ
- 25/100
調査の方向性
OpenSearch Java client の既存の HTTP トランスポートから始め、次に opensearch-protobufs の common.proto と、OpenSearch の build.gradle にある transport-grpc エントリを読みます。クライアントが既存のクラスを再利用すべきか、別の gRPC パスを生成すべきか、部分的なサポートを提供すべきかを明確にします。完了とは、API 互換性と移行時の動作を定義した、Java gRPC トランスポートの合意済みのアプローチが得られていることです。
索引モデルが issue の本文から書いたものです。
説明
Is your feature request related to a problem?
https://github.com/opensearch-project/OpenSearch/issues/16787 introduces GRPC/Protobuf as a new protocol/schema for client-server APIs, which has shown great performance improvements compared to traditional HTTP/REST APIs. This feature is now moving towards maturity and stabilization.
To further this feature's integration within the OpenSearch ecosystem, we would like to propose adding GRPC/Protobuf as a supported protocol in OpenSearch language clients. This will allow:
- users to more easily be able to use this feature, rather than raw protobuf generated code
- have shared common utilities which all clients can benefit from
- maintain parity with the HTTP/JSON user experience.
- Offer a more seamless transition from HTTP APIs to GRPC ones (e.g. through adding a flag to toggle
--protocol={grpc,http})
What solution would you like?
Add gRPC transport support to the OpenSearch Java client, providing a high-performance alternative to the existing HTTP transport while maintaining full API compatibility.
Some questions/challenges to consider are:
- Reuse HTTP java classes vs. build new ones: Whether the existing java classes can be refactored to support GRPC as well. If not possible, another option is to build a new GRPC Java code path which gets generated differently from the HTTP ones, which
- Handwritten vs. auto-generated client If the GRPC code path is separate from the HTTP code path, should we handwrite the java client for GRPC, or is there a way to autogenerate it similar to the HTTP one? There could be divergences from spec and protobufs (due to protobuf best practices), so how can autogeneration work? Should it be generated from the API spec or opensearch-protobufs?
- Full support vs. partial support: Depending on the challenges for supporting a fully fledged GRPC client, shall we opt to provide support only on utilities for common patterns? Can we fallback on using the default generated protobuf language client for APIs which are not supported by the client yet?
- Protocol specific considerations: Is there a way for the Java client support gRPC-protocol-specific features, such as streaming? On the other hand, how can the client properly convert HTTP-specific features, like the bulk NDJSON format?
- User migration: How should users transition from HTTP to gRPC (e.g.
--protocol={grpc,http}flag for a seamless transition, or would they have to rewrite their code to adhere to the GRPC client?
What alternatives have you considered?
Using the generated Java code for protobufs directly, rather than integrating into the existing client architecture.
Do you have any additional context?
- How protobufs are generated from spec: https://github.com/opensearch-project/opensearch-api-specification/issues/677
- opensearch-protobufs repo where protobufs are stored: https://github.com/opensearch-project/opensearch-protobufs/blob/main/protos/schemas/common.proto
- How the GRPC core module uses the protobufs: https://github.com/opensearch-project/OpenSearch/blob/main/modules/transport-grpc/build.gradle#L37
- 主要言語
- Java
- スター
- 164
- フォーク
- 260
- 平均マージ
- 20時間 4分
- マージ済み PR（30日）
- 53
環境構築
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートなし
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
opensearch-project/opensearch-java のほかの issue
-
enhancement untriaged
難易度 2/5 1〜3時間 初心者へのやさしさ 74/100
opensearch-project/opensearch-java#2188 ·
メンテナーはふだん 1 日以内に返信
-
[BUG] "shape" should not be required in GeoShapeQueryField再び着手できるかも @lsh1215 が 131 日前に担当しましたが、オープン中のプルリクエストはありません。 オープンbug untriaged
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
opensearch-project/opensearch-java#2011 · コメント 2 件 ·
メンテナーはふだん 1 日以内に返信
-
untriaged
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
opensearch-project/opensearch-java#2008 ·
メンテナーはふだん 1 日以内に返信
-
[BUG] ISM types lastUpdatedTime is susceptible to int overflow対応中かも @gingeekrishna が 126 日前に担当しました。 オープンbug
難易度 2/5 1〜3時間 初心者へのやさしさ 70/100
opensearch-project/opensearch-java#1898 · コメント 3 件 ·
メンテナーはふだん 1 日以内に返信
-
[BUG] `BulkIngester` can deadlock when retried operations fill the buffer対応中かも @emreekiziltoprak が 8 日前に担当しました。 オープンbug untriaged
難易度 4/5 3〜5日 初心者へのやさしさ 45/100
opensearch-project/opensearch-java#2248 ·
メンテナーはふだん 1 日以内に返信
opensearch-project/opensearch-java の issue をすべて見る
似ている issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100
commons-app/apps-android-commons#7275 ·
メンテナーはふだん 1 日以内に返信
-
documentation
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
liberation-data/drivine4j#682 ·
メンテナーはふだん 1 日以内に返信
-
Document and enforce pull request review guidelines対応中かも @dashorst が今日担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
メンテナーはふだん 1 日以内に返信
-
`Time.at(t, in: nil)` returns UTC instead of the local time (or the time zone of `t`), unlike CRubyオープン
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
メンテナーはふだん 1 日以内に返信
-
hermes-queue
難易度 1/5 1時間未満 初心者へのやさしさ 72/100
chrisalunlloyd2-sudo/mindpalace#349 ·
メンテナーはふだん 1 日以内に返信