#12 – Semantics and Complexity of GraphQL
GraphQLを分析した論文 “Semantics and Complexity of GraphQL” を向井が紹介します。感想などはハッシュタグ #misreading か hello@misreading.chat にお寄せください。 Semantics and Complexity of GraphQL GraphQL the morning paper / Semantics and Complexy of GraphQL NL-complete (日本語) Correction エピソード内でクエリ結果のサイズ評価について議論していますが、論文をちらっと読んだかんじでは向井さんの主張が正しそうです。自分はなんとなくスキーマの ER 図みたいのを想像しながら話を聞いていましたが、この人のいうグラフはオブジェクトDBみたいなグラフで、何かを評価する際にスキーマなどはおまけみたいなも
GraphQLはRESTの置き換えではない｜こんぴゅ
GraphQLは最近注目されているWeb APIのための問い合わせ言語だ。 現在主流のRESTfulなAPIはURLとmethodでリソースを表現するわけだが、GraphQLは単一エンドポイント（ex: "POST /graphql"）だけ存在し、欲しいリソースをHTTP POSTのbodyに明示的に記載してリクエストする。 ↑JSON APIをGraphQLの形式でコールする（引用: how to graphql ) 徐々に実装例が増えてきており、2016年にはGithubがAPIの実装を全面的にGraphQLに移行させたのが注目された。 色々調べていくと、GraphQLは単にRESTの代替ではなく、開発・運用フローを一新させうるほど豊かな思想・機能を含む事が分かって来たので現状の整理をしてみたい。 APIリクエストを束ねて効率化RESTではURLがひとつのリソースを表すため、複数のリソ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
