#091 【聞くだけGraphQL後編】使い心地と作り心地体験編！GraphQLの弱点とは？

2022/11/13 ·

00:01
はいではグラフQL後半ですね後半戦前回はですねグラフQLがまあFacebookで誕生しましたよFacebookマジすげーっていう話をしましたはいざっくりねですねはいで今回はじゃあグラフQLの使い心地どうなん的な話をしていきます使い心地はい気になる使うって言ってもね呼び出す方もありますしサーバーがありますしねあとはなんか設計どうなんだとかね
00:27
私が気になったところを中心にいろいろ話していこうかと思いますはいお願いしますじゃあまず使い勝手のところからですねレストフルAPI叩いたことありますかお二人もう叩き散らかしてますねあります壊してますかもう散らかってますグラフQLがですね結構呼び出し方が特徴的でしてそこのところからさらっとお話していきますまず違うところその1全部ポストでやります
00:57
全部ゲットもデリートもポストもアップデートも全部全部ポストリクエストですこれなんでかっていうと基本的にグラフSQLってリクエストボディにJSON形式でどんなリソース呼び出すとかどんなリソースどういう操作する
01:24
みたいなリクエスト情報を突っ込むのでポストじゃないとボディ持てないので全部ポストでやりますなるほどポストの中でもコマンドを書くんですよボディに例えばいわゆるゲットとかデリートみたいなものを全部ミューテーションっていうコマンドなんですけどミューテーションってJSONの中に書いてミューテーションの
01:54
キーバリューを想像してくださいJSONのキーバリューミューテーションをキーにしてバリューの中に操作内容というか操作するモデルの内容ユーザーズの位置ネームノリみたいなのをひっくるめてミューテーションを送るとないやつはできるしすでにあるやつはアップデートされたりしますミューテーションともう一個なかったっけなんかはいそれはこの後出ますはいはい
02:24
一旦分かりやすい違いはこういう感じですかねもう少しちょっとブレイクダウンしていくんですけど基本的にSQLみたいなものを思い浮かべていただければいいですSQL言語ですね基本的に言おうと思ってましたSQLってさ書いてる文章同じだけどきっと投げるところの機構って全部同じなんだろうなって思ってたんで
02:49
SQLグラフQLいやSQLですSQLってさセレクト文書いて投げたらセレクト文動くしアップデート文書いたらアップデート文動くじゃないですか動く動くっていう感じでボディになんかその命令を書くけど飛ばし方は同じなんだろうなっていう風に思ってましたポストで全部やってるみたいな結局SQLもポストかどうか知らんけど似たような感じなのかなって思ってました確かにそれイメージが近いかもしれないですねはいっていうのでえーと
03:18
さっきミューテーションっていう話をしたんですけどさっきゲットとかデリートって言ったんですがちょっと思考を変えていただいてインサートアップデートデリートって考えてくださいミューテーションはミューテートって変異させるとかって意味だからデータベースをいじる系の操作がミューテーションってことですよねその通りですね
03:38
リソースを指定するのはなんとなく想像つくじゃないですかそれだけじゃなくてメソッド的なものを定義できます定義じゃないや指定できますメソッドもポストフォトみたいなメソッドを定義するとポストフォトしてくれるへーみたいな機能も呼び出すことができます定義を決めておいて使い回せるよってことですかサーバー側でもともと定義されているメソッドを呼び出せるって言うんですかね
04:07
超究極一つのメソッドでユーザーも作れるしユーザーに紐づく会社名とか登録できるし複数リソース操作できるとかそういういろんなことをやりたい時に多分使うんでしょうけどそういったメソッドも用意することができます利用することができるか今クライアントの話だっけこれ今クライアントですね呼び出し心地の話をしてます今呼び出し心地ですね2つ目
04:41
これちょっと驚きなんですけどデータの変更監視をするサブスクリプションという機能がありますどういうこと?監視をする?これはですねソケットを使ってデータベースの変更を監視できるんですよつまりリクエストをもう一度出さずとも数字が変更したら変更したぞっていう信号を受け取ってアプリケーションに反映することができます
05:06
イメージがつかないと思うのでもっと具体的な話をするとFacebookを思い出してくださいFacebookを思い出しましたいいねの数ページ更新なしで更新されますよねされるんですよいいねされたら自分の投稿いいねされたらページ更新走んないでいいねの数増えるんですよ
05:28
でもあれって別に普通でも定期的にリクエスト飛ばしてたらできるじゃないですかそこのリクエスト飛ばさずにレスポンスだけ返ってきてるってことですかそうなんですあれはソケットで通信ずっと繋いでてリソースが変更されたらほぼリアルタイムで
05:52
更新されてるんですよ省エネソケットとは何でしょう通信をする際に用意するパイプみたいなものだと思ってますありがとうございますパイプですね通信経路的なそれが繋がってる間はずっと通信が続いてるみたいな対応ですよね確かにそういうのいいねどんどん出していこうなんとなく使っちゃったわ
06:21
一回繋いじゃえばもう勝手にやってくれるんですねそうすると経路を作るとか他に何で使うかっていうとそれこそDBとAPIの接続ソケットでやることありますよねやってますねESQL.socみたいなファイルできてるわ確かに
06:43
あとの用途はちょっとよくわかりませんねなんかあるかな通話かなあとなんかWebRTCとかその辺も使ってそうな気はするWebでの通話ZoomとかGoogle Meetとかは多分ソケット通信だと思うが曖昧ですなるほどそういうなんか常時接続してる系は基本的にソケット通信かなはいうんうんうん
07:06
まあなのでこれすごいんですよねだから db の中身が変更されたのページ更新なしで受け取れるってそれ今ソケットがつながってる人だけに行くってことですよねそうですねすっごい量のソケット通信になるんじゃないのそれねフェイスブックとかの規模になるとそういや正直あの僕もそう思っててそのソケットってなんだっけあれポート縛るんですよねポート番号1ポート使うんじゃなかったっけ
07:34
使わないっけなじゃあすいません曖昧ですがだとしたら足りなくね?ポートそうなんですよ足んないと思っててどうすんだろうなと思ってますがちょっとすいませんここは分かりませんでしたでも多分作っちゃうぐらいの人たちだからこれはパフォーマンス問題あると思うんですがそういうサブスクリプションっていう機能がありますもう一個ですね最後インストロペクションっていうインストロペクションこれあのまあ
08:04
触り心地の話で変わった機能だなと思ってるんですけどGraphQL APIの呼び出し得るものモデル全部返ってくるっていうリクエストがありますこうやったら呼び出せるよみたいなメソッドとかリストが取れるってことですか公開APIのリストが取れるみたいな設計者APIでいうオープンAPIみたいなAPI設計者的なものが返ってくるっていう機能があります
08:36
インストロペクションロ入るんですかインストロペクションって書いてましたねインスペクションなら聞いたことあるけどインストロペクションって書いてました英単語でよくわかりませんこれは何のためなんだと思ったんですけど本ではフロントエンドの人とのコミュニケーションが取りやすくなるって書いてたんで多分開発とかそれこそAPIドキュメントとか見ずとも本当に試しにこのAPI叩いてみようって時に開発者が
09:09
インストロペクションを呼び出してああこういう構造になってるのねって言ってた本当になんかAPI使用書みたいな感じで使えたらいいよねって感じで多分そうなんつけちゃったのかなこれはそこまで使い道ないなと思いつつあんのかなでもAPI設計書に書いてるだろうからなまあでもあれじゃないかAPI設計書だとそっちを更新し忘れると
09:33
ずれた状態になっちゃうけどインストロフェクションならずっと最新の状態で反映されてるから信頼のおけるドキュメントみたいになるのかな信頼をおけますね少なくともっていう感じの呼び出し心地のざっくっとしたコマンドベースですねミューテーションとサブスクリプションとインストロフェクション3つがありますアリさんが出てきました今あれミューテーションの話してる時にもう1個あるよねみたいなミューテーションとクエリーってなかったですか
10:05
クエリだって?何だっけな?なんかゲットは別だったような気がするんだよねミューテーションじゃなくてミューテーション使わないで普通に呼び出すとか?調べますあーはいはいはいはいすいませんありますねあります?はいミューテーションじゃなくてクエリっていうキーを付けて中身突っ込むとゲットができるっていうのがありますねへーはいこれあのRestful APIの課題を解決する面白ポイントで
10:34
これなんと複数のリソースを一気に指定できるというかユーザー1ユーザー2ユーザー3を一気に指定してリクエストするとユーザー1ユーザー2ユーザー3を一気にレスポンスとしてもらえると1,2,3クリエイターといったらもらえる感じですねこれ非常に
10:53
レストフルAPIじゃできない指定の仕方ですねなおかつ前言った通り指定したレスポンスだけ来るんでネームとか1個のリソースの特定の
11:06
絡むだけというか取れるとマジで裏側どうなってんだろうってめっちゃ気になりますねこれユーザー1の名前ユーザー2の住所ユーザー3の年齢とかでもいけるってことですかいけるいけるどういう時に使うかなかなかないシーンだと思うクエリの中の書き方がすみませんちょっと特徴的でした失礼しましたJSONって言ったんですけどJSONじゃないです違うんだあれ違います
11:34
何が違うかっていうと基本的にJSONっぽいんですがなんて言おうかな見てくださいこれはちょっと見ないと分かんないかもしれないですキーバリューJSONのキーバリューってキーがあってコロンがあってバリューカンマ次のキーバリューカンマみたいな書き方するじゃないですかクエリってちょっと違くてですねキーバリューみたいな形でコロンがあってバリューがあるやつと
12:06
コロンがないやつがありますジェイソンっぽいけどちょっと文法違うよねみたいな感じなんださっき言ったユーザーの中でネームとかIDとか複数要素のキーを取得するときは開業ですねカンマもないです開業で個数を分けるというか
12:33
シンプルJSONよりシンプルな書き方になってるかなと思いますこれはちょっとすいません見てくださいなんとも言えないですっていうのが使い心地のところでクライアントとして叩こうと思ったらこういう違いがあるんだっていうところですねなるほど1個のエンドポイントに対してこっち側で欲しい情報を指定して送れば欲しい情報だけが返ってくるっていうのが肝ってことですかそうですね
12:58
ポストで欲しい情報だけ送ってクエリリクエストだったらクエリコマンドだったらゲットだしミューテーションだったらインサートアップデートデリートができるよっていうざっくりそうですねなるほど裏側が気になります裏側って言っても正直仕組み部分で言うとさっきの叩くところで言うと普通に気合で実装できるじゃないですかカールとかでも特殊なライブラリーなしに実装できる気しませんか
13:32
リクエストボディに欲しいキーを呼び出せるようなクエリをストリングで書いてそっちはねなので普通のhttpクライアントでグラフQLのAPIって呼び出せるんですよそれはできそうですねもちろん
13:51
グラフQL用のモジュールはあるライブラリモジュールはあるのでそういうのを使った方がもちろん実装は楽だと思います裏側裏側サーバー側ここですよ設計ですよまずグラフQL設計してください何します?積みましたもう積みましたとりあえずライブラリを探します本当だよねライブラリは使うんですけどももちろんライブラリ使わない方法はせません本日は言えないです
14:19
その話は載ってないライブラリ使った方がいいです絶対設計なんですけどまずRESTful APIの設計するとき第一歩何するかっていうとエンドポイントの設計するんですよどういうことかというと何のリクエスト送ったらどういうレスポンスが来るっていうのを書きますなのでユーザーズhttpsこのアプリケーションのドメインとURLスラッシュユーザーズ
14:51
レスポンスでユーザーの一覧が返ってくるレスポンスを書くみたいな200みたいなのをRestful APIの設計書を書くときには使うでもグラフQLって思い出してくださいエンドポイントないんですよそうなんですよねもしかして何もしなくていいとかですかさすがにそんなことはないそんなことはないですか究極そういうことかもしれないですねクライアント向けの設計書はいらないのかもしれません
15:23
今話してて気づいたんですけどインストロペクションってあったじゃないですかあれで十分なんですよねひょっとしたらもしかしてリソースだけ書いておけばあとはいい感じに組み合わせてくれるとかですか言っちゃいますね確信ついてるかもしれないですねマジでそうですだとしたらめちゃめちゃすごいと思うんですけどそうなんですよ
15:49
ちょっと凄さをまだ分かってないです徐々にいきましょう僕らはゆっくり進みましょうノリさんは今2週目楽しんでるんだけど顔がすごいもん険しいエンドポイントないんでAPIマンからすると何したらいいんだってなっちゃうんですけどはい
16:07
どっちかっていうと DBのテーブル設計に近い感じで進めていくのかなという印象を受けました私は確かにどういうことかというとですねスムさんもう日本先って言ってるんですけど確かにどういうイメージかというと各リソース例えばユーザーズユーザーズには何が入ってるんじゃとさっき言ったユーザーIDとネームあと何もう何入れてもいいんですけど年齢とかね
16:33
そういうのをどんどん定義していきます定義は何かっていうと型とかストリングイントフロートあとバリデーションとかね何文字以内とかねバリデーションもいけるバリデーションもいけますねあとは他のリソースと一対一対応してるとか一対一対応してるとか関係性も書かなきゃいけない関係性も書かなきゃいけないなんでユーザーズの中になんかカンパニーとかあったら
17:01
多分ユーザーズが他でカンパニーが1ですかねすいません副業は禁止です副業禁止だったらカンパニー1でユーザーさん関係になりますよねそういうのも最初のモデル定義の時にやっていきます本当にDBのテーブル設計を思い出すようなER図書くみたいな基本的にこういう風にやっていってリソースを定義していきますこうすると
17:33
呼び出し側を覚え出していただくとクエリとかゲットの操作とかはこのモデルの定義だけでできるようになりますただちょっと他にもあってミューテーションとかサブスクリプションをさっき言いましたけどミューテーションはインサートアップデートデリートただリソースの操作だけであればさっき言ったモデルの定義で終わるんですけどミューテーションってコマンド呼び出せるって話したじゃないですか
18:00
極端なことを言うとDelete Allみたいな全部消すコマンドみたいなバルスみたいなねそういったものは別途定義する必要があるのでそれはミューテーションの設計としてモデルの設計の他にはより必要がありますもう一個サブスクリプションの設定ですねもし利用するのであればこのモデルのこのリソースの監視をするサブスクリプションの設計も必要ですただ大まかなポイントとしてはモデルベースでやっていく
18:32
モデルの定義をベースにやっていくのがグラフQLの設計になりますエンドポイントいらないんですよねすごいよ言うたらだからDBのやつそのまま書き写してもいいんじゃないかっていうね本当それだよね多分そうだと思いますER図作ったらほぼ完成してると言っても過言ではないんですね中間テーブルとかその辺をどうするかだよね確かに
18:56
その辺はねちょっとねすいませんあのディープに使ってないんでなんとも言えないですねなんか叩いたでつなげてそれでもうつながるならまあいいよねそうそうそうそうそうで今のような頭で設計はなんとなくできたと思うんですけどこれを書く言語にグラフQLのライブラリがあるのでそのドキュメントを見ながらお作法を書いてくださいなるほどねそれでグラフQLのAPIサーバーを
19:22
ブートなんていうの起動すればグラフ系のサーバーが動きますサーバーもなんか特殊なのあるんですかライブラリですただのそういうことかレイルズみたいなフラスクみたいなラベルみたいなのがありますこれはグラフQLの普及協会みたいななんとかオーグ
19:47
なんとかオーガニゼーションがやってるんで貼っとくんですけどそこで本当に書く言語多分全部あるんじゃないかなファットミって大体あるなと思ったんでそれらを使うと簡単に実装ができますなるほどねクエリランゲージって言ってる意味が分かった気がしました本当にそうなんですよSQLっぽい今までだとクライアントがリクエスト送ってサーバー側でクエリを作ってデータベースに問い合わせてたけど
20:13
クライアント側でクエリを作ってサーバー側でそれを組み立ててくれるみたいな感じで1個前に来た感ありますよね処理が伝わってますよさっきのりさんが何で言ってたんだっけななんかすっきりしてましたよねあれですかサーバー側で
20:38
データというかリソースの定義したらいい感じにやってくれるんですかねそうそうAPIとかだとさっきのりさんが言ってたようにデータベースに入ってるやつをうまく整形して送るとかそういうのやらなきゃいけないけどDBに入ってるような設計をそのままサーバーにポンと置くだけでクライアント側が使いやすい形で勝手に出してくれるとここまで聞いたらグラフQLのデメリットがあんま思いつかないんですけど本当ですよね
21:08
そうもうなんかやればいいやんじゃあみたいなねそれでいいじゃんなんか実装も楽そうだしねなんか簡単になりそう本当にねトラフィックもなんか無駄ないしねパフォーマンス出そうだしねないんじゃないですかね多分ないやんってしかもこれはグラフQL採用は今すぐやった方がいいやんっていう世の中に一瞬になりましたそうなんだこれはもうレストフルAPI終わったやろっていうもう終焉迎えたなって終焉迎えたわっていうのが2019とか18ですねうん
21:37
出て割とちょっとでそんな注目されたんだそうですそうですデメリットを言いましょうじゃあここ僕は非常に面白かった読んでてデメリットないやん今のところ思いつかない全くないんですけどこの手があったかと思いました何個言おうかな4つですただクリティカルなのは
22:05
まあでもそんなないですただ1個はあるかもしれないですね1つ目まあそりゃそうだろうんですけど発展途上ですとなので技術の実装方針とかまだ定まってないですなるほどねなのでメジャーなライブラリとかも急にこういう形式の実装をサポートしなくなったりする可能性があるあーそっか確かに
22:29
なのでちょっとそこはやや考慮に入れながら息の長いサービスはちょっとあまり使わない方がいいかもしれないねぐらいなるほどね2つ目技術者が少ないですこれは何が大変になるかというと開発ちょっと勉強しなきゃいけませんレストフィルで多分時間がかかります保守やったことないですなんか
22:54
知らん問題が起きたとき困っちゃいます採用がきつくなるってことか採用がきつくなるし引き継ぎ受けた人も困っちゃいます確かにっていう意味でインターネット上にドキュメントも少ないですなるほどねでもなんかこれ今のところグラフQL自体の問題点というよりも新しく出てきたサービスの問題点って感じですよねその通りここまではね最初はそんなもんですけど別にね
23:25
チャレンジしたい気持ちを持ってる人たちなんで僕らは多分うんうんうんなんかやってみてもいいかなって気持ちですよねそうだからまあねやっぱグラフキュエル資格ないんじゃないですか資格ない感じですよねはいちなみに言うとそんなに資格ないんですけどないんかい3つ目はいこれあのなるほどなと思ったんですが
23:40
キャッシュの設計が大変ですあー確かに確かになんですがどういうことかというとはいベストフルAPIの場合ってユーザーズ1ってやったらユーザーズ1の情報丸って書いてくるじゃないですかはいでもグラフQLの場合ユーザーズ1のネームを呼び出す人とユーザーズ1のエイジを呼び出す人がいるわけですよはいそうすると
24:02
リクエストとレスポンスって全く違うものになるじゃないですか要するにリクエストとレスポンスのバリエーションがめっちゃ増えるんですよでもRESTful APIだとキャッシュっていって間のキャッシュサーバーみたいなリクエストとレスポンスを取っておくやつがいるんですけどいる場合があるんですけどパフォーマンス出したい時にAPIのレスポンスってリクエストとレスポンスのパターンがある程度決まってるのでそこで覚えておけばAPIサーバー叩かずともレスポンス返せるんですよね
24:31
真ん中で取っておいてそうなんですパフォーマンス出したい時にはそういうこと結構やるんですけどグラフQLって呼び出し方も無限大だし呼び出され方も無限大みたいなもんなんでキャッシュ返しづらいんですよねただこれをキャッシュを返しやすいようにサービス作ればいいんですがそれを考える労力が発生しますなるほど
24:57
なのでコンテンツデリバリーネットワークをフル活用するならRESTの方が嬉しいことがありますよっていうのが一つですね確かになキャッシュは無理かも諦めました僕は今やらなくてもいいかなとも思いますっていうのが3つ目のデメリットですねそいつができれば早くなるっていう話ですよねそこまでしなくても
25:22
スピード出さずとも別にめちゃめちゃユーザー数がいるんだったらキャッシュは必須必須だと思うめっちゃユーザー数がいるんだよねそう考えるとFacebookがそこの壁乗り越えてる乗り越えてるというかお金の力でどうにかしてる可能性ありますけどねGoogleとかもそうですよね結局サーバーがいっぱいあれば問題ないんで4つ目
25:47
セキュリティ関連のちょっと気にしなきゃいけないことがありますどういうことって思うじゃないですか皆さん思い出してくださいクエリって何でも書けるんですよ何でも書けるとどういうことが起きるか
26:00
ユーザー1から100を呼び出してユーザー1から100を呼び出した後に再起的にその下にユーザー1から100の情報を入れてもらってその下にユーザー1から100の情報を入れてもらってっていうのを入れ子構造的に呼び出すクエリを自由に組めちゃうのでとんでもなく複雑でとんでもない量になるクエリを呼び出すことができるんですよ一撃でドス攻撃みたいなことができるってことですか一撃ドス攻撃でできるんですよへー
26:26
なのでそれはグラフQLの弱いところの分かりやすい部分なんでそこはちゃんと深さの制限とか呼び出す幅キー数っていうんですかねの制限をサーバー側で設定してあげればそこは防げるんですがそっちはちょっと思っても見ないグラフQLならではの攻撃みたいなものが今後出てくるかもしれないんでなるほどねそういったところでまだまだ弱さがある
26:55
っていうのがグラフQLのデメリット4つ目なるほど新しい技術ゆえっていうところは多くはあるんですけどねそうですね本質的にグラフQLの問題なのは3番のキャッシュ戦略のところが一番ありそうですねっていうのがグラフQLのデメリットでただあの
27:19
掃除で聞くとなんか良さそうやんって思うので素敵やんまだ正直周りでこれを使っているプロジェクトに僕は遭遇したことがないんですけどちょっとこれはぜひ使ってみたいなというか使ってみたいなと思いました有名どころはグラフQL API結構公開してますよねGitHubとかGitHub一番有名かも使えるんだよなこっちでブラウザで
27:49
触って遊べるグラフQLグラフQLって叩いてみるとこういう感じかって分かると思うのでURL貼っておこうかなこの本でも何個かそれが紹介されてて自由に叩けるグラフQLAPIその中でもGitHub紹介されてたんですけど他にもデモで作ってるAPIもいっぱいあるので適当にURL貼っておこうかなと思います飛ぶとグラフQL叩けるんでおー
28:16
飛んだらクエリってクエリ中カッコなんか閉じってやったらそれが返ってくるんでやってみよう再起的にやってみようエラー返ってきますちゃんとちゃんと対策されてるとっていうのがね以上グラフ給料を使ってみようというところでクライアント側の話とあとは設計とかなんとなく作り心地みたいな話をして最後デメリットについてお話してみました
28:42
なので最初にお便りであったRESTと違って何が美味しいのかっていうと通信が最小限になってパフォーマンス出ますっていうのがざっくりとしたところかなどんな時に使うといいのかこれはユーザー数がめっちゃ多くてパフォーマンス出したい時が一つとサブスクリプションの機能を使いたい時なんじゃないかなと思いました僕はリソースの常時監視をしたい時確かになあれは独自っぽいよねなんか
29:13
ただそのぐらいかなという印象ですねでもあとなんか開発工数とかも規模でかくなるにつれてグラフQLの方が向いてそうな気がするなあとはそうですそこを忘れてましたDBのテーブルがめっちゃ多いとか機能数めっちゃ多い場合にはグラフQLの方が楽そうですねそうだよねうーん
29:31
っていうのがこの3パターンぐらいですかねとにかくだからユーザー数多いか機能数めっちゃ多いかサブスクリプション使いたい時かの3つかなという風に思いましたなるほど習得大変化についてなんですが
29:45
大変っていうのは非常に曖昧な尺度であるんですけど個人的にはそんなにハードル高くないのかなと思いました聞いた感じ文法をちょっと覚えるぐらいだから新しい言語を習得するより楽そうじゃないかと思ったもともとバックエンドAPIを作っている経験があったりだとか
30:04
そういうノウハウがあるんだったらそんなに大変じゃないんじゃないかなとは思いますただ実際にサービスで運用した時にぶつかる壁はちょっと果てしないなとは思ってます思ってないことってやっぱ起きるんでこういうのってその辺はあんまりねライブラリもどんぐらいちゃんとしたライブラリなのかもよく分かってないのでライブラリの
30:25
特有のなんじゃこれエラーが出てGitHubのイシュー見ても誰も解決しとらんやみたいなのは全然遭遇する可能性ありますね有名どころのライブラリとかあったりするんですかありますが少々お待ちください有名なライブラリですけどむずいですけど本読んでて出てきてたのはGraphQL JSApollo Server
30:55
これはどっちもJavaScriptのGraphQLのライブラリなんですけどこの辺が出てきてたApolloサーバーは聞いたことありますねちょっと待ってくださいだよな待ってこれはそういうことかJavaScriptが出してるそういうGraphQLのJavaScriptのプロジェクトで使えるライブラリってことじゃんNPMとかでインストールするっていうイメージですねNPMえーとね
31:29
ノンパッションミッションノードパッケージマネージャーかなパッケージ管理ツールちなみになんですがPHPとかだとAPIプラットフォームとかあるんだグラフィキュエルグラフィキュエルPHP違った
31:50
グラフQLPHPって言うんだな多分とか含めめちゃくちゃあります戦国時代的な感じですか戦国時代ですね多分グラフQLのグラフQL.orgスラコードっていうページにグラフQLを使うために利用できるツールとかがまとまってるページがあるんですけどざっと数百個あるなめちゃめちゃあるねじゃあ今どの会社も派遣を取りに
32:19
行こうとしてるわけだそうだよねだってそこのグローバルスタンダードになったらもう利益でかすぎるもんでかいですね相当強いんでちょっとねだからねプライベートで開発するときとか使ってみたいなグラフィックウェブっていう気持ちです責任のないようなソフトウェアとか作るときに使ってみたいうんうんうん
32:42
っていうのが以上グラフキュールの話でしたはい曲がりやすいとても良かったですなんとなく分かりましたよねどういうことが便利で使い心地もどうだとか作る時もどっから考えようみたいなのもDBベースで良さそうだというところで学びたいなと思ったら初めてのこのグラフキュールって本非常に取っ付きやすくて正直5時間ぐらいで
33:10
8割を読めたのでじゃあ6時間あればいけると思いますうん?そう分からんけどおすすめの本でめっちゃ良かったですいいですねちょっと正直実装したことがないので非常に表面的なお話になってしまいましたがバックエンドの開発をしているエンジニアがグラフィックエールの本を読んでこんなもんかって理解したぐらいの知識
33:35
お話しさせていただきましたなるほどこれいざ実際使おうって判断するってなるとすごいハードルは高そうではある勇気出ないよね
33:45
なかなか勇気が出ない新しいものってね触りたくはなるけどじゃあいざ本番でこれ動かせるのかっていう葛藤があるんだよねそれでいうとこの本に書いてたのがグラフQLを導入するステップみたいなものが書いてあって最初からズガーンって全部グラフQLするんじゃなくて新しく開発する機能だけグラフQLで足してみるみたいな
34:09
そっか元々のRESTの部分は残しておいてここからちょっとGraphQL入れてこうぜみたいなことができるのかそうそうそうというやり方が一つとあとは既存のRESTfulAPIの手前にGraphQL置いてみるとか試験用のGraphQLがあってそこがさらにRESTAPIを叩きに行くってこと?そうですそうですそんなことできるの?できるですらしいです実装上はそうやって多分2つ用意しておくのかなリソースというか呼び出すパスを
34:38
でフロントエンドがグラフQLで対応して問題なさそうだったら入れ替えるみたいなそういうことかAPIから取ってきた情報を結局データベースから取ってきたかのように扱えば別にいいわけかそうですそうですみたいな形で徐々にグラフQLに置き換えていくのがよくあるパターンっていう風に書いてましたねすごいそれめちゃめちゃ有用な情報じゃないですかはいらしいですはい
35:06
新規サービスでやりたくなっちゃいますけどねあわかるしがらみめんどくさいからっていう感じでクラフトQLの話終わりますこれでちょっとバズワード1個抑えれたかなというところで前もなんかちょろっと喋ったけど余計よくわかりましたイメージつきましたじゃあ1年後テストあるんでクラフトQL検定あるんではい
35:39
流行の用語はちゃんと押さえておきましょうというところで今日も一つ賢くなれてよかったねバイバイ無理無理無理終わらせたのそれではまた次回

0:00 36:17