クリス・コイエとポッドキャストエピソード22を壊す：サーバーレスとは​​何ですか？

今日は、サーバーレスアーキテクチャについて話します。 それはどういう意味ですか、そしてそれは私たちが現在サイトを構築する方法とどう違うのですか？ 私はクリス・コイエと話をして調べました。

メモを表示

• クリスのマイクロサイトフロントエンド開発者のためのサーバーレスの力
• Twitterのクリス
• ShopTalkShowポッドキャスト

毎週の更新

• 「実際のアプリケーションで使用するためのReduxのセットアップ」
  ジェリー・ナビ
• 「五感のためのウェブサイトをデザインできますか？」
  スザンヌ・スカッカ
• 「SapperとStrapiを使用して静的なブログを作成する」
  ダニエル・マダリツォ・フィリ
• 「Reactアプリの製品ツアーの実用ガイド」
  祝福クロフェガによって
• 「スケッチでポルシェ911を作成する方法」
  ニコラ・ラザレヴィッチ

トランスクリプト

Drew McLellan：彼は、10年以上前に立ち上げたWebサイトであるCSS-Tricksから知っているかもしれないウェブデザイナー兼開発者であり、ウェブサイトを構築するための素晴らしい学習リソースであり続けています。 彼はCodePenの共同創設者であり、ブラウザベースのコーディングプレイグラウンドであり、世界中のフロントエンダーが作成したものを共有し、フォローしている人々からインスピレーションを得るために使用するコミュニティです。 Dave Rupertと並んで、ウェブサイトの作成に関するポッドキャストであるShopTalkShowの共同ホストです。 彼はウェブ開発について多くのことを知っていますが、彼がかつて彼の魅力だけを使ってホットドッグを食べるコンテストで優勝したことを知っていましたか？ 私の壊滅的な友人、クリス・コイエを歓迎してください。 こんにちはクリス、お元気ですか？

クリス・コイエ：ねえ、私は壊している。

ドリュー：今日はCodePenについてではなく、話をしたかったのですが、CSS-Tricksについては必ずしも話したくありません。CSS-Tricksは、Googleのトップに表示されることを誰もが知っている素晴らしいリソースの1つです。 Web開発者の質問に関する回答を探すときの検索結果。 アップがあなたの顔をポップアップし、あなたまたはあなたのゲスト寄稿者の一人によって書かれた有用なブログ投稿があります。

クリス：ああ、私は実際にそれをしていました。 あった…私にはわからない、それはおそらくグーグルがその奇妙なソーシャルネットワークを持っていた時だった。 何だって？ グーグルプラス？

ドリュー：ああ、プラス、ええ。

クリス：ええ、彼らはWebサイトをPlusアカウントに関連付けるので、私のPlusアカウントにはアバターがあり、アバターは私だったので、検索結果に表示されました。 あの頃は過ぎ去ったと思います。 もしあなたが…

ドリュー：そうだと思う、ええ-

クリス：うん。

Drew：でも、もう少しあなたの副次的な関心事である何かについてお話ししたかったのですが、それがサーバーレスアーキテクチャのこの概念です。

クリス：うーん（肯定的）。

ドリュー：これはあなたが少しの間もっと学んできたことです。 そうですか？

クリス：うん、うん。 私はただのファンです。 フロントエンド開発の進化に自然に適合しているように思えます。ここで、少なくともある程度の専門知識を持っているように感じます。 私は自分自身をバックエンドよりもフロントエンドではるかに便利だと思っています。私は…最近ずっとそうしています。 私は十分長い間、小さなRubyコードを見るのを恐れないほど長くいました。それは確かです。 しかし、私はフロントエンドを好みます。 もっと勉強しました。 私はそのレベルでより多くのプロジェクトに参加しましたが、その後、「サーバーでJavaScriptスキルを使用できる」というこの小さな新しいパラダイムが登場しました。これは興味深いことです。 ほら？ そう思います。 それだけではありませんが、それが私が気にかけている理由です。フロントエンドの開発者がJavaScriptを深く掘り下げているように感じるからです。 そして今、私たちは他の場所で同じスキルセットを使用することができます。 うーん、かなりかっこいい。

Drew：まったく新しい世界が開かれたようですが、もしあなたがただのフロントエンドコーダーだったら…私は、ただのフロントエンドコーダーだと言ってはいけません。 あなたがフロントエンドのコーダーであり、同僚や友人と協力してバックエンドの実装を手伝うことに慣れている場合、突然それが開かれます。 そして、それはあなたが自分でスタック全体のより多くを管理できるものです。

クリス：うん、うん。 それでおしまい。

ドリュー：部屋の中の象の真上に向かって演説する。 サーバーレスについて話しているのですが、明らかに、名前を付けるのは難しいです。 我々はすべてそれを知っている。 サーバーレスアーキテクチャは、サーバーがないという意味ではありませんか？

クリス：これは必須だと思います。たとえば、これが最初に聞いたポッドキャストの場合、または最初に…「サーバーレス」という言葉を聞いたのは、これまでに聞いた最初の数十回だけです。内臓反応があり、「ああ、でもサーバーはまだある」というようなものがあります。 大丈夫。 それが今あなたに起こっているなら、それを知っておいてください、それはこれで必要なステップです。 それは人生の他のものと同じです。 理解する段階があります。 初めて何かを聞いたときは、それを少し拒否する必要があります。それから、十数回かそこらの後、またはそれがあなたにとって少し価値があることが証明された後、あなたはさらなる段階に入ることができますか？ここで理解の。 しかし、その言葉は勝ちました。それでも「サーバーレス」という言葉と戦っているのなら、電車が駅を出たとは言いたくありません。 その言葉はすでに成功しています。 あなたはこれに勝つつもりはありません。 だから、ごめんなさい。

クリス：でも面白いと思います…それは、実際にはサーバーが関与していないこともあるようになり始めています。 コンセプトとしてサーバーレスを固定したものの1つは、AWSLambdaだったと思います。 彼らはシーンの最初のようなものでした。 ラムダは、AWSに提供する関数のようなもので、魔法の空に配置します。URLがあり、ヒットすると、その関数が実行され、必要に応じて何かが返されます。 ほら？ それはただのHTTPか何かです。 それがどのように機能するかです…それを初めて聞いたとき、あなたは「なぜ？ 気にしない。」 しかし、それには明らかなことがいくつかあります。 他の誰もアクセスできない私のAPIキーを知ることができます。 そもそもバックエンドを実行するのは、クライアント側のJavaScriptにある必要のない秘密のものを知っているからです。 したがって、データベースと通信する必要がある場合は、それを実行できます。 他の場所でAPIキーを公開しなくても、安全にそれを行うことができます。 または、そのデータがどこにあるか、またはどのように取得するかでさえ、それは…

クリス：それはかなりクールだ。 データベースと通信し、データを取得し、それを返す関数を作成できます。 いいね。 つまり、Lambdaはそれですが、AWSは機能します。 地域を選択する必要があります。 あなたは「わかりません。 バージニア、どこにあるべきか？ オレゴン？ オーストラリアのものを選ぶべきですか？ わからない。" 彼らは20、30を持っています。私は彼らが最近いくつ持っているかさえ知りませんが、ラムダでさえ領域を持っていました。 最近はLambda @ Edgeがあります。つまり、すべての地域で、ちょっとクールです。 しかし、彼らは最初でした、そして今、誰もがラムダのようなものを持っています。 すべてのクラウドサービス。 彼らはこの世界で何らかのサービスを望んでいます。 それらの1つはCloudFlareです。 CloudFlareにはワーカーがいます。 AWSよりもはるかに多くの場所がありますが、異なる時間に実行されました…CloudFlareワーカーのように…ノードを実行できるという点でラムダに似ています。 JavaScriptを実行できます。 他の多くの言語を実行することもできますが、…私はこのことを大まかに考えています。最も興味深い言語はJavaScriptであり、その普及のためです。

クリス：それはCDNレベルで発生します。これはサーバーだと思いますが、私はCDNをサーバーとは考えない傾向があります。 明らかに他のものほどではありません。 最近、サーバーレスをさらに感じ始めています。 CDNはサーバーですか？ つまり、それはどこかのコンピューターだと思いますが、サーバーのようなものはさらに少ないように感じます。

ドリュー：そうですね、CDNはサーバーかもしれませんが、サーバーの最も最小限のバージョンです。 必要に応じて、シンサーバーのようなものです。

クリス：うん。 もちろん。

ドリュー：大丈夫です。 残念ながら、クレジットの出典を思い出せませんが、サーバーレスが「UberやLyftなどのライドシェアリングサービスを使用しているようなもの」などと説明されているのを聞いたことがあります。 あなたは車を持たず、車を所有していない可能性がありますが、それはあなたが車を決して使用しないという意味ではありません。

クリス：ええ、それは車が存在しないという意味ではありません。 うーん、いいね。

ドリュー：必要なときに召喚するだけですが、同時に、車の前払い購入費用を支払っていません。 メンテナンスや燃料を払っていない、または-

クリス：そうですね、価格も理にかなっていますよね？ それはすばらしい。 それはいい例えだと思います。 そして、それはCDNレベルでもあるため、すでに発生しているHTTPリクエストをインターセプトするだけです。つまり、リクエストしないでください。リクエストを送信せず、リクエストを送り返します。 それはリクエスト中に自然に発生しているだけなので、サーバーのように感じることも少なくなります。 わからない、おもしろい。 確かに面白いです。 ですから、それはあなたが価格設定のことを提起したことは大きな問題です。 使用した分だけ支払うこと。 これも重要です。なぜなら…たとえば、あなたはバックエンドの開発者であり、サーバーを一生スピンアップすることに慣れているからです。 そして、彼らはコストをかけます。「この種のメモリとこの種のCPU、およびこの種の仕様を備えたこの種のサーバーが必要です。 そして、これはそれがいくらかかるかです。」 サーバーレスが登場し、その価格設定から頭を切り落とします。

クリス：だから、あなたがこれをあまり好きではないバックエンドの開発者であったとしても、彼らはそれには興味がない、あなたのスキルセットは何年にもわたってそうであるように、あなたは価格を比較しますあなたは「何？ 以前に支払っていた金額の1％を支払うことができたでしょうか？」 あなたはそれを気にしないことは許されていませんよね？ あなたが彼らのサービスに彼らが支払う必要があるよりも100倍多く支払っているこのバックエンド開発者であるなら、あなたはその時あなたの仕事にちょっと悪いです。 いいにくいのですが。 これはやって来て、これは多くの点で価格設定を打ち砕きました。 あなたはそれを気にする必要があります。 そして、他の誰かがいるのはちょっとクールです…セキュリティについてまったく心配する必要がないわけではありませんが、それはあなたのサーバーではありません。 ラムダ関数やクラウド関数、ワーカーなどがありません。自分のネットワーク上の非常に機密性の高いデータのすぐ隣にあるサーバーに座っていません。 データベースのすぐ隣ではありません。

クリス：誰かがどういうわけかワーカーやラムダなどから自分自身を排出しようとするコードを書き、他のものにアクセスしようとすると、そこには何も得られません。 したがって、セキュリティも重要です。サーバー管理者としてのあなたの仕事であれば、このことのセキュリティに対処することです。 それを実行し、Lambdaで特定のものを実行すると、それから自然なセキュリティが得られます。これは素晴らしいことです。 だから、それはずっと安いです。 それははるかに安全です。 これらの小さなモジュラーアーキテクチャを奨励します。これは良い考えです。 ここでいいアイデアのドミノに次ぐドミノのようです。 それが注目に値する理由です。 ほら？

ドリュー：ええ、つまり、従来、私たちがWeb上で何十年も実行してきたサーバーベースのアーキテクチャでは、自分で実行するWebサーバーがあります。 フロントエンドコード、バックエンドコード、データベースなどすべてを保持します。 次に、それを維持し、実行し続け、請求書を支払う必要があります。使用されていない場合でも、請求書を記録します。 ユーザーはリクエストを行い、データベースからすべてのHTMLクエリを作成し、すべてをブラウザに送信します。 そのプロセスは機能します。 それは物事の負荷が構築される方法です。 それはおそらくウェブが構築される方法の大部分です。 それはWordPressのようなものがどのように機能するかです。 これは本当に私たちが解決する必要のある問題ですか？ つまり、コストについて少し話しました。 それに関する他の種類の問題は何ですか、私たちは…対処する必要があり、サーバーレスは私たちを助けるかもしれませんか？

クリス：ええ、古い学校のアプローチの問題です。 ええ、わかりません、多分何もありません。 つまり、ウェブ全体が全体を変える必要があると言っているのではありません…すべてを一夜にして。 わからない。 そうではないかもしれませんが、それは扉を開くと思います。 このように良いアイデアが浮かんだら、ウェブの動作が少しずつ変わっていくようです。 したがって、データベースが存在することを期待する何らかの方法で構築されたCMSがある場合、将来のホストがこれを興味深い方法で活用し始める可能性があることを意味します。 おそらく、それはまだ従来のサーバーであるように感じますが、ホスト自体が、サーバーレスアーキテクチャに、どのように動作するかをファームアウトしています。 したがって、それが起こっていることすら実際にはわかりませんが、サーバーレスの方法で必要なものをホストすることで、コストを削減する方法を見つけました。 たぶん、開発者として気にする必要さえないかもしれませんが、メタレベルでは、それが起こっていることです。 多分。 わからない。

クリス：それはまた…データベースがまだそこにあるという意味ではありません。 リレーショナルデータベースをアーキテクチャ上持つことが、そのデータを格納する正しい方法であることが判明した場合は、すばらしいことです。 サーバーレスのこの世界は、JAMstackと同時に成長しているので、私は言及します。 そして、JAMstackは、「静的ホストからWebサイトを提供する必要があり、それ以外は何も実行しない」というアーキテクチャです。これらは小さなCDNのようなものです。 彼らは、「私は何もできません。 私はPHPを実行していません。 私はRubyを実行していません。 私は何も実行しません。 静的ファイルのみを提供するように設計された小さなWebサーバーで実行しています。」

クリス： 「それ以上のことをする必要がある場合、リレーショナルデータベースからデータをプルする必要がある場合は、サーバー時ではなく、別の時に行ってください。 事前にビルドプロセスでそれを実行し、データベースからそれらをプルするか、静的ファイルを事前にビルドして、それらを提供するか、実行時に実行することができます。」 つまり、ドキュメントのこのシェルを取得すると、JavaScriptリクエストを作成してデータを取得し、それを事前に入力します。 したがって、事前または事後にそれを行いますが、それは「リレーショナルデータベースを使用しない」という意味ではありません。 これは、「ドキュメントの要求時にサーバーに生成させない」という意味です。これは…わかりませんが、少しパラダイムシフトです。

クリス：それはJAMstackだけではありません。 私たちはJavaScriptフレームワークの時代にも生きています。 私たちは、JavaScriptアプリケーションの起動方法が、いくつかのコンポーネントをマウントし、それらのコンポーネントがマウントされるときに、必要なデータを要求するということがもう少し期待され始めている時代に生きています。 したがって、React Webサイトのようなものが、次のようになるのは自然なことです。「まあ、サーバーレス機能を実行して、必要なデータを処理します。 それは本質的にいくつかのJSONAPIにヒットします。 必要なJSONデータを取得し、そのデータから自分自身を構築してから、ページにレンダリングします。」 さて、それがWebにとって良いか悪いかにかかわらず、「わかりません。 残念な。 船は出航しました。 それが多くの人々がサイトを構築している方法です。」 クライアントがレンダリングしたものです。 つまり、サーバーレスと最新のJavaScriptは密接に関連しています。

ドリュー：私はあなたが卸売りする必要はないと思います…あるアーキテクチャか別のアーキテクチャを見ています。 インフラストラクチャの一部がより伝統的で、一部がサーバーレスである可能性がある中央の領域があります、私は推測していますか？

クリス：うん。 まあ、とにかく彼らはあなたにそれを伝えようとしています。 アーキテクチャの一部を販売したい人は、「今すぐ購入する必要はありません。 少しだけやってください。」 もちろん、彼らはあなたに彼らが売っているものにあなたのつま先を浸して欲しいと思っています。なぜなら、あなたがつま先を浸すと、あなたがプールに飛び込む可能性がはるかに高いからです。 ですから、私は…それは嘘ではないと思います、しかし、必然的に、私は少し運が悪いと思いますが…私は自分のスタックがすべてのものの少しになることを望んでいません。 いつも飲み込みたくないテクニカルデスがあると思います。

ドリュー：うーん（肯定的）。

クリス：でも、それは可能です。 最も引用されているのは…eコマース要素を含むサイトがあるとしましょう。つまり…そして大規模なeコマース、つまり10,000の製品か何かで、このJAMstackアーキテクチャが到達していないとしましょう。それを静的に再構築するのは常に特に効率的です。 ですから、「それならしないでください」という考え方があります。 その部分を自然にハイドレイトさせましょう…サーバーレス関数をヒットし、必要なデータを取得して、それをすべて実行します。 しかし、サイトの残りの部分はそうではありません…ページもそれほど多くなく、データもそれほど多くありません。事前レンダリングなどを行うことができます。 だから両方の少し。

Drew：もちろん、多くの人がレガシーシステムを扱っています…2000年代に構築された古いデータベースのもので、ある種のJSONAPIレイヤーをその上に貼り付けることができるかもしれません…

クリス：うん。

ドリュー： …そして、より現代的で、おそらくサーバーレスの何かを構築し、それでも、奇妙な方法でそれを完全に接着することによって、それらのレガシーシステムと対話します。

クリス：うん。 でも好きですよね？ そうではありません…ほとんどのウェブサイトはすでに存在しています。 私たちの何人が完全にグリーンフィールドのウェブサイトですか？ 私たちのほとんどは、何らかの理由で将来に引きずり込まれる必要のある既存のがらくたに取り組んでいます。私にはわからないので、開発者はより速く作業したい、またはCOBOLで誰も雇うことができなくなった、などの話です。は。 ほら？

Drew：用語的には、JAMstackについて話しています。これは、CDNからコードを提供し、ブラウザーでコードを実行するこの方法論です。 したがって、サーバー上に動的なものはありません。 そして、サーバーレスについて話すときは、別の場所のサーバーで実行される機能のほんの一部について話します。 そうですか？ 私たちがこれらのクラウド機能について話していたことは、

クリス：ええ、つまり、彼らはたまたま両方の種類のホットなアイデアです。 ですから、一方について話したり、もう一方について話したりするのは簡単です。 しかし、必ずしも一緒である必要はありません。 サーバーレスとは​​何の関係もないJAMstackサイトを実行できます。 あなたはそれをしているだけで、サイトを事前に構築して実行するだけで、JAMstackを気にすることなくサーバーレスを使用できます。 実際、CodePenはJAMstackをまったく実行しません。 必ずしもCodePenについて話したいわけではありませんが、Ruby onRailsアプリです。 それを実現するために、多数のAWSEC2インスタンスと他のさまざまなアーキテクチャで実行されます。 ただし、サーバーレスのものは、安価で安全であり、作業に最適な方法であるため、できる限りサーバーレスのものを使用します。 したがって、JAMstackはまったく使用されていませんが、サーバーレスがいたるところにあります。

ドリュー：それはとても興味深い。 CodePenでサーバーレスにどのようなタスクを実行していますか？

クリス：まあ、たくさんのことがあります。 そのうちの1つは、うまくいけばかなり明白だと思います。必要なのは…CodePenのポイントは、ブラウザーで各HTML、CSS、JavaScriptを記述し、それを目の前にレンダリングすることです。 ただし、プリプロセッサ言語を選択することもできます。 あなたがSassが好きだとしましょう。 CSSでSassをオンにして、Sassを記述します。 さて、何かがSassを処理する必要があります。 最近、SassはDartか何かで書かれています。

クリス：理論的には、クライアントでそれを行うことができます。 しかし、前処理を行うこれらのライブラリはかなり大きいです。 Sassライブラリ全体をあなたに出荷したいとは思いません。ただそれを実行するためです。 私はしたくありません…それはただそうではありません、それは必ずしもこれのための正しいアーキテクチャではありません。 多分それは道のりです、つまり、オフラインのがらくた、ヤダ、ヤダ、Webワーカーについて話すことができます。 私たちにできる建築上のことは何百万もあります。 しかし、これが現在どのように機能するかです。ラムダがあります。 Sassを処理します。 それには、小さな、小さな、小さな、小さな仕事が1つあります。

クリス：あなたはそれにSassのこのブロブを送り、それはあなたにものを送り返します。それは処理されたCSSであり、おそらくサイトマップです。 それには小さな小さな仕事が1つあり、おそらく4セントか何かのようにそのラムダの代金を払っています。 ラムダは非常に安価であり、ハンマーで叩くこともできるからです。 規模を気にする必要はありません。 あなたはあなたが望むだけそのことを打つだけで、あなたの請求書は驚くほど安くなります。 サーバーレスが高すぎるという境界線を越え始める瞬間があります。 私はそれが何であるかわかりません、私はそのようなもののそのマスターではありません。 しかし、一般的に、私たちが行うサーバーレスの作業は、基本的に…すべて無料と見なされます。これは、非常に安価だからです。 しかし、Sass用のものがあります。 少ないものがあります。 バベル用のものがあります。 TypeScript用のものがあります。 1つあります…これらはすべて、実行する個々のラムダです。 ここにいくつかのコードがあります、それをラムダに渡してください、それは戻ってきます、そして私たちはそれでやろうとしていることは何でもします。 しかし、最近でも、それ以上の目的で使用しています。

クリス：これが例です。 CodePenのすべてのペンにはスクリーンショットがあります。 かっこいいですよね？ ですから、人々が何かを作ってから、PNGやJPEG、またはその何かが必要になります。そうすれば、ツイートしたときに、小さなプレビューが表示されます。 Slackで共有すると、プレビューが表示されます。 ウェブサイト自体でレンダリングに使用しています…iframeの画像がはるかに明るいため、ペンがアニメーション化されていないことを検出できた場合は、iframeの代わりに画像を使用してみませんか？ とにかくアニメーション化されていません。 そのようにパフォーマンスが向上するだけです。 したがって、これらの各スクリーンショットには、明らかにURLが含まれています。 そして、そのURLが実際にはサーバーレス関数になるように設計しました。 それは労働者です。 そのため、そのURLがヒットした場合、そのスクリーンショットをすでに撮ったかどうかをすばやく確認できます。

クリス： CloudFlareワーカーはサーバーレス機能であるだけでなく、データストアもあるため、これはCloudFlareワーカーによって実際に有効になっています。 彼らはKey-Valueストアと呼ばれるものを持っているので、そのIDをすばやく確認すると、「正誤問題、持っているかどうか」になります。 それがあれば、それはそれを提供します。 そしてそれはCloudFlare上でそれを提供します、そしてそれは最初から超高速です。 そして、あなたにもこのすべての能力を与えます。 これはイメージCDNであるため、次のように言うことができます。「まあ、最適な形式で提供してください。 これらの次元としてそれを提供してください。」 それらの寸法で画像を作成する必要はありません。 URLに寸法を入力するだけで、魔法のようにそのサイズで返されます。 とてもいいです。 それがない場合は、別のサーバーレス関数にそれを本当に速くするように要求します。 それで、それはそれを作り、それからそれをどこかのバケツに入れます…あなたは画像の起源を持たなければならないからですよね？ 通常はどこかで実際にホストする必要があります。 そのため、S3バケットにすばやく入れて、サービスを提供します。

クリス：つまり、キューイングサーバーはなく、何もありません。 これは、サーバーレス機能がこれらのイメージの作成、保存、提供を管理するようなものです。 そしてそれらの5000万または8000万か何かのようなものがあります。 たくさんあるので、それをスケールとしてかなりうまく処理します。 触らないだけです。 それはただ起こります。 それはすべて超高速で起こります。 超いいね。

Drew：そうですね…そうですね、サーバーレス関数は、物事の状態についてほとんど知識を必要としないタスクに理想的に適合します。 つまり、キーと値のペアを保存して、何かがすでにキャッシュされているかどうかを確認するCloudFlareの機能についておっしゃいました。

クリス：うん。 それは彼らがそれらで解決しようとしていることです。 それらのキーと値のペアは、それです…私は伝統的に真実だったと思います。 彼らは、あなたがそれを頼りにすることができないので、「物事の状態を避けなさい」のようなものです。 そして、CloudFlareワーカーは、「ええ、実際には、ある程度、状態に対処することができます」のようになっています。 それは…ほど派手ではありません、私にはわかりません、それは重要な値なので、それは価値の鍵です。 それは、ネストされた、リレーショナルな派手なもののようなものではありません。 したがって、おそらくそれにはいくつかの制限があります。 しかし、これはこのための赤ちゃんの日です。 ものはより強力になるように進化すると思うので、州のようなものを実行する能力があります。

ドリュー：そして時々、状態を維持するそのような制限された能力、またはあなたが持っていないという事実…あなたはまったく状態を維持したくないという事実は、あなたにこの種の…を与えるアーキテクチャにあなたを押し込みます「ゆるく結合された小片」のソフトウェア哲学について話しますね。

クリス：うーん（肯定的）。

ドリュー：それぞれの小さなコンポーネントが1つのことを行い、それをうまく行うところ。 そして、それを取り巻く生態系の残りの部分については本当に知りません。 そして、それはサーバーレス機能のこの概念に本当に当てはまるようです。 同意しますか？

クリス：うん。 それが良い考えかどうか、哲学的な議論ができると思います。 ほら？ いわばモノリスが好きな人もいると思います。 可能性があると思います…これをやり過ぎて、完全にテストするのが難しすぎる小さな部品を作りすぎる方法があります。 「ああ、Sass関数が機能しているかどうか疑問に思います。 さて、それについて少しテストを書いて、それが正しいことを確認しましょう。」 しかし、たとえば、ユーザーにとって重要なのは、そのうちの7つの文字列です。 7つすべてを一緒にテストするにはどうすればよいですか？ 話はもう少し複雑になると思います。 これらすべてに超インテリジェントに話す方法はわかりませんが、他のどのアーキテクチャよりも自動的に優れたアーキテクチャであるすべてのサーバーレス機能を使用する場合、必ずしもそうとは限りません。 それはいいですね。 それは私にはうまく推論されますが、それがすべてのアーキテクチャのすべてであるかどうかはわかりません。 ほら？

Drew：私にとって、それは非常にWebのように感じます。つまり、これはまさにHTMLの仕組みですよね。 HTMLを配信すると、ブラウザが画像を取得してJavaScriptを取得し、CSSを取得します。 それはその拡張のようです-

クリス：いいね。

ドリュー： …ある種のアイデア。 しかし、私たちがWebについて知っていることの1つは、ネットワークが壊れやすいため、回復力があるように設計されていることです。

クリス：うーん（肯定的）。

Drew：この種のサーバーレスアプローチはどれほど堅牢ですか？ 何かが…それらの小さな断片の1つがなくなったらどうなりますか？

クリス：それは非常に悪いことです。 ほら？ それは災害になるでしょう。 あなたのサイトは他のサーバーと同じようにダウンするでしょう、もしそれがダウンした場合、私は推測します。

ドリュー：それを軽減する方法はありますか、それは特に-

クリス：わかりません。

ドリュー： …あなたが出くわしたこの種のアプローチに適していますか？

クリス：たぶん。 つまり、私が言ったように、本当に非常に堅牢なものは次のようになります... CodePenにアクセスし、SassのJavaScript実装があり、かなり高速なネットワーク上にあり、アイドル状態であることに気付いたとします。たった今。 たぶん、そのJavaScriptを取得して、ServiceWorkerにスローします。 次に、ラムダが失敗したか何かが検出された場合、またはこれがすでにインストールされている場合は、ラムダではなくサービスワーカーをヒットし、サービスワーカーはオフラインで作業できます。 だから、それもいいですね。 それは面白い。 つまり、彼らは同じ言語っぽいです。 サービスワーカーはJavaScriptであり、多くのクラウド関数はJavaScriptであるため、いくつかの可能性があると思いますが、それは可能性があると思います。何千人ものユーザーに、彼らが何を持っているのか、そして彼らがどのバージョンを持っているのかを必ずしも知っているとは限りません。 ええ、でもそれは私自身の怖さです。 そのようなことで良い仕事をした人もいると思います。

クリス：私は実際には知りません。 サーバーレスの復元力に関して、私が知らないいくつかの戦略を知っているかもしれません。

ドリュー：サーバーレス関数で発生する可能性のある失敗モード、つまり失敗のスタイルがあると思います。この場合、関数を1回実行すると失敗し、その後すぐに2回実行すると、ヒットする可能性があるため成功します。完全に異なるサーバー。 または、問題が何であれ、その実行が2番目の要求に存在しない可能性があります。 ホスト全体がダウンしているという問題は1つですが、おそらく…マシンに個別の問題があります。 あなたはそのメモリが悪くなった特定のサーバーを持っていて、それはたくさんのエラーを投げています、そしてあなたが最初にそれを打ったとき、それは失敗するでしょう。 2回目は、その問題が根付いている可能性があります。

クリス：このテクノロジーを提供する傾向のある企業は、信頼する必要がありますが、たまたまそのタイプの企業でもあります…これが彼らの誇りです。 これが人々がそれらを使用する理由です。なぜならそれらは信頼できるからです。 人々は過去のAWSの停止を指摘できると思いますが、それらは少しまれで、あまり一般的ではない傾向があります。 あなたがあなた自身のがらくたをホストしていたなら、私は彼らがあなたをSLAパーセンテージの種類のレベルから打ち負かしたに違いない。 ほら？ したがって、「回復力のある方法で構築しないでください」というようなものではありませんが、一般的に、これらのものを提供するタイプの企業はかなり信頼できます。 その機能を台無しにしたためにダウンする可能性は、アーキテクチャが失敗しているためよりもはるかに高くなります。

ドリュー：つまり、APIや失敗する可能性のあるものを使用している場合と同じように、単にスローするのではなく、その失敗モードに対処し、次に何が起こるかを知るためにコードを構造化することを確認しているだけだと思いますユーザーへのエラー、または単に死にかけている、またはあなたは何を持っていますか。 それを認識し、ユーザーに再試行を求めています。 または、自分で再試行するか、何か。

クリス：ええ、私はただ「ああ、いや。 失敗。 アボート。" 「わからない、バディ、もう一度やってみませんか？」

Drew：つまり、サーバーレス機能、つまりクラウド機能のテストと開発に関して言えば、それはローカルで実行できることですか？ クラウドで行う必要がありますか？ それを管理する方法はありますか？

クリス：いくつかの方法があると思います。 ストーリーが素晴らしいかどうかはわかりません。 まだ比較的新しいコンセプトなので、どんどん良くなっていると思います。 しかし、私が知っていることから、一つには、あなたはかなり普通のノード関数を書いているのです。 これを行うためにJavaScriptを使用していると仮定すると、特にLambdaでは、JavaScriptがあらゆる種類のものをサポートしていることを私は知っています。 ちっぽけなPHPクラウド関数を書くことができます。 Rubyクラウド関数を書くことができます。 ですから、私は特にJavaScriptについて話していることを知っています。なぜなら、これらのほとんどはJavaScriptであると感じているからです。 言語が何であっても、ローカルでコマンドラインにアクセスして実行できます。 そのテストのいくつかは…他のコードと同じようにテストするだけです。 関数をローカルで呼び出して、機能するかどうかを確認するだけです。

クリス： HTTPリクエストについて話しているときは少し違う話ですが、それはあなたがテストしようとしていることです。 リクエストに適切に対応していますか？ そして、それはものを適切に返しますか？ わからない。 ネットワークがそこに関与する可能性があります。 したがって、そのレベルでテストを作成することをお勧めします。 それはいいです。 わからない。 そこの通常の話は何​​ですか？ ある種のローカルサーバーまたはそれを提供する何かを起動します。 郵便配達員を使ってください、わかりません。 しかし、そこには…フレームワークも助けようとします。 サーバーレスの「.com」はひどく混乱していることは知っていますが、文字通りサーバーレスと呼ばれる会社があり、サーバーレス関数を作成するためのフレームワークを作成して、それらのデプロイを支援しています。

クリス：つまり、サーバーレスでNPMをインストールするのが好きなら、そのフレームワークを入手できます。 そして、それは非常に役立つだけなので、非常に良いと広く見なされていますが、彼らは独自のクラウドなどを持っていません。 これらを作成すると、実際のラムダに到達するのに役立ちます。 または、複数のクラウドプロバイダーで機能する場合もあります。 最近はわかりませんが、既存の目的は展開ストーリーを簡単にすることです。 何がわかりません…AWSはそのシンプルさで有名ではありません。 ほら？ AWSの使用に役立つツールの世界はすべてあり、それらはその1つです。

クリス：彼らはある種の有料製品を持っています。 私はそれが正確に何であるかさえ知りません。 それらが行うことの1つは、…それらを使用する目的はテスト用であり、サーバーレス機能をテストするための開発環境を用意することだと思います。

ドリュー：ええ、それはワークフローのかなり大きな部分だと思いますよね？ JavaScript関数を作成し、ローカルでテストした場合は、それが機能することを知っています。 どのプロバイダーに参加するかを実際にどのように選択し、どのようにそのサービスに導入しますか？ さて、それは地雷原ですね。

クリス：うん。 I mean, if you want to use no tooling at all, I think they have a really… like AWS, specifically, has a really rudimentary GUI for the thing. You can paste the code in there and hit save and be like, “Okay, I guess it's live now.” That's not the best dev story, but I think you could do it that way. I know CloudFlare workers have this thing called Wrangler that you install locally. You spin it up and it spins up a fake browser on the top and then dev tools below. Then you can visit the URL and it somehow intercepts that and runs your local cloud function against it. Because one of the interesting things about workers is… you know how I described how it… you don't hit a URL and then it returns stuff. It just automatically runs when you… when it intercepts the URL, like CDN style.

Chris: So, one of the things it can do is manipulate the HTML on the way through. The worker, it has access to the complete HTML document. They have a jQuery-esque thing that's like, “Look for this selector. Get the content from it. Replace it with this content. And then continue the request.” So you can mess with code on the way through it. To test that locally, you're using their little Wrangler tool thing to do that. Also, I think the way we did it was… it's also a little dangerous. The second you put it live, it's affecting all your web traffic. それはちょっと大したことです。 You don't want to screw up a worker. ほら？ You can spin up a dev worker that's at a fake subdomain, and because it's CloudFlare, you can… CloudFlare can just make a subdomain anyway. わからない。 It's just kind of a nice way to do a… as you're only affecting sub-domain traffic, not your main traffic yet. But the subdomain's just a mirror of a production anyway, so that's kind of a… that's a testing story there.

Chris: It brings up an interesting thing, though, to me. It's like… imagine you have two websites. One of them is… for us it's like a Ruby on Rails app. なんでもいい。 It's a thing. But we don't have a CMS for that. That's just like… it's not a CMS, really. I think there's probably Ruby CMSs, but there's not any renowned ones. ほら？ It seems like all the good CMSs are PHP, for some reason. So, you want a quality CMS. Drew, you've lived in the CMS market for a long time -

Drew: Absolutely.

Chris: … so you know how this goes. Let's say you want to manage your sites in Perch or whatever, because it's a good CMS and that's the proper thing to use to build the kind of pages you want to build. But you don't want to run them on the same server. Unless you want to manage the pages on one site, but show them on another site. Well, I don't know, there's any number of ways to do that. But one JavaScript way could be, “Okay, load the page. There's an empty div there. Run some JavaScript. Ask the other site for the content of that page and then plunk it out on the new page.” That's fine, I guess, but now you're in a client side rendered page. It's going to be slow. It's going to have bad SEO, because… Google will see it eventually, but it takes 10 days or something. It's just a bad story for SEO. It's not very resilient, because who knows what's going to happen in the network. It's not the greatest way to do this kind of “content elsewhere, content on site B, show page of site A”, situation.

Chris: You could also do it on the server side, though. Let's say you had… Ruby is capable of granting a network request too, but that's even scarier because then if something fails on the network, the whole page could die or something. It's like a nervous thing. I don't love doing that either. But we did this just recently with a worker, in that we… because the worker's JavaScript, it can make a fetch request. So, it fetches site A, it finds this div on the page, and then it goes and asks site B for the content. Gets the content. Plugs it into that div, and serves the page before it gets anything. So it looks like a server rendered page, but it wasn't. It all happened at the… on the edge, at the worker level, at the serverless level.

Chris: So it's kind of cool. I think you can imagine a fetch request on the browser probably takes, I don't know, a second and a half or something. It probably takes a minute to do it. But because these are… site B is hosted on some nice hosting and Cloudflare has some… who knows what kind of super computers they use to do it. 彼らはそうします。 Those are just two servers talking to each other, and that fetch request happens just so super duper, duper fast. It's not limited to the internet connection speed of the user, so that little request takes like two milliseconds to get that data. So it's kind of this cool way to stitch together a site from multiple sources and have it feel like, and behave like, a server rendered page. I think there's a cool future to that.

Drew: Are there any sort of conventions that are sort of springing up around serverless stuff. I'm sort of thinking about how to architect things. Say I've got something where I want to do two sort of requests to different APIs. I want to take in a postal address and geocode it against one, and then take those coordinates and send that to a florist who's going to flower bomb my front yard or something. How would you build that? Would you do two separate things? Or would you turn that into one function and just make the request once from the browser?

Chris: Mm (affirmative). That's a fascinating question. I'd probably have an architect function or something. One function would be the one that's in charge of orchestrating the rest of them. It doesn't have to be, your website is the hub and it only communicates to this array of single sources. Serverless functions can talk to other serverless functions. So I think that's somewhat common to have kind of an orchestrator function that makes the different calls and stitches them together, and returns them as one. I think that is probably smart and faster, because you want servers talking to servers, not the client talking to a whole bunch of servers. If it can make one request and get everything that it needs, I think that's probably generally a good idea-

Drew: Yeah, that sounds smart. うん。

Chris: But I think that's the ultimate thing. You get a bunch of server nerds talking, they'll talk about the different approaches to that exact idea in 10 different ways.

ドリュー：うん。 No, that sounds pretty smart. I mean, you mentioned as well that this approach is ideal if you're using APIs where you've got secret information. You've got API keys or something that you don't want to live in the client. Because I don't know, maybe this florist API charges you $100 dollars every time flower bomb someone.

Chris: Easily.

Drew: You can basically use those functions to almost proxy the request and add in the secret information as it goes, and keep it secret. That's a viable way to work?

Chris: Yeah, yeah. そう思います。 I mean, secrets are, I don't know, they're interesting. They're a form of buy in I think to whatever provider you go with, because… I think largely because of source control. It's kind of like, you could just put your API key right in the serverless function, because it's just going to a server, right? You don't even have to abstract it, really. The client will never see that code that executes, but in order for it to get there, there's probably a source control along the way. It's probably like you commit to master, and then master… then some kind of deployment happens that makes that thing go to the serverless function. Then you can't put your API key in there, because then it's in the repo, and you don't put your API keys in repos. That's good advice. Now there's stuff. We've just done… at CodePen recently, we started using this git-crypt thing, which is an interesting way to put keys safely into your repos, because it's encrypted by the time anybody's looking at that file.

Chris: But only locally they're decrypted, so they're useful. So it's just kind of an interesting idea. I don't know if that helps in this case, but usually, cloud providers of these things have a web interface that's, “Put your API keys here, and we'll make them available at runtime of that function.” Then it kind of locks… it doesn't lock you in forever but it kind of is… it's not as easy to move, because all your keys are… you put in some input field and some admin interface somewhere.

Drew: Yeah, I think that's the way that Netlify manage it.

Chris: They all do, you know?

ドリュー：うん。 You have the secret environment variables that you can set from the web interface. That seems to work quite nicely.

Chris: Yeah, right. But then you got to leave… I don't know, it's not that big of a deal. I'm not saying they're doing anything nefarious or anything. How do you deal with those secrets? Well, it's a hard problem. So they kind of booted it to, I don't know, “Just put them in this input field and we'll take care of it for you, don't worry about it.”

Drew: Is there anything that you've seen that stands out as an obvious case for things that you can do with serverless, that you just couldn't do with a traditional kind of serverfull approach? Or is it just taking that code and sort of almost deploying it in a different way?

Chris: It's probably mostly that. I don't know that it unlocks any possibility that you just absolutely couldn't run it any other way. Yeah, I think that's a fair answer, but it does kind of commoditize it in an interesting way. Like, if somebody writes a really nice serverless function… I don't know that this exists quite yet, but there could kind of a marketplace, almost, for these functions. Like, I want a really good serverless function that can take a screenshot. That could be an open source project that lots of eyeballs around, that does a tremendously good job of doing it and solves all these weird edge cases. That's the one I want to use. I think that's kind of cool. ほら？ That you can kind of benefit from other people's experience in that way. I think that will happen more and more.

Drew: I guess it's the benefit that we talked about, right at the top, of enabling people who write JavaScript and may have written JavaScript only for the front-end, to expand and use those skills on the back-end as well.

クリス：うん、うん。 そうだと思います。それは…次のような瞬間があるからです…ウェブサイトに何が適切で何が適切でないかを知るために、非常に熟練している必要はありません。 たとえば、先週、このグリッチがこれらを使用する小さなチュートリアルを行いました。グリッチを保存すると、作成したもののナメクジが表示されます。つまり、「ウイスキー、タンゴ、フォックストロット。 1,000。」 それは賢い小さなもののようなものです。 数字などを付けていると思うので、ユニークになる可能性は非常に高いです。 しかし、彼らはこれらの楽しい小さなものになってしまいます。 彼らはそれらすべての単語を含むライブラリをオープンソース化しますが、それは数十万の単語のようなものです。 ファイルは巨大です。 ほら？ 単語の辞書だけのメガバイトの大きさです。 開発の最初の年に、「メガバイトの辞書であるJavaScriptファイルを出荷しないでください」と学ぶかもしれません。 それは出荷するのに良いことではありません。 ほら？ しかし、ノードは気にしません。 あなたはそれらの何百も出荷することができます。 サーバーの速度とは関係ありません。

ドリュー：うん。

クリス：サーバーでは関係ありません。 ですから、「うーん、それならノードでやるよ」みたいな感じになります。 「同じ単語には単語が必要です」などの文と、上部に「数字をランダム化してください」というメモがあります。 アレイから引き出して戻します。」 したがって、サーバーレス関数は、このオープンソースライブラリをプルするpackaged @JSONを含む8行のコードです。 そして、私のフロントエンドコードには、サーバーレス関数へのURLがあります。 そのURLにヒットします。 URLは、1つの単語または単語のグループなどを返します。 あなたはそれのためにあなた自身の小さなAPIを構築します。 そして今、私は本当に素晴らしい、効率的なものを持っています。 それについて良かったのは、それがとてもシンプルなことです。 私はそれの安全性について心配していません。 わかりません…分かりますか

クリス：それはただ…非常に平均的または初心者のJavaScript開発者は、それをやってのけることができると思います。これは素晴らしいことです。 それは彼らが以前に持っていなかった可能にするものです。 以前は、「2MBの単語の配列があります」と言っていました。 「ああ、それをクライアントに発送することはできません。」 「ああ、その時はシャットダウンするだけです。」 あなたはこの壁にぶつかるかもしれません。 他の誰かにそれを手伝ってもらうか、それをやらないか、もっと退屈なスラッグか何かを選ぶように頼む必要があります…」それは、あなたがそれをすることができなかったので、あなたにとって壁である他の方法に行かなければなりません。 そして今、あなたは「ああ、まあ、私はただ…」です。それをスクリプトスラッシュまたはソーススラッシュスクリプトフォルダーに入れる代わりに、関数フォルダーに入れます。

クリス：スクリプトをあるフォルダから別のフォルダに移動したようなものです。 そして、その1つは、代わりにサーバーレス関数としてデプロイされます。 それはどれくらいクールですか？ ほら？ ほぼ同じスキルセットを使用しています。 まだいくつかの荒削りな部分がありますが、かなり近いです。

ドリュー：すごいね。 あなたはこれらのアイデアについてのある種の小さなマイクロサイトをまとめましたね？

クリス：うん。 私はゲームに少し早かった。 でも、今日はただ取り組んでいました。なぜなら…プルリクエストを受け取るからです。 アイデア…まあ、それはserverless.css-tricks.comにあり、…ちなみに、CSS-Tricksにはダッシュがあります。 つまり、これはCSS-Tricksのサブドメインであり、私もサーバーレスで構築したので、これは…CSS-TricksはWordPressサイトに似ていますが、これは静的サイトジェネレーターサイトです。 そのすべてのコンテンツは、オープンソースであるGitHubリポジトリにあります。 したがって、サイトのコンテンツを変更したい場合は、投票リクエストを送信するだけで済みます。これは、時間の経過とともに100件ほどの投票があったため便利です。 しかし、私はすべてのオリジナルコンテンツを作成しました。

ドリュー：ここには非常に便利な場所がリストされています…「そうです、サーバーレス機能を使い始めたい」とお考えの場合は、試してみることができるすべてのプロバイダーがリストされています…

クリス：それだけです、ほとんど、テクノロジーのリストです。 うん。

ドリュー：それは素晴らしいことです。そうでなければ、あなたはただグーグルをしているだけで、何を見つけているのかわからないからです。 ええ、それはあなたがこれらの種類のことをするのを助けるAPIプロバイダーのリストです。

クリス：フォームはその一例です。なぜなら…選択した分…たとえば、JAMstackに行くということです。これが必ずしも重要なことではないことはわかっていますが、フォームがどのように連携しているかがわかります。 。 突然、PHPファイルなどそのフォームを処理するものがなくなりました。 JAMstackサイトでフォームをどのように作成しますか？ ええと、それをする方法はいくつもあります。 どうやら、みんなとその妹はあなたがその問題を解決するのを手伝いたいと思っています。 ですから、私がJAMstackという言葉の発明者だったとしたら、彼らは自然にあなたを助けようとしますが、あなたはそれらを使う必要はありません。

クリス：実際、私はこのサイトをまとめてとても驚いていました。 どれどれ。 6、9、12、15、18、21、22のサービスがあり、このサイトでフォームをサーバーレスで処理できるようになります。 23位になりたいのなら、大歓迎ですが、競争があります。 したがって、この背後にある考え方は、文字通りフォーム要素のように、HTMLでフォームを作成することです。 そして、フォームのaction属性は、ポイントするものがないため、内部のどこもポイントできません。 処理できないので、外部を指します。 それは彼らがあなたにそれを指し示して欲しいものは何でも指し示します。 彼らはフォームを処理し、その後、電子メール通知を送信するなど、あなたが期待することを行う傾向があります。 または、Slackのものを送信します。 または、Zapierに送信すると、Zapierは別の場所に送信します。 それらはすべてわずかに異なる機能セットと価格設定などを持っていますが、それらはすべてあなたのためにその問題を解決しようとしています。 問題ない。 処理します。」

ドリュー：ええ、それはとても便利なリソースです。 ぜひチェックしてみてください。 それはserverless.css-tricks.comです。 だから、私はサーバーレスについてすべてを学んでいます。 クリス、最近何を学んでいますか？

クリス：ええと、私はまだこの世界にいて、サーバーレスのことを学んでいます。 私は…という考えを持っていました。私は何年も前にこのオンラインロールプレイングゲームをプレイしていました。 私は最近、それがまだ生きていることを発見しました。 これは、テキストベースの中世ファンタジーのようなゲームです。 私はAOLが問題だったときにプレイしました。なぜなら、AOLは、ログオンしてプレイする必要のあるこれらのゲームをプレイしたいと思っていたからです。 、確かに、なぜ彼らはある時点でとてもうまくいったのか。

ドリュー：それで、秒単位で請求します。 うん。

クリス：うん。 だからゲームは彼らにとって大きかった。 彼らがあなたをそこにいる他の人々とゲームをするようにさせることができれば。 つまり、このゲームは…そこではデビューしませんでしたが、AOLに移行しました。これは、彼らがジューシーな取引をしたと確信しているためです。 あなたはドワーフの魔術師であり、革の鞘からルーンの杖を手に入れます。 そして、端末のようにコマンドを入力します。 その後、ゲームはあなたに応答します。 私はそのゲームを非常に長い間プレイしました。 私はそれにとても夢中になりました。 私はそれのコミュニティとその精神に入りました。 まるで…まるで一人でパソコンを見ていたかのようでしたが、それでも当時を振り返り、「人生で素晴らしい時間だった」と感じています。 私は本当に…人々とゲームとそのすべてが好きでした。 しかし、それから私は成長し、それを演奏するのをやめました。なぜなら、人生はあなたに起こるからです。

クリス：誰かがポッドキャストをやり始めたので、最近知りました…どうやって出会ったのかわかりませんが、やっただけです。 「このゲームは今日の世界で健在です、冗談ですか？ このテキストベースのもの。」 そして、私は元のキャラクターを再びアクティブにして元に戻し、それを再生することができてとても幸せでした。 しかし、このゲーム用にダウンロードしてもらうクライアントがまったく進化していないことを知るためだけに。 彼らはひどいです。 彼らはほとんどあなたがWindowsを使用していると想定しています。 これらのひどく安っぽいレンダリングが不十分なだけです…そしてそれはテキストベースです、あなたはそれが少なくとも素晴らしいタイポグラフィを持っていると思います。 いいえ、私は「私は関与することができました。 このゲームのクライアントを書くことができました。 美しいタイポグラフィを入れてください。」 ただ近代化するだけで、ゲームのプレイヤーは喜んでくれると思いますが、私には圧倒されました。 「どうすればいいですか？」 しかし、私はいくつかのオープンソースプロジェクトを見つけました。 そのうちの1つは、実際のターミナルウィンドウからゲームをプレイでき、いくつかのオープンソースライブラリを使用してターミナルウィンドウからGUIを作成するようなものです。

ドリュー：本当に？

クリス：わかりません。 かっこいいですね。 私は、「彼らがそれを書いたとしたら、ゲームに接続してすべてを実行する方法などのコードがそこにあるはずです。 だから、少なくとも私はいくつかのスターターコードを持っています。」 「Flutterか何かでやろう」とアプリに沿って進めようとしていたので、最終的な製品アプリは携帯電話で動作し、「これは本当に近代化できた」とのことでした。 しかし、それから私は圧倒されました。 「ああ、これは大きすぎる…できません。 私は忙しいんだ。" でも、同じ考えを持っている人を見つけて、ずっと進んでいたので、デザインレベルで貢献できました。 作業するのは本当に楽しかったですが、他の人の赤ちゃんであるプロジェクトに飛び込むことはめったにないので、私もたくさんのことを学びました。私は少しだけ貢献しているだけで、それはまったく異なります。私が今まで選んだよりもテクノロジーの選択。

クリス：それはElectronアプリです。 彼らはそれを選びました。それは私のWebスキルなので、これもまたクールな方法です。だから私はあまり奇妙なことを学んでおらず、クロスプラットフォームです。これは素晴らしいことです。 だから、私はエレクトロンについてたくさん学んでいます。 楽しいと思います。

ドリュー：それは魅力的です。 小さなサイドプロジェクトや私たちが楽しみのために行うことは、私たちが時々最も学ぶ場所になることは常に驚くべきことです。 そして、私たちのような日常業務にフィードバックできるスキルを学びましょう。

クリス：それが私が物事を学ぶ唯一の方法です。 私は…「彼らは…ではない」というようなものに引きずり込まれました。それはMithrilと呼ばれるJavaScriptライブラリでレンダリングされています。これは…聞いたことがあるかどうかはわかりませんが、奇妙です。 そうではありません…JSXなしでReactを書くようなものです。 「要素を作成」してこれらすべてを実行する必要があります…しかし、ベンチマークはそれよりもはるかに優れているはずです…そして、このテキストベースのゲームではテキストが飛んでいるだけなので、実際には一種の問題です。 多くのデータ操作があります。たとえば、このテキストベースのゲームはブラウザウィンドウで実行するのがとても簡単だと思うかもしれませんが、実際にはそうではありません。 非常に多くのデータ操作が行われているので、あなたは本当にそうしなければなりません…私たちはレンダリングの速度について良心的でなければなりません。 ほら？

ドリュー：それは魅力的です-

クリス：かなりかっこいい。

ドリュー：うん。 親愛なるリスナーの皆さん、クリスからもっと聞きたい場合は、ツイッターで彼を見つけることができます。彼は@chriscoyierです。 もちろん、CSS-Tricksはcss-tricks.comにあり、CodePenはcodepen.ioにあります。 しかし、何よりも、まだ購読していない場合は、shoptalkshow.comでShopTalkShowポッドキャストを購読することをお勧めします。 本日はご参加いただきありがとうございます、クリス。 別れの言葉はありますか？

クリス： Smashingpodcast.com。 それが本当のURLだといいのですが。