1画面1APIと比べるとGraphQLのAPIはどこから作ったらいいか分かりにくい - hitode909の日記

Backends for Frontends的に、1画面につき1つずつAPIを作っていると、画面のリストを作って、それぞれ1画面につき1個ずつAPIを作っていくことになるので、進捗の把握がやりやすかった。10画面あって3APIできてたら進捗30%ということになる。 グラフをたどって開発することになる GraphQLでAPIを作っていると、「実はこの画面を組み立てるためのクエリは、あちらの画面の条件を変えたものである」みたいなことが起きるようになる。たとえば、トップページではサマリを表示していて、もっと見るを押すと全件表示するような場合とか。 このように、着手しようとするともう作るものがなかったりとか、逆に、作るときに、他の画面から使う想定でパラメータの設計をするなど、考えることが増えたりもする。 スキーマに沿ってグラフをたどるだけで画面を組み立てられるのは良いことだけど、開発内容の依存関係

[onk]

TDD と同じこと言ってる気がする。実装が見えてる場合は一気に実装してもよくて、見えてない場合は必要と分かっているところから。 / オススメは随時認識合わせながら (常にペア作業しているとより良い) 深さ優先です。

[holyshared]

先にモデリングして、画面用のクエリとかは後にしてる。 スキーマだけのPR出して、みんなでレビューしてる。

[ledsun]

（一般論として）GraphQLがほしいのは、REST（画面とリソースが1対1）が合わないユースケースが増えてきたから、とかなのかな？

[gg119104]

ドメインモデリングとイベント駆動開発マジおすすめ