RESTful API との比較で GraphQL API を作ることの難しさ｜qsona

上の資料でも書いてるんですが、要点を言うと以下のようなことを主張している。 API の設計手法として、以下の2つのパターンが考えられる ・Resource-based API ・Usecase-based API Usecase-based というのは要はクライアントの要求にそのまま沿った形で API を作るということだ。しかし、UI やその他クライアントの要求というのは変わりやすいものなので、そのたびにいちいち API を変更しないといけないとか、API に一貫性がなくて使いにくいとか、1つの endpoint で多数の要求に対処する "神API" が作られてパフォーマンスが悪化する、というような問題が起こる。 したがって、注意深く RESTful API を設計すると Resource-based になる。ここで言っている Resource というのはテーブル設計にやや近いが、そのまま

[c-matt]

内容からは外れるんだけど、GraphQL使うとモニタリングに今までの手法が使えなくてコストが跳ね上がってしまうのみんなどうしてるんだろう。

[turanukimaru]

N+1 問題は画面側で起きるのがRESTでサーバ側で起きるのがGraphQLではなかろうか。難しさはRESTはエンティティ単位だけど画面はそうとは限らないから便利APIが生まれるという話でGraphQLは別にこれを解決してくれたりはしない

[efcl]

RESTだとユースケースごとのAPIが作りやすいけど、GraphQLだとResourceベースになってユースケースは制御できない。 モデリングをユースケース or ドメインどっちから考えるかという話なのかもしれない

[hachibeechan]

そもそもまともな規格も何もないRESTfulはGraphQLの比較対象じゃないというのが僕の意見。あとusecase baseかresource baseかは作ってるサービスの種類や規模、チーム体制によって変わるので汎用の解答はない

[masa8aurum]

・GraphQL APIを作るならusecase-based でなくresource-basedな思想で作るべき ・resource-based API を作るならGraphQLのほうがむしろ楽 ・resourceについて考察しない（設計を練らない）ならusecase-basedもありだが、そのしっぺ返しは早く来る

[petitviolet]

リソース指向でグラフ構造をGraphQL APIとして提供さえしておけば、クライアント側で各画面特化なクエリを構築できるというのがメリットだし、N+1はRESTだと回避にはAPI設計に工夫がいるがGraphQLなら実装で回避出来る

[ed_v3]

リソースベースこそRESTな気がする。"GraphQL API を作ると N+1 問題が起きやすいので注意が必要" これもRESTのデメリットでむしろこれを解決するのがGraphQLだったような。

[otihateten3510]

API利用側でハンドリングできるのは期待してるけどまあ10年は必要でしょう。

[mayumayu_nimolove]

つかGlaphQLのメリットがわかってれば難かしくても他人のソース見ながらでもやるだろ。メリットで判断して必要ないと感じれば覚えなくてもいいし。

[onesplat]

何言ってんだこいつ

[monomoti]

あとで