API設計に関する個人的な考察
目的
現段階での、API設計に関する個人的な考察をアウトプット。 gRPCもGraphQLもRESTも基本はリソースを中心にして設計するという設計感になったので、雑なアウトプットだが今後自分の設計感がどう変化していくのかの、備忘録的位置付けにしようと思う。
API設計に関する理解度
- RESTしか経験無い(かつ本格的ではない)
- 転職後初めてGraphQLとgRPCに触れる
- 設計方法とかバラダイムよくわからんけど、REST時代の思考で設計
もやる
開発を進める中で色々と悩む事が増えてきて、モヤモヤが蓄積する。たとえば、
- gRPCの設計時に、ドメイン的に階層構造になっているモノ(例:発注と明細とか)は、集約を取得するときにそのままの階層構造で返したい気持ちだったけど、パフォーマンスとかを考慮するとそうはいかない
- 結果、ヘッダーと明細を別で取得できるAPIを用意する。そうすると今度は、更新時には集約でさせたいけど、ヘッダーの方に明細も渡すと更新と取得で歪な関係になるのでは...?など別のもやりも出てくる
- 状態遷移をさせるときは、UpdateのAPIに全部渡すのではなく別アクションできりだす方が適切な気がするけど、言語化がうまくできない...
デザインパターンに出会う
本屋をぶらぶらしていると、「APIデザインパターン」なるものに出会う。 まだ途中だが内容的には結構良かった。リソース指向がなぜいいか?という内容から、gRPC、GraphQL、RESTのいずれも同じ考え方で設計していいものか?を考えるようになった。
WEBを漁る
gRPCについて
このサイト良かった。 google.aip.dev
ビジネスドメインに沿った考えでAPI設計をするっていうのは非常にわかりみが深い。 これは、UIに左右された作りにならないので、BE側にとっても幸せそう。
GraphQLについて
このサイトはかなり参考になり良かった。 github.com
ここ見て、GraphQLもリソース指向でいいのかなーという解になる。 クライアントによって表示したい内容とかレイアウトは全然異なるけど、根底にある表示したい情報(リソース)は共通だとすると、リソースをちゃんと設計できていればクライアントごとにスキーマを用意するとかは不要そう。
と共に、BFFはクライアントごとに必要って聞いたけど、BFF一個でいいのでは?との思いに至る。 調べていると、 Universal BFF という考えがあり、それがまさにこれにあたる。以下のリンクにはGraphQL誕生の動画もあり、まさにこれではと更に思う。 zenn.dev
テーブル設計の変更に弱いというデメリットはあるけど、hasuraとか使うとBFF作る必要なくなって開発速度上がるとかもある? BE側も参照系のAPI用意する必要なくなりそうだし..