GraphQLとRESTfulについて今日考えてたこと Backend for Usecase/Resourceについて - 余白

DISCLAIMER: これは本当にただのメモ書きで、これがベストプラクティスだとかいう話ではないので、同じようなことを考えてる人いたら今度議論しましょうよ、って程度の話の種。 GraphQLを使うべきスポット、RESTfulが好ましいスポットについて今日ぼんやり考えていて、なんとなく言語化ができる気がするので文字起こししてみる。 Backend for UsecaseとBackend for Resource バックエンドのAPIには2種類あって、 「データ」を構成する「リソース」を提供するもの アプリケーションの「ユースケース」がもつシナリオのなかで登場する「データ」部分を埋めるためのもの を区別することが必要そう、と思っている。 まず前者を Backend for Resource (BFR)と呼ぶことにする。これはわかりやすくて、これはまさしくRESTfulそのもの。 RDBやそう

[phanto]

良いと思う。ただ、再設計のリスクは減るけど、BFUとBFRの切り分けで、仕様と業務理解についてより多くのスキルを要求されそう。あと人の出入りが激しいプロジェクトだとそのポリシーを維持することに対する課題あり。

[adwd118]

データストアやマイクロサービス間はリソースで、フロントエンドはユースケースでその間をつなぐのにGraphQLは便利　っぽい

[yutaszk23]

`あるいはBFRが拡張されてユースケースを受け入れはじめる` と維持するのがとてもつらくなるんだよなあ、すごい綺麗にまとまっててすごいわかる

[tkawa]

ユースケースという着眼点は納得。1つのRESTful APIで極端に異なるユースケースに対応するのはたしかに難しい。しかし更新系が入ってくるとGraphQLでもたぶん難しい

[tyru]

なるほどー REST と GraphQL 両方使うみたいなのもアリか。記事で言ってる様にリソースと画面で必要なデータに丁度いいのがなかったり、あとリソースで表現しきれなかったりするものは GraphQL 使うとかすると便利なのかな？

[vvakame]

複数のユースケースを1つのクエリにするのは正しい。ただし、ユースケース毎に個別にfragmentを定義せよ。というのが僕の今の理解。正しいかは知らん。

[iga_k]

lacoさんのGraphQL知見

[massa142]

“ユースケースにとってはユーザーの名前がUserテーブルのNameカラムに保存されているとかそんなことはどうでもよく、ただユーザーの名前がほしい、というニーズだけがある”

[qsona]

再読。システム改修の種別ごとの改修範囲の図がとてもよくまとまっていてわかりやすい。

[braitom]

Backend for ResourceはRestful、Backend for UsecaseはGraphQLが良いのでは？という話。なるほど。

[raimon49]

BFF用途にGraphQLが向いててRESTとはシステムのライフサイクルが違う、という整理にしっくりくる。

[bump_sunbear]

"BFRが拡張されてユースケースを受け入れ始める"あるある

[roadhiax]

GraphQL

[griefworker]

GraphQLはBFFに便利そうだとは思っていた。

[tsugitta]

R→UのラッパーとしてのGraphQLは半端になることが多々ある気がして、そこはクライアント側に寄せるのも自然に思う。あとBFUだとキャッシュさせづらいのと冗長なリクエストが多くなってしまう感あるのも気になる。

[otherworld]

マイクロサービスとBFFそのものという気がするけど、名前を変えることで役割や責務を意識しやすくしたい…ということなのかな？

[ryopeko]

今日らこらこと雑談していた内容のまとめができていてハイパー便利を享受している。こういうところに踏み込んで行く必要がありそうだよねって話しをしていたけどまだ答えに行き着いていないという感じ