00:07
はい、みなさんこんにちは。keethこと桑原です。 本日もやっていきましょう、keethのエンジニア雑談チャンネルです。
この番組ではウェブ業界に関することやエンジニアリング、いろんな技術についての雑談などの情報を発信していきたいと思います。
で、今日はタイトーにありますJavaScriptのFetchっていうAPIがあるんですけど、それとFetcherですね、Fetchをするライブラリについてちょっと気になることがあったので聞いてみたっていうところですね。
私が、門川情報工科学院っていうところでJavaScriptの講義を今1個持たせていただいていて、
今リアクトのショーまで入って、簡単なですね課題をやらせています。この冬休み中にやってくださいっていうので、ソースコードとかも特に提供なくですね、簡単に手ほどきだけして環境構築だけ作って、
どんなものを作るのかみたいなのを、資料があったのでそれを見せて、これを冬休み中にチャレンジしてねっていうのをやらせています。
で、その課題やるときに必ずFetchをしなきゃいけないと。APIをコールしてデータを取得をして、
グラフでもいいし何でもいいんですけどライブラリを使って描画をするっていうのは本当に簡単なことですね。
僕らフロントエンドエンジニアとしたら当たり前にやってることですけど、やったことがない学生さんからすると初めての経験なので、
かつてリアクトを使ってやるというので、いろいろそういうエコシステムとかサードパーティーのライブラリを使い倒すみたいなところですね、経験してもらいたかったのでその課題を出したんですね。
実際でも出すのはいいけど自分でもやっぱりやってみたくて、まだ僕自身が解いてないので僕もやるんですけど、
昨日ちょっとちょこちょこコード書いてて、いざFetchするとき何を使おうかなっていうのをちょっと悩んでたんですけど、
リアクトにはですね、リアクト専用のFetcherのライブラリがいくつかあって、今は大体3大挙と勝手に思ってますけどSWRとまだまだ有名なAxiosと、
あとは最近はTurnstack Query使うことが多分多いんじゃないかなと思います。
もともとリアクトクエリもあった気がしますけど、それをリアクトじゃなくて効果的にいろんなライブラリでも使えるようにTurnstack Queryというライブラリに紹介をしたという感じですね。
この辺を使うことが多分多いんじゃないかなと。
使わないんだったらJavaScript標準のFetch APIを使うことが多いでしょうというところですね。
で、そもそもFetchの歴史ですね。
この楽器ちょっと気になったので、そういえば昔僕らってXHR、XML HTTPリクエストの略です。
XHRっていうのをガリガリ書いてインスタンスを作って、そこからコールをして取ってきたものを非同期処理をしてみたいなことをやってたんですね。
なかなか大変だったんですけど、まあ仕組みがわかりやすかったっていうのはありますね。
それをやっとおかげで他のライブラリが中で何やってるのかなっていうのはイメージしながら使えるっていうのはやっぱ大きかったと思っております。
これがですね、2000年代初頭にXHRっていうのが作られて導入されてたと。
03:01
その後はW3Cによって標準化もされてたらしいですね。
2000年代だったっていうところで、もう20年以上前にFetchの話が標準化をしたと。
そこからFetch APIの提案っていうのが、これは多分W3CじゃなくてTC39ですよ。
議論してると思うんですけど、その辺で話が始まったのかな。
XML HTTPリクエストだと協力ではあるんですけど、使用の複雑さっていうのが結構大きくて、かつ機能の不足っていうのも結構あったと。
単純にコールしてデータ取得するだけであればいいですけど、実際の現場ではそうではないよね。
これも欲しいし、あれも考慮したいしっていうのがあるので、標準の機能だけだとちょっと不足をしているっていうので、
それを解決するために新しくFetch APIっていうものが提案をされましたと。
よりモダンなアプローチをとって、PromiseベースのAPIっていうのが提供されるので、より読みやすく使いやすいインターフェースを持っていたというところですね。
ちょっと余談ですけど、Promiseを作った方が、これはJavaScriptの最大のミスだったと発言をしてましたね。
JavaScriptというかNode.jsかなって言ってたと思います。
Promiseがこんだけ世界中で主流になってしまうとか、ほぼほぼ非同期処理のデファクトまでなるっていうのは想定外だったらしくて、
Promiseは開発者の人がやり直したいみたいな発言を見ててちょっと面白かったなと思います。
このPromiseが出たおかげで、非同期処理っていうのか、一連の流れっていうのを統一的にかけるっていうのはそれは結構大きかったと思いますが、
JavaScriptはそもそもグローバルスコープの話とかあったり、なんやらかんやらっていうので、
いろいろ欠陥ではないですけど、癖が結果強くなってしまったっていうのはあるので、それを再設計したかったっていう話は出てくるかもしれないですけど。
さておき、Promiseが出てきたことによって、より非同期処理っていうのが、
Promiseベースで書けばいいじゃんっていうので標準化しやすくなったというので、より使いやすいインターフェースとしてフェッチAPIっていうのが提案をまずされてたと。
2015年ですね、ES2015で導入がされていったっていう話ですね。
この辺からもうXHR使ってる人って、直接使う人はほぼほぼいなくなったんじゃないかなっていう予想はしますね。
今の若い子たちにはもっともっと使わないでしょうと。
昔の想像、僕らはXHRのインスタンスを無理やり作ってガチャガチャやるか、もしくはJQueryのJQuery.AJAXっていうメソッドがあって、それを使ってコールすることもありましたね。
JQuery前世の時代はそうやったと思います。
フェッチが導入されて、ちゃんと多くのメジャーブラウザーによってもサポートされるようになってきて、市民権を得たというところで、もう開発者コミュニティでもフェッチを標準的な方法して取り入れることが増えてきたと。
実際今でもさっき言った通り、アクシオス使ったり、端スタグクエリー使ったりという、現場ではフェッチャーライブラリ使ってますけど意外とフェッチそのものを使ってるリポジトリは割とあるんですよね。
標準でも割と使いやすくなったって本当その通りなので、これでも良いんじゃないと。フェッチとAsyncアウェイトとPromiseみたいなところをうまいこと掛け合わせて使うという感じでやることもあるので、別にライブラリを入れなくても良くないって話は全然あるんですね。
06:05
実際端スタグエリーとかはちょっと重いですからね。よりライトなSWRでも十分同じような機能を全然持ってますので、それでも良くないって話もあると思うし。
リアクトじゃない方はアクシオスでも良いと思いますね。
アクシオスは本当に使いやすいし、最初のフェッチャーライブラリとしてJavascriptのフレームワークに依存するようなフェッチャーじゃないやつを使うとしたら、まずアクシオスになるんじゃないかなと個人的には思ってます。
ちょっと余談だと、JQueryJaxの対等の話ですけど、これも2000年代中盤にJQueryというのが登場しましたと。
ジョン・レイシーグだったっけ?が作ったライブですよね。
ちなみにJQueryはJQueryそのもののソースコードもかなり勉強になりますので、Javascriptの設計ってこうやってやるんだなっていうのを見ていくと面白いかもしれないですね。
そのXHRっていうのをちょっと抽象化をして使いやすくしたAJAXというメソッドが当時としては楽だったんですよ。
XHRを1から2にしてインスタンス作ってやってた我々からするとAJAXメソッドは楽だったんですよね。
すごく良かった。良かったんですけど、JQueryに依存しなきゃいけないっていうのが正直つらかったっていうのはあります。
で、いろんなJavascriptのフレームワークが生まれてきて、そこからJQueryからの脱却をするっていう流れも結構大きくて、今でもそれはもうほぼほぼ
デファクトまでいかないですけど、JQueryを使うことはそもそもあんまないよねって話は出てきてると思います。
とはいえ、古典的といったらあれですけど、歴史の長いウェブアプリケーションとかサイトではまだまだ使われていますし、
JQueryに依存したライブラリーで便利なものも言うてたくさんあるんで、完全なる脱却は難しいかもしれないですよね。
そんなものがあって、FetchっていうようなAPIっていうのが導入されたんですけど、それとちょっとですね、2014年にAxiosというライブラリーが生まれましたと。
HTTPクライアントとして、やはりこれはPromiseベースのAPIですね。
で、簡潔な構文で書けるようになったAxiosっていうのが、今でもずっと世界中で使われている有名なライブラリーの一つとなりましたと。
で、ここからReactとかVueがですね、ちゃんとメジャーバージョンとしてリリースされて、それ用のFetchライブラリーがどんどん出てきたと。
そもそもReactとかVueの中でも、Fetchとか状態管理とか、あとはライフサイクルですね。
いつデータコールするかみたいなところも考慮された機構になっていて、そこで何を使うかっていうのがいろいろ考慮されたライブラリーが生まれ始めたというのはありますが。
React QueryとSWRっていうのが、Reactの中でのその当時生まれたライブラリーですね。
これの強いのは、やっぱりAPIコールをするときに渡した引数に応じては、キャッシュをしてくれて再度コールしなくてもよくないとか、
一連のコールする流れの中、レンダリングの前にデータを取るんですけど、いろんなAPIに依存する場合はいろんなAPIを何度もコールするんですけど、
それがもし同じものがあったらキャッシュして、この一連の中では1回しかコールしませんみたいなことも勝手にやってくれたりするんですね。
それが結構大きかった。で、また取ってきた後のデータの同期をしてくれたりとか、もしくは差分があったらデータ自動の再取得みたいなことも、
09:06
こちらでコードを書いておけば勝手にやってくれるっていうのがすごく強かった。
ビュー用のライブラリーはあんま実はなかった気がしますね。なんだかんだアクセスを使ってた気がしますけど。
そこからもうちょっと話が変わって、新たなパラダイムとしてGraphQLが生まれました。
GraphQLは本当、書いたことある方はわかりますけど、そのAPIのBFF的に動いてくれるのはすごくありがたいんですよね。
全部手続き的に一個一個APIコールして内部でデータをごにょったりして、どっかでエラーが出たらロールバックしてもう1回コールしますかとか、
自動で何回コールします、その時間タイムどこまで空けますかみたいなとか、いろんな議論があったんですよね。
GraphQLを使って1本とりあえず叩けば、よしないデータを取ってきてくれるというのはものすごくありがたかった。
今でもこの便利さはあるなと思います。とはいえ、レストフルに作りたいという需要とかそういう環境はありはするので、別にレストフルが完全に終わるというのは想像ないと思いますけど。
GraphQLはすごくありがたいと思います。BFFを1から作ったことある身としてはGraphQLは感動しましたね。
これ、もうこれやん!って思いました。
そんなものも出て、今でも結局手続き的にコールをするというので、さっきのReactクエリがもう少し消化したTurnstackクエリというものですね。
これはVueでもSvelteとか他のフレームワークでも全然使えるっていうのは本当にデカい。
SWRってReact用のやつもあるし、アクシを吸ってもらったりしますし。
最後、最近はNext.jsが、というかReactがReactサーバーコンポーネンツとかを作ったりしてますし、
そもそもサーバーサイドレンダリングと静的サイトジェネレーションですね。
スタティックサイトジェネレーションのSSGとかもあったりするので、それに最適化したいようなデータフェッチングの方法とか、ライブラリもしかしたら今後生まれるかもしれないですね。
Reactサーバーコンポーネンツは単純にセキュリティとかデータの取得っていうのをより、バッタンのコンポーネントのところでやりましょうと。
上から取ってきて、グローバル管理をしてそれをバケツ例するんではなくて、必要なところで必要なコンポーネントがコールをすれば良いと。
それを制御して、親がそれを全部管理しなくても良いというような感じに今はなってきていると思うので、
それ用のデータの状態管理をアプリケーション全体としての状態管理っていうのをどうするかはまたちょっと別の議論ですけど、
でもデータフェッチするのはやっぱり必要な人がやれば良いっていうのは全然あると思いますので、
それ用に特化したものが生まれるかもしれないですし、今のライブラリたちでも十分その機能を果たしていると思うので、
それでも良いのかなと思いますね。
一応データを取得した後何をするかっていうのがアプリケーション開発者としてはメインの関心どころではあるので、
そことの親和性が高いライブラリっていうのが今後生まれるかもしれないなっていうのもあると思います。
さておき、そんなところの話を今日はチャットDVDに質問を投げながら歴史を改めて振り返ってたってところですね。
12:02
どんどんやっぱり複雑さっていうのを抽象化して便利に使いやすくするっていうのがエコシステムとかサードパーティーライブラリの期待をするところではある。
今までもそうやって開発をされてきてますし、今後もそういうふうになっていると思いますけど、
どっかの配信でも言ったんですけど、技術が進化したりライブラリとかが進化していくと、結局はコミュニティ化してインターフェース自体とかAPI自体はそんなに変わらないと思うので、
最終的にはその開発者、ニーズというか開発側の哲学ですね。どういうフィロソフィーとかで作られる、プリンシプルとかで作られてますかっていうところに共感するものを使うんじゃないかなと思ったりしてます。
とはいえ、ライブラリ自体の重さとかもありますよね。さっきも言った通り、単スタックエリって超高機能なんですけど、重いんですよ。
その代わりやっぱり機能が増えれば増えるほどコード量も多いし、ダウンロードする量も増えるので、それだったらライトでとにかくフェッチをしてその後のごにょりを手軽にしたいだけでいいですとか、
キャッシングとかはなんとか自分たちでやりますみたいな人たちであれば、アクシオスを使うとかも全然いいと思ったりするので、開発とかアプリケーションのニーズとかによるとは思いますけど、
最終的にはその思想哲学が反映されたライブラリが今後生まれていくんだろうなと。自分たちもそれを選ぶんだろうなって気はちょっとしてます。
はい、というわけで今日はそんなお話でした。参考になったら幸いですし、改めて皆さんでもフェッチAPIそもそもの歴史を調べていくと割と面白いものがいろいろ見えてきたりするので、ご興味あれば見てみてください。
はい、では今回はこんなところで終わっていきたいと思います。いつも聞いてくださり本当にありがとうございます。ではまた次回の16でお会いしましょう。バイバイ。
