API設計に関する個人的な考察

目的

現段階での、API設計に関する個人的な考察をアウトプット。 gRPCもGraphQLもRESTも基本はリソースを中心にして設計するという設計感になったので、雑なアウトプットだが今後自分の設計感がどう変化していくのかの、備忘録的位置付けにしようと思う。

API設計に関する理解度

  • RESTしか経験無い(かつ本格的ではない)
  • 転職後初めてGraphQLとgRPCに触れる
    • GraphQLに関しては、UI側が好きなようにレスポンスを組み立てるという理解。GraphQLは画面が使いやすいように返すっていう人もいるけど、これはリソースの関連を自由に辿る=それを指しているのか、ドメインとか無視して画面特化の好きなDTOを返すイメージどっちだったのかすらわかってない
  • 設計方法とかバラダイムよくわからんけど、REST時代の思考で設計

もやる

開発を進める中で色々と悩む事が増えてきて、モヤモヤが蓄積する。たとえば、

  • gRPCの設計時に、ドメイン的に階層構造になっているモノ(例:発注と明細とか)は、集約を取得するときにそのままの階層構造で返したい気持ちだったけど、パフォーマンスとかを考慮するとそうはいかない
    • 結果、ヘッダーと明細を別で取得できるAPIを用意する。そうすると今度は、更新時には集約でさせたいけど、ヘッダーの方に明細も渡すと更新と取得で歪な関係になるのでは...?など別のもやりも出てくる
  • 状態遷移をさせるときは、UpdateのAPIに全部渡すのではなく別アクションできりだす方が適切な気がするけど、言語化がうまくできない...

デザインパターンに出会う

本屋をぶらぶらしていると、「APIデザインパターン」なるものに出会う。 まだ途中だが内容的には結構良かった。リソース指向がなぜいいか?という内容から、gRPC、GraphQL、RESTのいずれも同じ考え方で設計していいものか?を考えるようになった。

www.amazon.co.jp

WEBを漁る

gRPCについて

このサイト良かった。 google.aip.dev

ビジネスドメインに沿った考えでAPI設計をするっていうのは非常にわかりみが深い。 これは、UIに左右された作りにならないので、BE側にとっても幸せそう。

GraphQLについて

このサイトはかなり参考になり良かった。 github.com

ここ見て、GraphQLもリソース指向でいいのかなーという解になる。 クライアントによって表示したい内容とかレイアウトは全然異なるけど、根底にある表示したい情報(リソース)は共通だとすると、リソースをちゃんと設計できていればクライアントごとにスキーマを用意するとかは不要そう。

と共に、BFFはクライアントごとに必要って聞いたけど、BFF一個でいいのでは?との思いに至る。 調べていると、 Universal BFF という考えがあり、それがまさにこれにあたる。以下のリンクにはGraphQL誕生の動画もあり、まさにこれではと更に思う。 zenn.dev

テーブル設計の変更に弱いというデメリットはあるけど、hasuraとか使うとBFF作る必要なくなって開発速度上がるとかもある? BE側も参照系のAPI用意する必要なくなりそうだし..

自分なりの解

  • リソース指向でAPIを組み立てるで良さそう
    • ただ、gRPCとGraphQLではリソースの抽象度は違うと思っている
    • 最初にリソースの設計を雑にでもしておくと、API設計時にUIに引っ張られなくなりそう
  • BFFは一個だけで良さそう(理想論?)