GraphQL
https://graphql.org/ https://gyazo.com/44743b96918357f337c9645af43891da
server/client間のHTTP APIの実装パターン
サーバーにある1つのエンドポイントに、必要なデータのmodelとschemaを要求する
最小のリクエスト回数で、必要なデータを過不足無く返せる
mh.iconが檄押しのAPI設計
また、facebook apiは全面的にこちらに移行したらしい
こういう雰囲気で全部のapiを一つのjsonっぽいもので管理する
https://gyazo.com/1497375b32c3c1499fe056105ecb8f7d
日本語の記事
RESTの問題を解決しようとしているようだ？（調査中shokai.icon） modelの数だけHTTPリクエストを送る必要があり、全部揃うまで画面を構築できない
Fat modelを作ると、clientが必要としない大量のプロパティ送受信して、データサイズが無駄
そんなに問題かなあ、という印象shokai.icon
DB schemaとAPI仕様が密結合しがちshokai.icon
パフォーマンスが出るDB設計の都合に、web APIが引きずられてしまう
綺麗なRESTを保つには、DB構成の変更と同時にweb APIを変更し、clientライブラリも変更しなければならない
難易度高すぎる
実際無理なので、まったくチューニングできない
上の2つがよく言われるけど、密結合こそがRESTの問題な気がするがどうなんだろう？shokai.icon
完全に同意です。DBのSchemaを直接弄るのは便利かもしれないが、ビジネスロジックの層が無いことで、Schemaが複雑になり余計混乱しそう。ytanaka.icon
それともあれか？ビジネスロジックは全部Schemaで表現可能という仮定があるのか？
DB/API/clientライブラリ密結合問題、GraphQLでも解決できなそうな気がするshokai.icon
たぶんいちばんGraphQLに近いのはmongodbのhttp APIだと思うshokai.icon modelの必要なプロパティをclient側が指定し、serverは過不足無く返す
なお、mongo直接だと当然スケールはしない
RESTと比べると、かなりよく考えてURLとcacheの対応パターンを設計しなければならない気がする
むかし、SQL wrapparでキャッシュ機能を作ったことがあるが、SQL文を解析してのキャッシュは大変だったrakusai.icon
rakusai.icon
TwitterやFacebookでは、サービスの内部のDBがそもそも一つではない。
ツイート情報は、XXX DBだけど、ユーザー情報は YYY DBというようなことが普通になっている。
さらに呼び出してる言語も違ったりする。ツイート情報はscalaで、ユーザー情報はrailsとか。
そうするとスキーマはもう内部でぐちゃぐちゃなわけでRestでもGraphQLでもあまり変わらんということになる。
むしろGaphQL化するとAPIの構造を一貫性をもって設計する制約がうまれてよい、みたいな話になる
また、gem, npm等の各種プログラミング言語に対応したライブラリが作りやすくなる
なので、このような規模が拡大したサービスほどGraphQLの恩恵を受けやすいという印象
Developer exeperiece（開発者にとっての使いやすさ）という観点からみると、多くの開発者は一部のapiだけ使うことが多いだろうから、restのほうが取っつきやすいだろうと思う。その観点でよっぽど使いやすい開発/デバッグツールか、ライブラリの自動生成ツールがでてこない限り、graphQLには置き換わらないと思ってる