Lorawan-stack: gogoprotoプラグインの将来を調査する

使用している検証プラグインは、GoGoのサポートを終了しました
https://github.com/envoyproxy/protoc-gen-validate/pull/340

前進するための最善の方法は、エコシステムをたどり、gogo / protobufから移行することだと思います。 他の依存関係がgogoから離れるにつれて、それを使い続けることがますます難しくなると思います。 もちろん、移行するのは大変な作業になるので、移行する場合は、適切な計画を立てる必要があります。

@rvolosatovsは、おそらくgogottnジェネレーターで設定されているカスタムオプションについて詳しく知っていますが、protoファイルの明示的なオプションについて私が見つけたものは次のとおりです。

• gogoproto.customname 、 gogoproto.stdtime 、 gogoproto.stdduration 、およびgoproto_enum_prefixオプションを削除することから始めることができます。 Goコンパイラは結果として生じる問題についてすぐに文句を言うので、これらは比較的簡単に削除できます。
• gogoproto.embedオプションを削除すると、埋め込みフィールドにアクセスできなくなり（Goコンパイラがそれらを見つけるのに役立ちます）、メッセージが一部のインターフェイスを満たさなくなることを意味します（これはより難しい場合があります）。
• gogoproto.nullableオプションは、ゲッターの使用を開始し、nil-checksを追加する必要があるため、はるかに手間がかかります。 結果として生じる問題は、Goコンパイラによって検出されない場合があります。 考えられる回避策は、これらのフィールドを一時的にプライベートにしてから、ゲッター/セッターに書き直して、最後にフィールドを再びパブリックにすることです。
• 非常に問題になるのは、 gogoproto.customtypeを使用するフィールドと、 gogoproto.enum_stringerオプションを使用する列挙型です。 それらについては、マーシャリング/アンマーシャリングの方法をJSONに変更することがよくあります。 EUI、DevAddrなどのカスタムbytesフィールドの場合、タイプ（プロトメッセージ内）をstring （バイナリ互換）に変更できます。 列挙型では、文字列と整数の両方として（UnmarshalJSONによって）受け入れられるようになったため、JSONAPIが機能しなくなるのではないかと心配しています。

たぶん、これは私たちのv4 APIについて考え始める良い機会でもあります。なぜなら、私たちはさらにいくつかの（APIを壊す）驚きを発見するかもしれないと想像できるからです。

前進するための最善の方法は、最初にhttps://github.com/alta/protopatchを試すことだと思い

• すべてのニーズが満たされている場合->移行してこれを忘れてください（ apiディレクトリで検索して置換するだけです）
• 一部のニーズのみがカバーされ、プラグインでカバーされていないカスタムオプションがある場合->オプションごとに評価し、これらのカスタムオプションを削除するか、おそらくprotopatchに貢献する必要があります。低労力機能。 これは実際にはオプションによって異なりますが、 customtypeについて話している場合、IMOは間違いなく貢献を正当化しますが、 stdtimeようなものはそれほど多くありません。

将来的には、実行時に内部的にコンポーネントでバニラprotobufプロトを直接使用するべきではないと思います（今日提供されているprotobufの機能セットを前提としています）。
（逆）シリアル化、つまりストレージとAPIレイヤーにprotobufを使用することは意味があります。 ただし、内部的には、プレーンなバニラで生成されたGoプロトを使用しても意味がありません。
したがって、たとえば、NS：

1. レジストリから*ttnpb.EndDevice （バニラ生成のGoタイプ）を取得し、保存されているバイナリデータから逆シリアル化します
2. *ttnpb.EndDeviceをT_deviceに変換します（注：おそらく、最初はラッパーであるか、永久にラッパーである可能性があります）
3. NSの内部でT_device使用する
4. T_deviceを*ttnpb.EndDevice変換します（注：ラッパーを使用している場合、変更されたフィールドを変更するだけで、バイナリでも実行できるため、これは簡単で非常に高速なタスクになる可能性がありますデータを直接）
5. *ttnpb.EndDevice 、バイナリデータにシリアル化します

参照https://github.com/TheThingsNetwork/lorawan-stack/issues/342 （生成されたポピュレーター）

私はgogoの（より小さな）代替手段を支持していません。 缶を押すような感じです。 物事を可能な限りバニラに保ちましょう。特に、前進するための最善の方法をもう一度決定する必要がある場合はそうです。

生成されたプロトにどこでも依存するのではなく、いくつかの場所で中間タイプを使用することを検討できることに同意します。 基本的に、データ転送オブジェクト（DTO：プロト、ストレージ用）をデータアクセスオブジェクト（DAO：それらの使用方法）から分離します。 それが主に読んでいる場合は、インターフェースを宣言して、それをどこまで達成できるかを確認することもできます。

そうは言っても、NS全体をT_deviceを使用するように変更するのではなく、必要に応じて特定の構造体やインターフェイスを使用するようにします。

この議論を11月に移しましょう

@rvolosatovsカスタムJSONマーシャラーを使用してバニラに移行することに反対する意見は何ですか？

バニラプロトを直接使用することになった場合、移行の大きな負担と定型文の負荷。
私は実際にはそれに反対しませんが、最初に単純で邪魔にならない代替案を見つけようとし、それが不可能な場合は、このすべてをやり直すことに頼るべきだと思います。

私たちが依存し始めたプラグインは、ある時点でメンテナンスされていない状態になるのではないかと心配しています。 一般的に言って、私は物事をできるだけバニラに近づけることに賛成です。 それがnilを私たちが望むよりも頻繁にチェックすることを意味するのであれば、そうです。 また、初期化された構造体ではなく、設定されていないことがわかっていることも有利に機能します。

コードベース全体のリファクタリングは、どのように行っても苦痛になるのではないかと心配しています。 私たちの（gogoで生成された）プロト構造体は現在どこでも使用されています（gRPC API、HTTP API、イベント、エラー、内部的に、Redis DBなど）。コードベースのほとんどすべて、そして現在の外観をすべて同時に。

難しい要件は、v3APIの互換性を損なわないことです。 この状況をv4APIの作業を開始する瞬間として（少なくとも内部的に）使用することにした場合でも、既存のユーザーに対してそのv3APIをサポートし続ける必要があります。

長期的には、（バージョン管理された、メジャー内で安定した）外部APIを内部（バージョン管理されていない、マイナー内で安定した）APIおよび（バージョン管理された、安定した）データベースドキュメントから分離することで、大きな恩恵を受けると思います。 。 次に、内部APIと他のAPIの間で変換する関数を記述または生成できます。

しかし、私たちが今すでに実行できるいくつかのステップがあると思います。

JSON

v3 JSON APIとの互換性を維持するために、最初のTODOは、カスタム型をマーシャリング/アンマーシャリングする方法を理解するJSONマーシャラーとアンマーシャラーの生成に取り組むことだと思います。 GoによるプロトコルバッファのJSON形式の実装には安定性が約束されていないため、これを行うのは賢明だと思いgrpc-gatewayランタイムではコーデックを登録できるため、{gogo、golang} / protobufのjsonpbの代わりに、独自の（生成された）（非）マーシャラーを呼び出すコーデックを記述できます。

古いものの_隣_に新しいプロトを生成する

私はすでにここでそれを試しました： https ：

これにより、protobufはtypesレジストリについて不平を言うので、これを機能させるには、古いprotoからgolang_proto.RegisterTypeを削除する必要があるかもしれません。 これを削除すると、 google.protobuf.Any解決が失敗する可能性がありますが、これらはエラーとイベントでのみ使用されるため、これらの特定のケースの回避策を見つけることができます。

古いプロトと新しいプロトの間で変換する関数を生成します

これは移行期間のみですが、長期的な解決策として、同様のコンバーターを生成する必要があります。

サービスを1つずつ更新する

https://github.com/TheThingsNetwork/lorawan-stack/commit/cd7d75c8b42ad15eee1ac594ff6d0f2d5a75eb67の簡単なサービスですでに試しましたが、より複雑なサービスの場合は、これらのコンバーターが必ず必要になります。

これはgrpcサービス自体のみを変更することに注意してください。 grpc-gatewayは引き続きJSON側で古いgogoのものを使用し、内部gRPCサーバーを呼び出します。内部gRPCサーバーは新しい実装を実行します。

いくつかの初期依存関係の更新と下位互換性の回避策をここにプッシュしました： https ：

ますます多くの依存関係がprotobuf1.4とV2APIにアップグレードされており、これを開いたままにしておく時間が長いほど、依存関係をアップグレードしようとするときに問題が発生します。

私たちは本当にこれをもう少し優先し、これについて何をするかを決定する必要があります。

オフラインで話し合うことができるように、来週の電話を計画してください。

私たちはこの痛みのプロセスを経て、1、2週間でこれを解決することに集中すべきだと思います。 そして、それを避けるために、他のことをします。そうしないと、多くの競合が発生するからです。 できるだけ多くの手を持っていることは、私たちがどのような場合に何をしようとしているのかを正確に知り、タスクを可能な限り分割し、賞に目を光らせる必要があります。

次のステップ：

1. @rvolosatovsは、ツールを「バニラ」にできるだけ近づけるように更新します。
   
   
   
   • unconvert 、 gofumptなど、protocの上で実行しているものをすべて削除します
   
   
   • protoc-gen-gogottnからprotoc-gen-gofast （またはバニラに最も近いもの）に切り替えます
   
   
   • プロトファイルに(gogoproto.*)オプションを明示的に追加して、現在と同じようにレンダリングするようにします
   
   
2. 直接フィールドアクセスの代わりにゲッターを使用するには、コードをリファクタリングする必要があります。 おそらく、 goplsやrfようなツールがこれに役立つでしょう。
3. (gogoproto.*)オプションを1つずつ削除し、それを使用するコードを更新します。 おそらく、 goplsやrfようなツールがこれに役立つでしょう。
   
   
   
   • gogoproto.populateを削除してテストを更新する（https://github.com/TheThingsNetwork/lorawan-stack/issues/342）
   
   
   • gogoproto.customnameを削除し、 EUI -> Euiなどを変更します。
   
   
   • gogoproto.embed削除します。 メッセージがValidateContext(context.Context) errorやExtractRequestFields(m map[string]interface{})などのインターフェースを実装していることを確認する必要があります。
   
   
   • gogoproto.nullableを削除し、可能な場合はGetterを使用していることを確認し、それ以外の場合はnilチェックを実行します。
   
   
   • ..。
   
   

@rvolosatovsは、v3.11.3の最初のステップを試してみましょう。 それが終わったら、他の担当者を再度追加して、もう一度話し合いましょう。