00:06
5月28日、土曜日ですね。
朝9時を回りました。
今日はですね、結構いい感じの天気ですね。東京は晴れております。
はい、もう起きたばっかりですね、今日。
起きたら、まさかの8時40分とかでバタバタと準備したんですけど。
はい、おはようございます。ゆめみのくわはらですけども、本日も朝活を始めていきたいと思います。
ではですね、今日はタイトルにある通りですけども、昨日で一応、
Next.jsのレイアウトRFCを一応読み切りました。
読み切りましたが、リアクトサーバーコンポーネンツのところ、セクションだけ飛ばして読んでます。
今日はそのリアクトサーバーコンポーネンツのRFCがあって、
それをまず読まないと、先ほどのNext.jsのレイアウトRFCの
リアクトサーバーコンポーネンツのセクションが読めないというか、
ちょっと理解できないという可能性が高かったので、
今日はそれを読んでいきたいかなと思います。
はい、というわけで今日は、リアクトサーバーコンポーネンツをちょっと読んでいこうかなと思いますね。
はい、じゃあスタート、入ってきますが、
このRFCのスタートデートは2020年の12月21日なので、実にもう2年前とかですね。
RFCのプレイリクエストも一応出てて、それはまだクローズされていない感じだようですね。
イシューというのもありますけども、それは置いといて。
1個だけ注意事項がありまして、
We strongly recommend watching our talk introducing server components before reading this RFCと言っていますので、
おい、まだあるじゃねえか。
このRFCを読む前に、
watching our talk introducing server componentsという記事を強くお勧めしますと。
なるほど、このRFCを読む前にそっちの記事を読めって言われたので、
早速朝霞のタイトルが狂いそうなんですけど、まあいいや。
はい、わくわくさんおはようございます。
ご参加いただきありがとうございます。
タイトルにある通り、
今日はリアクトサーバーコンポーネントのRFCを読んでいこうと思っていたんですけども、
早速読み始めたところ、
このRFCを読む前に別の記事を読めっていうことを推奨されたので、
タイトル詐欺になりそうなんですけど、
それを強く勧められたので、そっちから読もうと思います。
元気さんおはようございます。ご参加ありがとうございます。
この強く先にこっちを読むことをお勧めしますという記事を今開いてるんですけど、
記事的にはほとんどYouTube動画だけで、他説明ちょこっとあるぐらいなので、
これはどこまで、悩ましいですね。
03:02
YouTube聞くのも別にいいんですが、さすがに、
ツイッターライブの配信でうまいことやることが難しいので、
一応コメントだけガッと読んでみますね。
タイトルの記事的には、
イントロデューシングゼロバンドルサイズ、リアクトサーバーコンポーネントというのを書いてまして、
イントロデューシングがあって、それはリアクトサーバーコンポーネントの導入なんですけど、
トークとデモを用意したよと。
もし望むんだったら、
休日にやっているこの配信とかトークっていうのを見てくれと。
もしくはその後ほど出てくるピックアップの記事とかっていうのがあるので、
それも見てくれてもいいんじゃないのって言ってましたね。
動画の最後の方にあるんですけど、
リアクトサーバーコンポーネンツっていうのはまだ研究開発途中ですと。
我々は透明性の精神とリアクトコミュニティからの最初のフィードバックを得るためにこの作業を共有しています。
時間はたっぷりあるので、今すぐにキャッチアップしなければならないというわけでもないですよと。
もしチェックしたいのであれば、以下の順序でチェックすることをお勧めしますと。
一つ目はこの記事内にあるトークを見て、
リアクトサーバーコンポーネンツについて学んで、とりあえずデモを見てくださいと。
続いてデモをクローンして、自分のローカルコンピューターでリアクトサーバーコンポーネンツを使ってくださいと。
ラストにRFCですね。
最後にFAQを含むRFCっていうのを読んで、より深い技術的なブレイクダウンを行ってフィードバックをくださいと。
我々はTwitterのatReactJSファンドでのリプライで皆様からのご意見をお待ちしています。
これは年末に書かれた記事らしいですね。
というのがあるので、最初にこの動画を見ないとリアクトサーバーコンポーネンツの学習ができないみたいなことを言っているので、ちょっと悩ましいところではあるんですけど。
動画は後で見るとして、一旦今日はそのままRFCを見ていこうかなと思います。
RFCの中身、テーブルオブコンテンツがっと入っていきますけども。
最初サマリーですね。
サマリーから行くんですけど、サマリーでまた改めてさっきの動画を見ろっていうのを主張しているので。
本当に読まない。もしかしたらある意味ないとあまり理解できないのかもしれない気がしますが。
一応概要とかコンセプトだけでもキャッチアップしたいなと思うので、そのまま読んでいきたいと思います。
このRFCではリアクトの次期機能であるサーバーコンポーネンツについて説明をします。
サーバーコンポーネンツはサーバーとクライアントをまたがるアプリケーションを構築して、
クライアントサイドアプリケーションの豊かなインタラクティブ性と従来のサーバーレンダリングの改善されたパフォーマンスを組み合わせることを可能にします。
有名のような機能ですね。
サーバーコンポーネンツはサーバー上でのみ実行され、バンドルサイズに影響を与えません。
06:03
そのコードがクライアントにダウンロードされることはないため、バンドルサイズの縮小と起動時間の短縮に役立ちます。
サーバーコンポーネンツはデータベース、ファイルシステム、マイクロサービスなど、サーバー側のデータソースにアクセスもできます。
また、サーバーコンポーネンツはクライアントコンポーネント、つまり従来のサーバーコンポーネントに対応しています。
また、サーバー上のデータをロードして、それをプロプスとしてクライアントコンポーネントに渡すこともできます。
これによって、ページのインタラクティブな部分のレンダリングをクライアントが処理することができます。
サーバーコンポーネントはレンダリングするクライアントコンポーネントを動的に選択できるため、
クライアントコンポーネントをクライアントに渡すこともできます。
サーバーコンポーネントはレンダリングするクライアントコンポーネントを動的に選択できるため、
クライアントはページのレンダリングに必要な最小限のコードのみをダウンロードすることができます。
サーバーコンポーネントは、再読み込み時にクライアントの状態も保持します。
つまり、サーバーコンポーネントのツリーが再読み込みされても、
クライアントの状態、例えばフォーカスであったりとか、
および進行中のアニメーションとかが中断されたりリセットされたりすることはないということですね。
はい、素晴らしい。それは大変だと思いますけど、これをやってくれるのはかなりありがたいですね。
サーバーコンポーネントはプログレッシブにレンダリングされ、
UIのレンダリングユニットをクライアントにインクリメンタルにストリームします。
それにサスペンスと組み合わせることで、開発者は意図的なロード状態を作成して、
ページの残りの部分のロードを待つ間に重要なコンテンツを素早く表示することができます。
ユーザーをブロックしないということですね。
また、サーバーとクライアント間のコードを共有して、一つのコンポーネントを使用して、
サーバー上のあるコンテンツの静的バージョンをあるルートで、
クライアント上のそのコンテンツの編集可能バージョンを別のルートでレンダリングすることも可能です。
これはちょっと日本語が難しいな。
サーバークライアント間でコードを共有して、
一つのコンポーネントをサーバー上のあるコンテンツの静的バージョンのあるルートで、
あるルートっていうのがあれだな。
英語を読んでいきますが、
本当だ、そのまんまですね。
ワンルートっていうからあるルートなんだ。
何かのルートでクライアント上のコンテンツの編集可能バージョンを
別の方のルートでレンダリングすることもできます。
なるほどね。
ベーシック・エグザンプルが続くんですけど、
いきなりソースコードなので、
コードでどこまで伝わるかわからないですけど、
読んでいきますか。
ベーシック・エグザンプル。
この例ではタイトルと本文を持つ単純なノートをレンダリングします。
09:04
これのnode.server.jsっていうファイルですね。
オプションでクライアントコンポーネント、
従来のリアクトコンポーネントを利用して、
ノートのエディターをレンダリングします。
まずサーバー上でノートをレンダリングします。
ノートっていう関数がありますね。
ソースコードをざくっと見ると、
最初にインポートでdb.serverっていうのをインポートしてます。
もう一個インポートでノートエディターっていうのをインポートしますね。
これがそのノートエディター.クライアントっていうやつで、
これはノートエディター.クライアント.jsっていうファイルを作ります。
これはクライアントのコンポーネントらしいですね。
さっきのdb.serverっていうのはサーバーコンポーネントですね。
それをインポートして、関数コンポーネントを定義してますね。
ファンクション、ノートっていう名前の関数コンポーネントで
引き続きプロプスを受け取ってます。
プロプスからコンストでIDとIsEditingっていうフラグを受け取ってますね。
あれか、普通にアクセスするのか。
db.post.getでそのIDをキーにして、
ポスト、ノートを取得しているというところですね。
小文字のノートっていうコンストで受け取って、
それをリターンの中でJSXでレンダリングしてるっていうところですね。
特定のノートIDの記事を取ってきて、
それをレンダリングするっていうような実装になってます。
コメントに戻りますけども、
まずサーバー上でノートをレンダリングして、
サーバーコンポーネントの名前はset.jiga.server.js、
もしくはJSX、TSXなどっていうところであるから、
っていうことがリアクトチームの作業上の習慣となってるらしいですね。
なのでみんなそういうふうに作ってるらしいですね。
サーバーコンポーネントはserver.jsで、
クライアントのほうはclient.jsでコンポーネントを作ってるらしいですね。
またちょっとコメントがありますね。
この例にはいくつかのキーポイントがあると。
それを説明しますけども、
これは単なるリアクトのコンポーネントですと。
プロップスを受け取ってビューをレンダリングします。
そうですね、コード的には本当普通のリアクトのコンポーネントでしたね。
サーバーコンポーネントにはステータイエフェクトなどを使用できない、
などいくつか制約がありますけども、
全体としては期待通りに動作しますと。
それはまだ実装中だからかな。わかんないけど。
詳細はサーバーコンポーネントと
クライアントコンポーネントの機能と制約というページがあるので、
12:00
そこを参照してください。
それは今日は割愛します。
ついでにサーバーコンポーネントでは、
ソースコードがあるんですけど、そこに示すように、
データベースのサーバーのデータソースに直接アクセスすることができます。
さっきのプロップスで受け取ったんですけど、
このプロップスの中にサーバーコンポーネントのデータソースがあって、
それをそのまま受け取れますし、使えますよと言ってます。
要はプロップスを介してアクセスできますよと言ってますね。
これは汎用的なメカニズムで実装されていて、
コミュニティでは様々なデータソースと連携する互換性のあるAPIを作成することができます。
はい、なるほどね。
結局そんな感じで簡単に、本当ですね。
クライアントとサーバー側で簡単にアクセスできるというのはそのままだと思いましたね。
なるほどね。
はい、では続いて、
えー、どこにあるんだ?
続いてですね、サーバーコンポーネントっていうのは、
ソースコードの中で示しているんですけど、
クライアントコンポーネントをインポートしてレンダリングすることによって、
レンダリングをクライアントに引き渡せますと。
クライアントコンポーネントはセットオフィスとしてクライアントJS、
またJSX、もしくはTSXなどが使えますと。
バンドラーはこれらのインポートを他のダイナミックインポートと同様に扱って、
さまざまなヒューリスティックに従って、
別のバンドレイで分割する可能性があります。
この例では、ノートエディター.クライアントJSというのは、
Props.isEditingというフラグがトゥルーのときだけクライアントにロードしますと。
はい、というふうなコントローラブルに扱うことができますよと言ってますね。
でも、そのisEditingっていう変数の値っていうのは基本的にプロプスで当たってくるので、
サーバーコンポーネントの方からの値ですね。
サーバーコンポーネントの状態に合わせてクライアントをレンダリングするしないっていうのが、
クライアント側でも制御できるようになるという例でした。
これめちゃめちゃシンプルですね。
なるほど。
サーバーコンポーネント、こんなちょっと未来性があるな。
すごいですね。
では続いて、またまた読んでいきますが。
はい、続いてこれに対してクライアントコンポーネントっていうのは、
あなたがすでに慣らしんでいる典型的なコンポーネントです。
ステート、エフェクト、もしくはドムへのアクセスなど、
リアクトの全機能にアクセスすることもできます。
うん、そんな感じですね。
ソースコードみたいな感じ、ほんと単なるリアクトコンポーネントなので、
サーバーのコンポーネントをインポートした後は普通にリアクトのフックスも使えそうですし、
従来通りの使い方にさらにサーバーコンポーネントも一緒に使えるみたいな、
乗っかった感じがしますね。
クライアントコンポーネントっていう名前には新しい意味は別になくて、
これらのコンポーネントをサーバーコンポーネントと区別するためだけのもので、
名刺的に分けるためだけで従来通りですよって言ってますね。
この例の続きとして、ノートエディターを実装する方法をそのまま説明しますというところで、
15:03
ソースコードがバーっと来てます。
ソースコード的には、
note-editor.client.jsっていう先ほどのクライアントコンポーネントのファイルですね。
ざっくり見てますけど、
これもクライアントコンポーネントだけでリアクトの単なるコンポーネントですね。
export-defaultで関数コンポーネントを作っていますね。
定義としてnote-editorっていう名前の関数を定義します。
引き続きプロプスを受け取って、
props.noteでノートのデータソースにアクセスできています。
その後にuseStateを2つ定義しておいて、
タイトルとボディっていうのを初期値に与えれます。
戻れちゃうタイトルとセットタイトル。
もう1個はボディとセットボディっていうやつですね。
セッターと変数とっていうのを受け取ってます。
アップデートタイトルっていうメソッドと
アップデートボディっていうメソッドの関数が定義しておいて、
それを最後にreturn.jsxの中で
インプットのところが変更されたらタイトルとか変更して、
テキストエリアのところが変更されたらオンチェンジですね。
変更されたらアップデートボディとかメソッドを発火させると。
本当にどシンプルな感じですね。
ただクライアントコンポーネントの方の中身は
サーバーコンポーネント、こっちはサーバーコンポーネントと何も影響しないので
まんまリアクトコンポーネントなので何も新しいことなかったですね。
コメントにも同じことが書いてます。
これは普通のリアクトコンポーネントのように見えますが、それはそうだからです。
クライアントコンポーネントは通常のコンポーネントです。
重要な点はリアクトがサーバーコンポーネントの結果をクライアントにレンダリングするとき、
それ以前にレンダリングされた可能性のあるクライアントコンポーネント状態を維持することです。
具体的にはリアクトはサーバーから渡された新しいプロプスを
既存のクライアントコンポーネントにマージをして、
これらのコンポーネントの状態、もしくはDOMを維持して
フォーカス状態及び進行中のアニメーションを保持します。
ここがありがたいですね。
クライアントとサーバー側でプロプスをマージして
そこをヨシナミがやってくれるというのがありがたいです。
続いてモチベーションの話に移ってくるそうですね。
モチベーションです。
サーバーコンポーネンツというのはさまざまなアプリケーションで見られる
リアクトの多くの課題に対応しています。
当初はよりシンプルなソリューションにつながることが多いため
これらの問題に対するターゲットソリューションを探していました。
しかし我々はそのアプローチに満足できませんでした。
根本的な課題はリアクトアプリがクライアント中心で
サーバーを十分に活用できていないということでした。
18:00
もし開発者が簡単にサーバーをもっと活用できるようになれば
これらの課題をすべて解決して規模の大小にかかわらず
アプリを構築するためのより強力なアプローチを提供できるはずです。
それは本当そうだと思います。
ただリアクトって本来UIを担当するライブラリだと思うので
それはサーバーの機能がないのは当然であって
だから我々はNext.jsを望んだというのが正直だった気もしますけど
そこにリアクトサーバーコンポーネンツという機能が入ってくるので
リアクト自体がサーバー側と処理を入ってくるので
Next.jsをどうやってサポートするのか気になってきますね。
これらの課題は主に2つのバケットに分類されます。
まず開発者が成功の落とし穴に落ち入りやすく
デフォルトで良好なパフォーマンスを達成できるようにしたいと考えました。
成功の落とし穴がどういうことを意味しているのか
僕は分からなかったです。
特に説明もない。ピットオブサクセスって書いてますね。
ピットオブサクセス。後でググります。
2つ目はリアクトアプリでのデータ取得をより簡単にすることです。
リアクトを使ったことがある人なら次のような機能の
少なくともいつかを選んだ後、望んだことがあるのではないでしょうか。
というのが次からちょっとずつ名前が出てきますけど
概要だけ言うと、ゼロバンドルサイズコンポーネンツと
フルアクセストゥーザバックエンドと
オートマティックコードスプリッティングと
ノークライアントサーバーウォーターフォールズと
いっぱい出てくるな。いっぱい出てきますね。
なんかわちゃわちゃ出てくるんで
それを一個一個今度説明していこうかなと思ってますね。
では一つ、ゼロバンドルサイズコンポーネンツというところからですね。
先に言うと思いっきりこれ今日中に終わる気がしないので
明日も同じようにこれの続きを読んでいくことになるなと思います。
では行きます。ゼロバンドルサイズコンポーネンツですね。
開発者っていうのはサードパーティーのパッケージの
仕様について常に選択を迫られています。
マークダウンをレンダリングしたりとか
日付をフォーマットするためのパッケージを使うことは
開発者として便利ではありますけども
ユーザーにとってはコードサイズが大きくなって
パフォーマンスを抵抗させます。
一方これらの機能を自分たちで書き換えるのは
時間がかかりましてエラーが起こりやすいと。
ツリーシェイクのような高度な機能を使えば
多少は楽になりますけどそれでも結局は
ユーザーに余分なコードを提供しなければならないのです。
そうなのよね。
ただ自分たちでゼロベースで作るかってすごく大変ですし
やっぱりサードパーティーとかエコシステムを使いますよね。
例えば今日ですね。
マークダウンで私たちのノートの例をレンダリングするためには
240キロバイト以上のJSが必要かもしれません。
個別にGZIPで圧縮しても74キロバイトいっちゃうよね。
21:06
これはあなたが使用する可能性のあるライブラリの
ワンセットに過ぎず、より小さいまたはより大きい
代替ライブラリがあるかもしれないことに注意してください。
例えばXバイトしかない代替ライブラリを好むとしても
ユーザーはそのXバイトをダウンロードしなければなりません。
この例のポイントっていうのは
特定のライブラリを選ぶことではなく
ライブラリの使用は開発者としては便利ですが
バンドルサイズが大きくなり
アプリケーションのパフォーマンスを低下させる
可能性があるということです。
一応ソースコードの例があってですね。
見てみると
note-with-markdown.jsっていうファイルですね。
そういうコンポーネンツか。
これはサーバーコンポーネンツの以前のものだという風に
明示してますね。
例えばインポートでマークトっていう
ライブラリをインポートしていると。
これは35.9kBで
gzipで圧縮したところで11.2kB
もう一個インポートでサニタイズHTMLってやつですね。
これも必要ですよね。
サニタイズHTMLっていうライブラリを
nodemode.jsからインポートしているんですけど
これも200kBあって
gzipで圧縮して63kB
合わせて200kB
約300kBですね。
ファンクションでnote-with-markdownという関数コンポーネントを定義しておいて
プロプシにテキストを受け取って
中身の方で
先ほどのサニタイズHTMLに
テキストを渡してサニタイズしてます。
そのHTMLを使ってリターンで
ここにおよってレンダリングをするという感じのコンポーネントがあります。
ユーザーはそれをダウンロードしなきゃいけないよねって言ってますね。
それをどうするのかというと
しかしアプリケーションの多くの部分っていうのは
インタラクティブではなく
完全なデータの一貫性を別に必要とするわけではない。
例えば詳細ページっていうのは
製品、ユーザー、その他のエンティティに関する情報を
表示することが多く
ユーザーの操作に反応して更新する必要というのは
基本的にはないはずですよね。
このノートの例はまさにそれだと言ってます。
サーバーコンポーネンツを使用すると
開発者はサーバー上で静的にコンテンツをレンダリングして
リアクトのコンポーネント指向モデルは最大限に活用して
バンドルサイズに影響を与えずに
サードパーティー製パッケージを自由に使用することができるようになります。
上記の例をサーバーコンポーネンツに移行すると
この機能には全く同じコードを使用できますけど
クライアントに送信することはありませんと言ってますね。
さっきのやつはクライアントのソースコードだったんですけど
これをサーバーコンポーネンツに移行しましたと。
例としてはさっきのノードウィズマークダウンというファイルですけど
これのサーバー.jsファイルの1個別で作ってますと。
これはサーバーコンポーネンツで
同じようにマークトゥとサニタイズHTMLというのを
インポートをして
24:00
でもファンクションでノードウィズマークダウンというのを受け取ってます。
同じようなことをやりますという感じですね。
これをサーバー側にガンとそのまま持ってってしまえば
ファンクション側の方では別にということですね。
なるほどです。
これは結構便利ですね。
とはいえでも
ユーザーの方に結局
最終的にマークダウンであったりとかっていうのは提供するので
何かしら渡すことには結局なってしまうので
そんなに軽くならない
ゼロにはならないと思うんですが
UI的に結局マークダウンをユーザーが操作させたかったりするのであれば
と思いますけど
詳細記事という意味では確かに
マークダウンを渡す必要はないので
その辺をサーバー側でまるっとやって
クライアント側ではその辺の全部計算処理が終わったら
ただのHTMLを返すという意味では確かに
ゼロバンドルに確かになるのでそこは便利だと思いますし
小さくなるのですごくありがたいと思います。
要はクライアント側でマークダウンのソースコードの解析と
サニタイズまでを
今までずっとクライアント側でやったものを
全部サーバー側に押し込めるというのは確かに強いですよね。
今のが一応
ゼロバンドルサイズコンポーネントの一つの例でした。
続いてフルアクセストゥーザバックエンドですね。
フルアクセストゥーザバックエンドは
リアクトのアプリケーションを書くときに最も一般的な
ペインポイントですね。
辛いなというところのポイントの一つというのは
データにアクセスする方法
あるいはそもそもデータを保存する場所を決定することです。
うん、その通り。
リアクトでデータフェッチを行うには
多くの素晴らしいアプローチがあって
また多くの素晴らしいデータベースや
データストアを選択することができます。
しかしこれらのアプローチというのは
それぞれいくつかの課題があります。
共通のテーマは
開発者がUIを強化するために
追加のエンドポイントを公開しなければならない。
あるいは必ずしもそのUIを念頭において設計されていない
既存のエンドポイントを押しなければならないということです。
そうですね。
これがあるからAPI側の人たちと
いつもコミュニケーションを取らなきゃいけないということですね。
私たちは誰でも簡単に始められ
かつ大規模なアプリケーションの複雑さを
緩和できるようなソリューションを求めていました。
そうです。求めています。
For exampleというのがあって
ソースコードの例が出てきます。
新しいアプリもしくは最初に作るアプリケーションを作るときに
データをどこに保存したらよいか分からない場合は
ファイルシステムから始めると良いでしょう。
見てますけど
サーバーコンポーネンツのほうで
note.server.jsというファイルをまた作ります。
その中にreactfsというモジュールがあるらしいですね。
importfsをしておいて
functionでnoteというコンポーネントを作っておくと
27:03
引数にidを受け取って
中身のほうでjsonparseをして
そのファイルシステムですね
fs.readfileというよくやるやつですね
にid.jsonというファイルを受け取って
それをjsonparseにかけてnoteという変数で受け取ると
それを最後にreturnでjsxで返す
そこでnote.with.markdownで
propsでnoteという先ほどの
jsonから受け取ったデータを渡してあげる
というのが一つですねと言ってました
サーバーコンポーネントだから
サーバー側にアクセスできるので
確かにファイルシステムにもアクセスできる
ということですよね
なのでそこでもうデータを受け取ってしまう
というのは確かに一つかもしれないですね
なるほど
もしくは別のアプローチですね
別のアプローチとして
より高度なアプリケーションでは
同様にバックエンドに直接アクセスを利用して
データベース
もしくはその内部のマイクロサービスとか
その他のバックエンドののみのデータソースを
利用することもできるようになると言ってますね
ソースコード的には先ほど見た
インポートのdbですね
db.serverというのから
データベースの値をそのまま受け取って
同じように関数コンポーネントの
noteというのを定義しておいて
中身の方ですね
db.noteというのにアクセスをして
.getのIDを指定してあげれば
詳細記事とかも受け取るようになって
受け取ったnoteをまた
return.jsxの中で
コンポーネントのプロプスで
渡してあげればいいじゃない
という感じになってますね
こうやって確かにアクセスできるようにする
っていうのは大事ですけど
問題はじゃあバックエンド側に
それを提供できるような準備があるか
というのはまた一つの課題にはなると思いますね
とはいえでもこれでアクセスできるのは
確かにバックエンドのデータに
フルで万的なアクセスできるし
ざわざわAPIのエンドポイント
どうたらこうたらみたいなところまで
いかなくていいし
これはありがたいですね
なるほど
ただ一方でデータベースに近づく
ってことは
セキュリティリスクが上がる
っていう気がしていますので
そこの懸念はある気がするんで
そこどうすんだろうな
っていう気はしますが
少なくともここでアクセスできるのが
より便利になるっていうのは
確かに素晴らしい話であって
これはありがたいなと思いました
続きに読んでいきたいんですけど
気づいたら30分になってしまったので
一旦じゃあ今日の朝活は
こちらに以上にして
次回明日からですね
サーバーコンプレッサー続きで
次はオートマティックコードスプリッティングから
入っていきたいかなと思います
もうちょっとリアクトの話が続いていきますけど
これ終わったらまた違う議事
次何読もうかなって悩ましいんで
ネタあったらください
困ったらナックスとスリー読むかもしれないですね
という感じで
今日の朝活はこちらで以上にしたいと思います
土曜日なんで皆さん
ゆっくり休んでいただければなと思います
それではお疲れ様です
