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

Backends for Frontends的に、1画面につき1つずつAPIを作っていると、画面のリストを作って、それぞれ1画面につき1個ずつAPIを作っていくことになるので、進捗の把握がやりやすかった。10画面あって3APIできてたら進捗30%ということになる。

グラフをたどって開発することになる

GraphQLでAPIを作っていると、「実はこの画面を組み立てるためのクエリは、あちらの画面の条件を変えたものである」みたいなことが起きるようになる。たとえば、トップページではサマリを表示していて、もっと見るを押すと全件表示するような場合とか。
このように、着手しようとするともう作るものがなかったりとか、逆に、作るときに、他の画面から使う想定でパラメータの設計をするなど、考えることが増えたりもする。
スキーマに沿ってグラフをたどるだけで画面を組み立てられるのは良いことだけど、開発内容の依存関係が一見するとわかりにくい。
グラフの探索というと、さまざまなアルゴリズムがあるけど、グラフをどう実装していくか、という作戦も、幅優先でトップレベルから使いたいものを順に作ることもできるし、深さ優先で1パーツずつ着実に作ることもできるし、確実に使いそうなResolverやDataLoaderからボトムアップに作っていくこともできる。

衝突回避

開発を進めていくときも、この情報はこっちのオブジェクトのこれ、みたいに、いきなり別の画面用に開発する予定だったフィールドにたどり着いてしまったりする。
複数人で分担して作業しているときに、二人で同時に触ってしまうと、同じものを2回作ってしまうことになったり、お互いが回避すると気づくと実装されてない、みたいなことが起き得る。
ぜんぜん違うところを触るなら大丈夫そうだけど、1画面のうち2コーナーなどを同時に作っていると、作業場の依存関係が発生することがたびたびありそうな印象だった。

落ち着いて開発できるならボトムアップにするのがよさそう

餅つきやわんこそば的にViewもどんどん作って結合していきたい、みたいな事情がなくて、落ち着いて開発できるなら、ボトムアップに、ドメインモデルまわりから定義していくと、出たとこ勝負でtypeをどんどん追加するような混乱を回避できるとと思う。
Atomic Designとかをイメージすると、Atomsから順に作っていくはずで、Pagesから考えて必要に応じてAtomsをどんどん足していくと統一感を得にくいと思う。

スキーマのレビューを通しておく

あと一つ思い出したので書いておくと、実装までやらずに、スキーマ段階でレビューを通すのがおすすめ。
スキーマを読み書きするだけなら、他メンバーと合意する手段としては手軽で、実装まで済んだあとにスキーマからやり直しになるよりは、早い段階でコストを小さく試行錯誤できるほうがよい。
クライアントサイドが別チームになっているときには、ユースケースを満たせるか確認できるし、スキーマさえあれば、Apollo Serverなどから読むことでモックサーバーを動かすとか、作業を進めることができる。