お二方グラフQLどこまで知ってますか?ノンです存在と概要知るべきとこ押さえてそうまあまあある程度は本日ですねGoogleフォームにいただいたお便りからありがとうございますグラフQLについて教えてほしいというような

そんな胸のお便りがあったのでグラフQについて今日はお話ししたいなと思ってますすごい毎週お便り来てるもしかして確かにこれ人気ポッドキャストかひょっとしてこれもしかしたら読めない日とか来ちゃうかもしれないですね出てきちゃうかもしれない読めない日?もう来すぎてあーそういうことですね

まだ安心してくださいエピソードの最後ひょっとしたら2本になるかもしれないですがエピソードの最後にお便り紹介するスタイルでなので今回は早速本題に入っていくんですけど今日はですねグラフQLについてもともとなんとなく名前は聞いたことあるぐらいの人がグラフQLってなんで生まれたんだろうかみたいなどういう時に使えばいいんだろうか的なメリットデメリットだったり

すでにあるREST APIと比べてどうなんだと

いうことがわかるそんな話を今日はしていきます まあそこそこバズワードですからねまあそうなんですねそうそうねなんか良さそうっていう噂だけ聞くけどそう使ったことはないみたいな そんな技術ですねちなみたグラフ ql あるあるだと思うんですけどはいあのグラフ ql 後ろに ql ってついてるから sql の派生だと思いがちさっき言おうと思ってたけどちょっと止めてました止めてました 止めてたんだ

SQLの仲間ではないですか仲間ではないですが語源は一種の気がしますねまあなんとかクエリランゲージじゃないですかつので本日は参考書籍として初めてのグラフQLっていうオライリー本ですねもう評価爆高なんですけどそうなんだ2019年の書籍だったかなちょっと気がかったらすみませんがこちら参考にちょっと今日お話しさせていただきます信頼の一冊です信頼の一冊です

つうわけでグラフQLこれ何年に誕生した技術でしょうかはい1996年誰かの誕生日2016年惜しい2015年ですね16も間違えてないっちゃ間違えてないんですけど書籍は2015年にFacebookが公開したAPIの企画という風に書いてますねFacebookスタートだったよっていうのは聞いてますねそうなんですよ

すごいな企画企画ですねバックエンドに使うやつですね外観だけ言うとめっちゃ分かりづらいこと言いますよグラフ構造に着目してクエリ言語を用いて情報を操作しようっていうような考え方を用いたそんな仕組みになってますなるほど今のでもうね完璧に分かったね全部分かりましたグラフ構造って言っても思うんですけどグラフ理論の話がこの本でも出てくるんですが今回は

一旦なくても分かると思うんでグラフの話はすっ飛ばしてこれはパフォーマンスを出すための仕組みとしてグラフ理論が使われてるっていうだけなんで裏側で使われてるよってこと?そうですね一旦外観には関わってこないかなというところでがっつりここは省略させていただきますグラフQL2015年にできたって言いましたけどなんでできたと思いますか?なんかあれですよね

それに似た技術というか元の技術があってそれがちょっとここもちょっとこうしてほしいんだよなみたいなのがあってだいたい生まれるパターンじゃないですかその通りなんですけど世の中だいたいそうだったこれちょっと面白くてですね発端は2012年FacebookですねここのFacebookのところで

みんな使ってるFacebookのモバイルアプリを作り直そうって言うので当時FacebookはRestful APIとFQLっていうFacebook用のSQLそんなのあるんだっていう話ですけどそれで運用されてたんですけどちょっとユーザー増えてきたし扱う情報も増えてきてパフォーマンスに難があったと

あんだけ巨大なデータ使ってたらねそれでもたびたびクラッシュしてたのでやばいこれはちょっと改善せんとまずいって話になりよっしゃじゃあパフォーマンス向上のためにどうしよううーんよっしゃ企画作ろうっていうのでグラフQLが生まれましたすごすぎるよねやばくないやばい

新しい仕組み作っちゃおう既存のやつじゃ無理だからっていうので会社としてグラフQAっていうクエリ言語を作り始めましたすごいよねだってそれさもしさ車とかで考えたらさうわー車渋滞する空飛ぼうってことでしょ間違いのかな道路作っちゃおう違うのかな違うのかな

早く走れねーって言ってガソリンでも電気でもね新しいエンジン作ろうって話じゃないですか多分それっぽい例えで黙らせてしまったなるほどね2012年からそういう取り組みが始まって2015年にJavaScriptのプロジェクトにGraphQLを実装したやつが公開されたのが2015年

これがFacebookが公開した時期なんで2015年に生まれたとされてるんですが2016年にテクニカルレビュー版を出してそこから正式に使われるような企画としてグラフQLが生まれたっていうところがありますなるほどなのでこれが現在のFacebookのほぼ全てのデータ取得に利用されてます当たり前ですグラフQLがですねそうなんだそう

いやーさすがGAFAって感じですねこれはFacebookって何でしたっけ利用者10億人ぐらいいますよねいると思うよいそうそんぐらいですよねそれこそ東南アジアとかはTwitterとかインスタよりもFacebookですよね多分フィリピンはねもうFacebook大国でしたねですよねフィリピンはもうなんか

インターネットはお金かかるけどフェイスブックはお金かかりませんみたいなどういう仕組み?フェイスブックが多分フィリピン人の人のインターネット料金払ってるんじゃないかなっていう気がするマジですごすぎるどういうことやねんどういうビジネスモデルなのそれ謎謎そういうフェイスブックから生まれたのがグレフQLですとうーん

よく言われるのが結局これって既存のさっきも出てたRestful APIこれがいけてねーよなっていうので生まれたのでRestful APIの課題を解決するための企画ですとなるほどRestful APIって何ぞやとまず

改めて聞かれるとねてんてんてんってなっちゃうよね難しいかもしれない聞いてる方で知らない人がいるかもしれないんでここも丁寧に話していければなと思ってるんですけどなのでそこでじゅんぺいくんに丁寧に話してもらいたいなと思ってじゃあ僕からいいですかね丁寧に言わせていただくとみんなで分かりやすいルール決めてやっちゃおっていう思想設計思想うん

危ないなこれそうだよね逆にさよしみんなで分かりにくいやつ作っていこうってならんもんななんないっすね僕が知ってる感じだと4つぐらい項目というかみたいなのがあって1個がもう忘れたな1個があれです同じ

例えばJSON形式でやりとりずっとしようみたいなずっともだよみたいなずっともだよみたいなそういうのも一個決めるで2個目がのりさんにパスやべえパスされたけど俺の中のざっくりしたイメージいいですかURLあるじゃないですかURLはいURLのパスの部分はいはいはいでリソースを指定してHTTPメソッドでうん

どんな操作をしたいかっていう種類を指定してやり取りするとてもシンプルな通信方法だと

いう認識でいます僕はざっくりいいと思いますしざっくりで今回ではいいですありがとうございますノリさんのやつもう少し分かりやすく言うとどういうことなんですかね例えばですけどToDoっていうリソースがあったとしますとToDoに対してゲットリクエストを投げたらそのToDoの一覧が取れるしToDoスラッシュ1に対してゲットリクエストを飛ばしたらそのToDoっていうリソースのID1番のが取れるしうん

トゥードゥに対してポスト送信したら新規作成できるしプットもしくはパッチで送ったら更新できるしデリートで送ったら削除できるよっていうクラット処理が基本的にそのリソースに対してできますよみたいな感じになってたら一旦とりあえずレストって言っていいんじゃないかなと思ってますクラット処理はあれですね作ったり

クリエイト作ったりリード読み込んだりアップデート更新したりデリート消したりっていうのをまとめていうやつありがとうございますわかりやすい細かい定義多分レストめっちゃあると思うんですけど

その細かい定義を覚えるよりも今ので覚えちゃった方が個人的にはいいんじゃないかなって思ってます恥ずかしながら暗証はできないんですよ僕も結局ただそれはさっき言ったのりさんの原則にのっとってやると最終的にレベル2ぐらいのなんだ階層レベルだっけなんかねレストレベルみたいなやつがあるんですけどね

曖昧ですけどそのくらいのものを満たせたものは作れるんじゃないかという感じですかね要するにリソースベースにリクエスト投げてそのリソースに関する情報を全部まるっと返ってきますよがRESTful APIだと思うんですけどそんなRESTful APIの課題を解決しようというのがGraphQLですでも今聞くに実際使ってるじゃないですかRESTful API作ってるし

めっちゃ便利だなって思うわけですよめっちゃ便利分かりやすいめっちゃ分かりやすいしね作りやすいしねインターフェースって言って定義したどういうものを呼び出せば何が返ってくるかが分かりやすいから使いやすいし別に普段生活してて困んねえなと思ってますよ僕はそうですね便利だしね思うんですがただFacebookは違いましたデータ量が増えるとこいつはまだいけると

どんなとこ課題かと思ったかというとですね全部で何個あるんだろう1,2,333つの課題1個しか思いついてね完璧ですレストフルAPIレスト課題はないと課題なしですというのでノリさん聞きながら何個当たったか教えてほしいんですけど1つ目過剰な取得っていう課題ですねそういうこといやんこれどういうことかというとですねはい

先ほどののりさんto doって言ってto doでいいかなダイアリーとかにしとくダイアリーとかにしますダイアリーの中身どうなってるかよくわかんないけどユーザーにしときますユーザーにしましょうか例えばユーザーの位置を取ってきたときにユーザーIDとユーザーネームとパスワードとカンパニーとか

住所アドレスとかエイジとか書いてくるわけじゃないですかただこれ別に全部使うことないよね間違いないユーザーIDと名前だけでいいけど全部まるっと書いてくる

分かるわそれこことここで大体使う情報はユーザーなんだけどこっちにはこの情報がいるけどこっちにはいらないよねってなった時にどっちもカバーする大きいAPIを一個作るのかそれぞれにジャストフィットなAPIを作っていくのかでめっちゃ悩みますそうそうそうそうでし結局ねさっきのやつはもう一つの課題に絡むんでそこまで言わないんですけどそういう無駄ながらあるよね結局はいはいはい

これがグラフQLなら欲しいのだけ取れるんですよバカな後から言いますがこのRESTful APIの課題1つ目過剰な取得2つ目過小な取得小さいもんですねさっきのりさんが言った通りです

あーこっちにはいるけどこっちにはいらないよねの逆側の話そうですね複数のリソースを取得するときに複数リクエストを送らなきゃいけなくなるんですよ例えばユーザー1,2,3取りたいってなったらユーザー1のリクエストユーザー2のリクエストユーザー3のリクエスト3つのリクエストを送らなきゃいけない確かにそうめんどいそっか1回でやらせてくれと選択の取得は確かに考えてなかったなそうなんですようんうん

これがRestful APIだからこれによって無駄なリクエストが飛んだりするんですよだって1リクエストってリクエストボディの他にもヘッダーとか何やらやかんやら通信の確率で何やらやかんやら他に色々なやり取りがあった上でリクエストって成立するので3つ送ったりするとロスなんですよね確かになるほどなのでこれもちょっともう少しうまくいけるんじゃないかほうほうほう

レストークルAPIを普段使っている僕からするとこれ解決するのすごいなって思うんですよねやっぱグラフ級確かにねこれもちょっと後でお楽しみなんですけど3つ目エンドポイント管理ですねこれどういうことかというと本当にさっきのりさんが言ったんですがAPIを作ってどんどん機能開発していくとエンドポイントがめちゃめちゃ増えるんですよ例えばですよさっきのユーザーの話でどうしようかな

ECサイトとかだとユーザーテーブル設計ちょっとポカした想定ではあるんですけどユーザーwithカードみたいなインターフェースが生まれるかもしれないユーザーの情報とカード情報を一緒に返すAPIそんなの作り始めたらユーザーwith latest purchasedとかユーザーwith historiesとか

何々と何々を返すやつとかっていうのは考えやすいんですけどいろんなエンドポイントがガンガン増えていくんですよAPIってどんどん機能が増えるたびにねそうすると管理クソ大変なんですよエンドポイント増えるの良くないよねっていうのがRESTful APIの課題3つ目

なるほどね結局過剰な取得といらないレスポンスが含まれるよねが一つ目二つ目は何個も取るとき何回もリクエストしなきゃいけないよねが二つ目エンドポイントの管理が大変だよねが三つ目この三つの課題を解決するためにグラフQLが誕生しましたそんなんできるんだよいや無理無理無理すげーな

すっげーなんですよねすっげーなっていう話ですはいはいはいで時間的に非常に際どいんですがはいこれは切っちゃっていいんですかね切りますか切りましょう今何分ですか今今16分です切りましょうじゃあ次回は何を聞けるんですかはいじゃあ次回はですねはい課題がどう解決されてうんうん

どう実装されるのかとかあとはグラフQL実際に使ってみると今いいことしかなさそうですけどこんないいことあるしこんな悪いことあるよっていう悪いこともあるんだやっぱそんな話をしたいなと思いますなるほどそっちが気になるぜ歴史編じゃなくて実践編が次ですというわけで次回もお楽しみにということで

真ん中で切ったことないんで締め方よくわかんないんですけど一旦今日のまとめといたらどうですかそうですねそうしましょうか今日のまとめってお便りもついでに紹介しちゃいましょうかいっちゃいましょう尺があるんだよね今日のまとめですがグラフQAっていうのはFacebookで生まれてそのウェルストフルAPIのパフォーマンス良くないよねって言ったFacebookのエンジニアがよっしゃじゃあ企画作っちゃおうって言って新しくできた企画ですすごいわ半端ない

なので歴史としてはレストフルの課題を解決するのがモチベーションとしてあって過剰な取得過小な取得エンドポイント管理の課題を解決するために生まれた次は実際使ってみようというエピソードでしたちょっとね正直

今までは勉強してこなかった分野ではあったんですけどもバックエンドの知識がもともとあったので本がすんなり読めて非常に楽しかったですし勉強するきっかけを与えてもらって本当にありがたいですね強いやつの発想間違いないポジティブお便り最後に紹介しますラジオネームポーラーベアさんポーラーベアさん北極熊そういう意味か違う?わかんないで

ポッドキャストで話してほしいこととしてはグラフQLについて知ってみたいベストと違って何が美味しいのかどんな時に使うといいのか習得大変かなどほう

次回じゃあ判明していく感じだね感想仕事する前にモチベーション上げさせてもらってますいつもありがとうございますその言葉でこちらのモチベーションを上げさせていただいておりますお世話になっております営業だ営業の人だウィンウィンですねこういうことによってね僕らの知識も増えて聞いてる人の知識も増えてウィンウィンウィンですねウィンウィンウィン最後のウィンは

僕らお便り送った人リスナーです散歩よしという感じで終わりますかエンディングトークもないですねエンディングトークはないですまた次回バイバイ

ちょっとやりとりしたい人はメール気軽に送りたい人はGoogleフォームツイートお願いします詳細は説明欄を見てくださいポッドキャストのフォローコメント評価してくれるとバカ騒ぎしますそれではまた次回