GitHub aeroastro
Comment4
Like
Created atMarch 20, 2019 20:39
Updated atMarch 20, 2019 20:39

Questions and feedbacks (4)

aeroastro
aeroastro commented 4 months

命名変更以外の非互換 schema 変更を伴う場合の対応はどのように行っていますか?(versioning?)

まず、APIの出力に対して、新しい field を追加するという場合は、スキーマとしての互換性は失われますが、SDKを利用するコードに修正は必要無いため、そのまま追加を行います。

次に、APIの入力に対して、新しい field を増やすという場合は、スキーマとしての互換性は失われますが、バックエンド側で初期値を与えてあげることで、旧スキーマを参照する SDK からのアクセスも同一エンドポイントでハンドリング可能であるため、そのまま追加を行う場合が多いです。

fieldの削除等、 schema だけでなく、 SDK I/F としても互換性が失われるものについては、開発フェーズや、利用度合い等、様々な事情を考えた上で、様々な策が取られます。(詳しく説明すると非常に長くなってしまうので、すみませんが、今回は割愛させてください。)

これらが不適切となる運用段階での大幅な変更(大幅なschema変更や内部ロジック変更等)がある場合には、エンドポイントベースでの versioning を行 う場合があります。schemaから生成されるコードと、SDKの外部I/Fの間に層が存在することによって、SDK I/F としては同一のままになる場合もあります。また、APIの特性によっては、ロジックやデータのバージョンを示す field をスキーマ内に持つことで、新・旧の互換性を保持しているものもあります。

Like(0)

aeroastro
aeroastro commented 4 months

gRPCの利用は検討されたのでしょうか?

はい。検討しました。 しかし、プロジェクト当初は、RESTfulを選択することによる恩恵が大きいということで、開発者の意向として RESTful が選択されました。

これらの背景をより詳しく見ていくと以下のようになります。

  • RPC or RESTful という文脈においては、特に Rails においては、 RESTful を利用することによる生産性向上が大きかった。
  • そもそも、検討時における gRPC は、エコシステムも含め、今のように成熟したものではなかった。

また、SDK において開発者に使いやすい I/F を提供したいという都合上、カスタムのコードジェネレータを設計・実装する必要があるという部分は 、当時、仮にgRPCを導入していた世界線であっても、あまり楽にはならなかったのではないかと推測されます。

Like(0)

aeroastro
aeroastro commented 4 months

モックのAPIやAPIドキュメントを作る作業はフロントエンドチームとバックエンドチームが共同で作る体制でしょうか?

はい。案件ごとの差はありますが、共同で作る体制が多いです。 例えば、満たすべき要件に対して両者で話し合いながら概念設計を進め、その結果をスキーマに反映し、モックのAPIやAPIドキュメントを作っていきます。バックエンドチーム、フロントエンドチームが、それぞれの得意な領域から、設計に対してフィードバックしていきます。設計の為のたたき台を作ったりする部分や、設計結果をスキーマに落とし込み、APIとして利用できるようにする部分はバックエンドチームが担当する場合が多いです。

APIの規模や難易度が大きくなるほど、よりスキーマ確定前の設計時の共同作業に比重が置かれる傾向があります。

Like(0)

aeroastro
aeroastro commented 4 months

今回の可読性を現場で実践していく上で、重要だと考えているもの(方法論)があれば教えていただきたいです。

特に、既存のテストコードを、可読性が高い状態へと改善していく際のヒントを頂けると助かります。

Like(0)

This software is available as open source under the terms of the MIT License.
Copyright © 2018 Yoshiyuki Hirano