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

DISCLAIMER: これは本当にただのメモ書きで、これがベストプラクティスだとかいう話ではないので、同じようなことを考えてる人いたら今度議論しましょうよ、って程度の話の種。 GraphQLを使うべきスポット、RESTfulが好ましいスポットについて今日ぼんやり考えていて、なんとなく言語化ができる気がするので文字起こしし...

記事へジャンプ

みんなの反応

はてなブックマークでの反応
1ryopeko@hatena 2018/07/13 00:26
今日らこらこと雑談していた内容のまとめができていてハイパー便利を享受している。こういうところに踏み込んで行く必要がありそうだよねって話しをしていたけどまだ答えに行き着いていないという感じ
2yutaszk23@hatena 2018/07/13 00:40
`あるいはBFRが拡張されてユースケースを受け入れはじめる` と維持するのがとてもつらくなるんだよなあ、すごい綺麗にまとまっててすごいわかる
3adwd118@hatena 2018/07/13 01:49
データストアやマイクロサービス間はリソースで、フロントエンドはユースケースでその間をつなぐのにGraphQLは便利 っぽい
4otherworld@hatena 2018/07/13 09:21
マイクロサービスとBFFそのものという気がするけど、名前を変えることで役割や責務を意識しやすくしたい…ということなのかな?
5phanto@hatena 2018/07/13 09:23
良いと思う。ただ、再設計のリスクは減るけど、BFUとBFRの切り分けで、仕様と業務理解についてより多くのスキルを要求されそう。あと人の出入りが激しいプロジェクトだとそのポリシーを維持することに対する課題あり。
6tsugitta@hatena 2018/07/13 10:13
R→UのラッパーとしてのGraphQLは半端になることが多々ある気がして、そこはクライアント側に寄せるのも自然に思う。あとBFUだとキャッシュさせづらいのと冗長なリクエストが多くなってしまう感あるのも気になる。
7Cside@hatena 2018/07/13 10:39
基本 BFF 使わない環境にいたし、それでなんとかなってたのであまりピンとこなかった ...
8griefworker@hatena 2018/07/13 10:49
GraphQLはBFFに便利そうだとは思っていた。
9vvakame@hatena 2018/07/13 11:02
複数のユースケースを1つのクエリにするのは正しい。ただし、ユースケース毎に個別にfragmentを定義せよ。というのが僕の今の理解。正しいかは知らん。
10bump_sunbear@hatena 2018/07/13 14:10
"BFRが拡張されてユースケースを受け入れ始める"あるある
11peko-the3rd@hatena 2018/07/13 14:32
"本来関係をもつはずのないユースケース間の関係を生んでしまう"ほんこれ。纏めるという事の意味を間違えている人とはやり辛い
12ka2hik0@hatena 2018/07/13 15:03
うむ
13tyru@hatena 2018/07/13 15:51
なるほどー REST と GraphQL 両方使うみたいなのもアリか。記事で言ってる様にリソースと画面で必要なデータに丁度いいのがなかったり、あとリソースで表現しきれなかったりするものは GraphQL 使うとかすると便利なのかな?
14tkawa@hatena 2018/07/13 15:51
ユースケースという着眼点は納得。1つのRESTful APIで極端に異なるユースケースに対応するのはたしかに難しい。しかし更新系が入ってくるとGraphQLでもたぶん難しい
15raimon49@hatena 2018/07/13 17:17
BFF用途にGraphQLが向いててRESTとはシステムのライフサイクルが違う、という整理にしっくりくる。
16braitom@hatena 2018/07/14 23:32
Backend for ResourceはRestful、Backend for UsecaseはGraphQLが良いのでは?という話。なるほど。
コメント内容の著作権は、投稿者に帰属します。
削除依頼、不適切コメントのご連絡はこちらにお願いいたします。
2018-07-12 15:36:01:1531377361:1531819158
comments powered by Disqus
※メールアドレスは公開されません。
人気の反応
20