JAMstackの基礎：何を、何を、どのように

私たちはウェブの限界を押し上げるのが大好きなので、何か新しいことを試すことにしました。 JAMstack（JavaScript、API、およびマークアップに基づく新しいWebスタック）について聞いたことがあるかもしれませんが、ワークフローにとってそれは何を意味し、プロジェクトでいつ意味をなすのでしょうか。

Smashing Membershipの一環として、一連のライブウェビナーであるSmashingTVを毎週開催しています。 綿毛はありません—業界で尊敬されている実務家によって運営されている、ライブQ＆Aを備えた実用的で実用的なウェビナーです。 確かに、Smashing TVのスケジュールはすでにかなり密集しているように見え、Smashingメンバーはレコーディングと一緒に無料です—明らかに。

Phil Hawksworthに、JAMStackが実際に何を意味し、いつそれが理にかなっているのか、そしてそれがツールやフロントエンドアーキテクチャにどのように影響するのかを説明するウェビナーを実行するように依頼しました。 1時間のウェビナーも利用できるようになりました。 Philが来たるSmashingConfトロント（6月25〜26日）を共同MCし、今年も7月9〜10日に共同開催するJAMStack_confLondonを運営することを歓迎します。 さあ、始めましょう！

Phil Hawksworth：すばらしい、わかりました、それでは始めましょう。 非常に簡単な挨拶として、私はすでにこんにちはと言ったことを意味します、スコットは私に素晴らしい紹介をしてくれました。 しかし、はい、私は現在Netlifyで働いており、そこで開発者エクスペリエンスチームで働いています。 質疑応答には十分な時間があればいいのですが、スコットが言ったように、そこで質問する機会がない場合、または単に質問する場合は、Twitterで直接私にpingを送信できるので、私のTwitterは私の名前はPhilHawksworthなので、いつでもJAMstackやTwitterで何か質問をすることができます。

Phil Hawksworth：でも、今日は、この引用に少し時間をさかのぼって始めたいと思います。これは、私に非常に強く共鳴します。 これは、もちろんクリエイティブ・コモンズとオープンWebに多大な貢献をした素晴らしいアーロン・シュワルツからの引用です。彼は2002年にブログにこれを書きました。彼は、次のように述べています。 AOLサーバー、Postgres、Oracleがインストールされます。」 AOLサーバー、当時はオープンソースのWebサーバーであったことを思い出すために見上げる必要がありました。

Phil Hawksworth：でも、これは本当に強くチャイムを鳴らします。 また、ブログを存続させるためのインフラストラクチャを維持したくありません。それが彼が話していたことです。 そして、それは彼自身のブログのこのブログ投稿にあり、「焼く、揚げないでください」というタイトルでした。 彼は最近CMSを構築した人が使い始めた用語を選んでいて、ベーキングについてこの用語を広めました（Bake、Do n't Fry）。 彼が話しているのは、オンデマンドでレンダリングするのではなく事前レンダリングであるため、人々が来て要求したときにオンデマンドでコンテンツを揚げるのではなく、事前にコンテンツをベイク処理します。

Phil Hawksworth：プレレンダリングとレンダリングについて話しているとき、それが意味するのは、マークアップの生成について話しているということです。 サーバーレンダリングや同形レンダリングの種類、またはこれらの種類の流行語の多くについて話すことは、少し自己意識的だと感じます。 数年前、アムステルダムで開催されたフロンティアカンファレンスで、サーバーでのレンダリングについて話していたときに、誰かが私にこう言ったのです。 HTMLを出力するだけですか？」 もちろん、それが私の言いたいことです。

Phil Hawksworth：しかし、この種のすべては、スタックを単純化するのに大いに役立ちます。 Webサイトにサービスを提供するスタックについて考えるとき。 私はすべてを単純化しようとしています。スタックを単純化しようと非常に熱心です。 そして、それが「JAMstack」と呼ばれるものの核心であり、これについて少し説明したいと思います。 JAMstackの「JAM」は、JavaScript、API、およびマークアップを表します。 しかし、それは私たちがそれが何を意味するのかを理解するのに本当に十分ではありません—それは一体何を本当に意味するのでしょうか？

Phil Hawksworth：ええと、私が次の30分かそこらでやってみたいことは、その定義を少し拡張して、JAMstackとは何かについてもっと説明したいということです。 JAMstackの影響と影響について少しお話ししたいと思います。そして、それが私たちにそれを選択する理由について何を与えることができるかについて考えてください。 その過程で、役立つツールとサービスのいくつかに言及しようと思います。うまくいけば、掘り下げたいと思うかもしれないいくつかのリソースで締めくくり、おそらくあなたを取得するためのいくつかの最初のステップに言及します。進行中です。

Phil Hawksworth：それで、それが次の30分の計画です。 しかし、私は、スタックを単純化することについてのこの概念に戻りたいと思います。なぜなら、うまくいけば、これに参加するか、後でこのビデオを見に来た人々は、JAMstackが何であるかについての概念を持っているかもしれません。多分それは完全に新しい用語であり、あなたはただ興味があります。 しかし、最終的には、すでにたくさんのスタックがあります。 あなたがウェブサイトを届けることができる多くの方法があります。 LAMPスタックであれMAMPスタックであれ、MEANスタックであれ、さまざまな種類のインフラストラクチャを非常に長い間構築してきたように感じます。 ここの画面にはたくさんの人が浮かんでいます。 それらはたくさんあります。

Phil Hawksworth：では、なぜ私たちは別のものが必要になるのでしょうか？ さて、私が述べたように、JAMstackはJavaScript / API / Markupですが、もう少し説明的にしようとすると、JAMstackは、JavaScript /を使用して高速で安全なサイトと動的アプリを作成するのに役立つ最新のアーキテクチャを目的としています。 APIと事前にレンダリングされたマークアップは、Webサーバーなしで提供されます。これが最後のポイントであり、それを際立たせ、おそらくもう少し、面白くて珍しいものにします。

Phil Hawksworth： Webサーバーなしで何かを提供するというこの概念は、魔法のように聞こえるか、ばかげているように聞こえます。うまくいけば、途中で何がわかるかを理解します。 しかし、これに光を当ててもう少し詳しく説明するために、従来のスタック、またはWeb上で物事を提供する従来の方法と考えるものと比較すると便利な場合があります。 だから、ちょっとだけそれをやってみましょう。 おそらく、従来のスタックで処理されるリクエストがどのように見えるかを見ていきましょう。

Phil Hawksworth：つまり、このシナリオでは、誰かがWebブラウザーを開いて、ページの表示を要求しました。 そして、そのリクエストはCDNにヒットする可能性がありますが、おそらく、このサイトを所有する人々として、私たちがホストしている他のインフラストラクチャにヒットする可能性があります。 たぶん、私たちは非常に人気があり成功した光景を望んでいるので、これが多くの負荷の下でスケーリングすることを確認しようとしました。 したがって、おそらく、いくつかのロジックを含むロードバランサーを入手しました。このロードバランサーは、プロビジョニング、構成、および展開した多数のWebサーバーの1つにその要求を処理します。 それらのサーバーがいくつかある可能性があります。

Phil Hawksworth：そして、これらのサーバーは、「さて、これが私たちのテンプレートです。これにいくつかのデータを入力する必要があります」と言うロジックを実行します。 データを検索するロジックを実行する多数のデータベースサーバーの1つからデータを取得し、それをWebサーバーに返し、ビューを作成して、ロードバランサーに渡す場合があります。 おそらく、途中でCDNにコールオフし、CDNにいくつかの資産を隠します。これは、CDNがコンテンツ配信ネットワークであるため、インターネット全体に分散されたマシンのネットワークであり、リクエストサービスを可能な限り近く取得しようとします。ユーザーに追加し、キャッシュなどを追加します。

Phil Hawksworth：それで、私たちはそこにいくつかの資産を隠し、最終的には、私たちが構築したサイトを体験するユーザーの目玉に、ブラウザーにビューを戻すかもしれません。 したがって、明らかに、これは、従来のスタックでリクエストを処理する方法を単純化しすぎているか、非常に一般的な見方です。 これを、わずかに異なる方法でサービスを提供しているJAMstackと比較すると、次のようになります。

Phil Hawksworth：繰り返しになりますが、同じシナリオで、Webブラウザーから始めています。 ページの表示をリクエストしていますが、そのページはすでにCDNに含まれています。 そこから静的に機能するため、ユーザー、ブラウザーに返され、完了です。 したがって、明らかに、非常に単純化されたビューですが、すぐに、複雑さの点でここで違いを確認し始めることができます。 コードを管理する必要がある場所に関しては、深くコード化して、それらすべてのさまざまなものを管理します。 したがって、私にとって、JAMstackのコア属性の1つは、CDNから直接、または静的ファイルサーバーからでもサービスを提供できるサイトを構築していることを意味します。 CDNは、負荷を処理するために配置したいものですが、最終的には、あらゆる種類の静的ファイルサーバー、一種の静的ホスティングインフラストラクチャから直接提供できます。

Phil Hawksworth： JAMstackは、一種の、複雑さを軽減する機会を提供します。 数回戻ってくる図の2つの部分を比較するだけで、次の30分間で、複雑さを軽減し、リスクを軽減する機会であることがわかります。 つまり、静的アセットを提供することのメリットのいくつかを享受できるようになるということです。後で、それらが何であるかについて説明します。 しかし、あなたはこれを見て、「まあ、素晴らしいですが、これは静的なWebサイトの新しい名前ではありませんか？」と考えているかもしれません。 「私たちは物事を静的に提供するつもりです」と言っているとき、それは私に平準化するのに合理的なことです。

Phil Hawksworth：でも、私はそれに戻りたいと思います。 それについてもう少し話したいのですが、まず、このスタックの概念と、とにかくスタックとは一体何なのかについて話したいと思います。 そして、スタックは、Webサイトまたはアプリケーションを提供するテクノロジーのレイヤーと考えています。 また、ビルドパイプラインや開発プロセスについては話していませんが、サイトにサービスを提供する方法は、開発方法や展開方法などに大きな影響を与える可能性があります。

Phil Hawksworth：しかし、ここでは、実際にWebサイトとアプリケーションをユーザーに提供するテクノロジースタック、つまりテクノロジーのレイヤーについて話します。 それでは、もう少し比較してみましょう。 LAMPスタックについて少し話しましょう。

Phil Hawksworth：覚えているかもしれませんが、LAMPスタックは、HCPルーティングや静的アセットの提供などを行うためのApacheWebサーバーで構成されています。 PHP、一部の前処理用なので、かなりハイパーテキスト処理。 ロジックを適用し、テンプレートのビューとあなたが持っているものを構築するかもしれません。 そして、私のNISQLによって、データにある程度アクセスできます。そして、LINUXは、そのすべての下にあるオペレーティングシステムであり、すべての呼吸を維持します。 これを、このWebサーバーとして概念的にまとめることができます。 そして、これらのサーバーの多くが、ある種、一緒に座ってWebサイトにサービスを提供している可能性があります。

Phil Hawksworth：これはLAMPスタックの一種の伝統的な見方であり、それをJAMstackと比較すると、ここで重大な変化があります。 ここでは、オペレーティングシステムについて考えたり、Webサイトを配信するためのロジックを実行する方法について考えたりするのではなく、実際にレベルを上げています。 ここでは、これらのものを静的に提供することを前提としています。 そのため、ACPルーティングと、静的サーバーからのアセットの提供を行っています。 それは合理的に行うことができます。 何年にもわたって、静的なWebサイトまたは静的なアセットを配信する方法を構築することで、これは非常にうまくいきました。

Phil Hawksworth：これはCDNかもしれませんが、これについては後で説明します。 しかし、私たちが関心を持っている分野は、ブラウザーでより多く発生しています。 したがって、ここで、マークアップが配信され、解析されます。 これはJavaScriptを実行できる場所であり、これはブラウザーで発生しています。 多くの点で、ブラウザは最新のWebのランタイムになっています。 サーバーインフラストラクチャ自体にランタイムを設定するのではなく、ランタイムをレベルを上げて、ユーザーに近づけ、ブラウザーに移動しました。

Phil Hawksworth：データへのアクセスに関しては、おそらく外部APIを介して行われ、JavaScriptを介してこれらの外部APIを呼び出してサーバーにアクセスするか、APIをブラウザーAPIと見なして、JavaScriptと対話できるようにすることができます。ブラウザに機能があります。

Phil Hawksworth：いずれにせよ、ここでJAMstackについて重要なのは、事前にレンダリングされたものについて話しているということです。静的に提供され、ブラウザーでプログレッシブエンハンスされてブラウザーAPIやJavaScriptを利用できるようになる可能性があります。 、そしてあなたは何を持っていますか。

Phil Hawksworth：では、ここでこの小さな比較を行ってみましょう。 繰り返しになりますが、JAMstackがブラウザのレベルを上げたことを繰り返します。 そして、この図の2つの側面を見ると、左側にLAMPスタックがあり、右側にJAMスタックがあるので、LAMPスタックを使用して物を構築しているときでも、まだマークアップを出力します。 まだJavaScriptを出力しています。 まだAPIにアクセスしている可能性があります。 したがって、多くの点で、JAMstackは以前に構築していたもののサブセットのようなものです。

Phil Hawksworth： JAMstackは、サイトを提供するために必要な一連のツールとテクノロジーを保証するものであるため、保証されたスタックとして時々話していました。 ただし、いずれにせよ、これはサイトを配信するための非常に単純化された方法であり、要求時にサーバーでロジックを実行および実行する必要がなくなります。

Phil Hawksworth：それで、これは多くのことをすることができます。 これにより、展開が簡単になります。繰り返しになりますが、この図に時々コールバックします。 コードとサイトをどのようにデプロイするかを考えると、最初のデプロイから、開発ライフサイクル全体、Webサイトの存続期間全体にわたって、すべてのデプロイについて考えます。 従来のスタックでは、その図のすべてのボックスのロジックとコンテンツを変更する必要がある場合があります。

Phil Hawksworth：一方、JAMstackでは、デプロイについて話しているときは、CDNに物を届け、静的サーバーに物を届けることを話しているのですが、それがデプロイに伴うものです。 ビルド、ビルドを実行する種類のロジック—どこでも実行できます。 これは、Webサーバーをホストしているのと同じ環境で実行する必要はありません。 実際、そうではありません！ JAMstackへのキーを開始します。 これらの静的アセットを提供するリクエスト時に発生するものと、ビルド時に実行するロジックであるビルド時に発生するものを分離します。

Phil Hawksworth：それで、この種のデカップリングは重要なことです、そして私は後でそれに戻るつもりです。 私たちは静的ファイルを提供するのが非常に得意であり、CDNに物を届けたり、ファイルシステム（ファイルサーバー）に物を運んだりすることは、過去数年間で大きな進歩を見てきました。 現在、これを非常にうまく行うのに役立つツールやプロセスがたくさんあります。 静的アセットを適切に提供し、ビルドをその環境に組み込むためのワークフローを提供できるいくつかのサービスを呼び出すだけで、Azure、AWS、GoogleCloudなどの大規模なクラウドインフラストラクチャプロバイダーを想像する可能性があります。

Phil Hawksworth：しかし、他にもあります。 ですから、右上のサービスはサージと呼ばれるサービスで、数年前から存在しています。 これにより、ビルド環境でコマンドを実行し、アセットをホスティング環境にデプロイできます。 次のNetlifyは私が働いている場所であり、私たちはほとんど同じことをしますが、自動化も異なります。 私は別の時にそれに入ることができました。 そして一番下にあるのは、Nowと呼ばれるもう1つの静的ホスティング環境サイトです。

Phil Hawksworth：つまり、これを行うにはさまざまなオプションがあり、これらのスペースはすべて、CDNにできるだけ早く到達するためのさまざまなツールを提供します。 可能な限りシームレスな方法でサイトを展開します。 そして、それらはすべて、ローカルで何かを実行するという原則に基づいて構築されているという共通点があります。 静的サイトジェネレーターは、ビルドで実行する可能性のあるものと考えることがよくあります。このジェネレーターを実行すると、コンテンツやテンプレート、場合によってはさまざまなサービスからのデータが取得され、静的に提供できるものが出力されます。

Phil Hawksworth：静的サーバーでローカルにプレビューできます。 ローカル開発環境で行うのは簡単なことです。それをデプロイするプロセスは、それをホスティング環境に、理想的にはCDNに送信して、拡張を実現します。 ですから、そのような基盤が整ったので、JAMstackサイトに関してよくある誤解に対処したいと思います。 そして、これをJAMstackサイトをJavaScript、API、およびMarkupとして説明するものとして公開することで、私は何の恩恵も受けませんでした。 よくある誤解は、すべてのJAMstackサイトはJavaScriptとAPI、およびマークアップでなければならないというものですが、私たちが見落としていたこの種のことは、3つすべてを使用する必要がないということです。 、オプション。 これらは好きなだけ使用できます。 LAMPスタックサイトが必ずしもデータベースにアクセスしている必要がないのと同じように。 今、私は過去にLinuxマシン上でApacheサーバーによって提供されるものを構築し、PHPを使用していましたが、データベースにアクセスしておらず、スタックの名前を変更し始めませんでした必然的にそのために。

Phil Hawksworth：つまり、JAMstackサイトとは何かを考えると、さまざまなものになる可能性があります。 これは、Jekyllなどの静的サイトジェネレーターを使用して構築され、YAMLファイルからコンテンツをプルしてJavaScriptを持たず、APIにまったくヒットしないサイトを構築するものである可能性があり、GitHubPagesなどで提供されます。 または、それはJAMstackサイトになります。 あるいは、Gatsbyのような静的サイトジェネレーターを使用しているかもしれません。これは、JekyllのRuby環境ではなく、Reactエコシステムに組み込まれたJavaScript静的サイトジェネレーターです。

Phil Hawksworth：それはコンテンツを再び引っ張っている可能性があり、Markdownファイルを整理しています。 API、GraphQLのAPIへの呼び出しでそれを豊かにするかもしれません。 ブラウザーでテンプレートを作成するJavaScriptのハイドレーションを実行するなど、ブラウザーで実行している可能性があります。 そしてそれはAmazonS3で提供されるかもしれません。 それはJAMStackサイトですか？ ええ、絶対に！

Phil Hawksworth： Go！で構築された別の静的サイトジェネレーターHugoに移ります。 繰り返しになりますが、JavaScriptを使用してブラウザーでインタラクションを追加し、Markdownファイルでコンテンツを整理している可能性があります。 外部APIを呼び出さず、GoogleCloudでホストしている可能性があります。 JAMstackですか？ 絶対！ ほら、私はここでテーマを構築しています。 現在Viewエコシステムに組み込まれている別の静的サイトジェネレーターであるNuxtのようなものを使用します。 多分それは異なる隣接ファイルからコンテンツを引っ張っていますか？ 繰り返しになりますが、ブラウザでJavaScriptインタラクションを使用している可能性があります。おそらく、APIを呼び出して、eコマースなどを実行し、別の静的サイトにサービスを提供します。 Netlifyのような別のホスティングインフラストラクチャ、それはJAMstackですか？ はい、そうです！

Phil Hawksworth：しかし、私たちも、スケールのこちら側の端に行くかもしれません。 そして、私たちが自分たちで作成した、職人による手巻きのJavaScriptを作成した、手作りのプログレッシブWebアプリについて考えてみてください。 webpackでパッケージ化しています。 JavaScript Webトークンを使用し、APIを呼び出して認証を行い、さまざまなブラウザーAPIと対話し、Azureでホストしている可能性があります。 はい、それもJAMstackです！

Phil Hawksworth：そして、ご存知のとおり、これらすべて、およびその他多くのものは、JAMstackと見なすことができます。これらはすべて、共通の1つの属性を共有し、オリジンサーバーでは提供されないためです。 それらのいずれも、要求時にロジックを実行するサーバーにヒットする必要はありません。 これらは静的アセットとして提供され、その後JavaScriptとAPIの呼び出しで強化されています。

Phil Hawksworth：繰り返しになりますが、JAMstackは、CDNから直接提供できることを意味します。 それで、私はこれの影響と影響のいくつかを単に呼びたいと思います、なぜならなぜ私たちはこれをしたいのですか？ さて、最初の概念はセキュリティに関するものであり、ここでは攻撃の表面積が大幅に減少しています。 攻撃に対処しなければならない可能性のある場所について考えると（この古い図に戻ると）、ロードバランサー、Webサーバー、データベースサーバーなどを保護する必要があります。 これらすべてのことから、いかなる種類の攻撃、そして実際にはCDNが侵入されないようにする必要があります。

Phil Hawksworth：このパズルからより多くのピースを取り出すことができれば、攻撃される可能性のある場所が少なくなり、確保する必要のある場所が少なくなります。 攻撃する可動部品が少ないことは非常に価値があります。 Netlifyでは、独自のCDNを運用しているため、CDNを通過するトラフィックを監視できるという贅沢を得ることができます。また、Netlifyでホストされているすべてのサイト、想像できるすべてのJAMstackサイト、それらのいずれも監視できません。完全に分離されているため、WordPress管理ページがあります。 WordPress管理者はいませんが、大量のトラフィックがあり、WP管理者などを調査し、侵入方法を探し、攻撃ベクトルを探しています。

Phil Hawksworth： Kent C.Doddsがやったことのいくつかが本当に好きです。 あなたがReactコミュニティに精通しているかどうかはわかりませんが、おそらく過去にKent C.Doddsに出会ったことがあります。 彼はWordPressを使用していませんが、それでもこのURLであるWPAdminをルーティングしています。 彼はそれをYouTubeのリックロールのビデオにルーティングしていたと思います。 彼は確かにそれを調査しに行った人々を荒らしている。 しかし、要点は、そのように物事を切り離し、ある種、起こることを動かし、要求時間に起こることから時間を構築することによって、露出を大幅に減らすことができるということです。 リクエスト時に可動部品はありません。 可動部品はすべて、ビルド時に完全に切り離されています。 潜在的に、完全に、まあ、必然的に完全に異なるインフラストラクチャ上で。

Phil Hawksworth：もちろん、これはパフォーマンスにも影響を与えます。 ここで昔の友人に話を戻します。これらのさまざまな場所で実行する必要のあるロジックがある場合、ここでスタック全体のパフォーマンスを向上させたいと思うかもしれません。 これが従来のスタックで頻繁に発生する方法は、パフォーマンスを向上させるために、レイヤーの追加、静的レイヤーの追加を開始することです。 つまり、静的であるかのように動作し始める方法を見つけてください。 処理を高速化するために、スタックの各レベルでそのロジックを実行する必要はありません。 そのため、インフラストラクチャ全体にキャッシュするなどの導入を開始し、そのロジックを実行するのではなく、Webサーバー内にあることがわかる可能性のある明らかな場所を紹介します。そのロジックを実行せずに、すぐに何かを提供したいと考えています。

Phil Hawksworth：つまり、それは疑似静的であることに向けた一歩のようなものです。 同様に、データベースサーバーでは、cache-comクエリにキャッシュレイヤーを追加します。 CDN全体のバランスが悪い場合でも、キャッシュと考えることができます。 ただし、従来のスタックでは、すべてがキャッシュされるわけではないため、そのキャッシュを管理する方法を理解する必要があります。 だから、いくつかの論理があります。 動的に入力する必要があるものとキャッシュできるもの。 そして、JAMstackモデルでは、すべてがキャッシュされます。 デプロイが完了した時点からすべてがキャッシュされるため、まったく異なる考え方をすることができます。

Phil Hawksworth：それで、これは、スケーリングにもヒントを与え始めます。 そして、規模によって、私が話しているのは、大量のトラフィックをどのように処理するのでしょうか。 従来のスタックは、拡張するためにインフラストラクチャを追加し始めます。 だから、はい、キャッシングに。 従来のスタックに配置し始めています。 それはある程度役立ちます—ある程度。 通常発生するのは、大量のトラフィックを処理するために、インフラストラクチャの拡張を開始し、サーバーの追加、これらの要求を処理するためのピースの追加、これらのコストの削減、および負荷の見積もりは大きなオーバーヘッドであり、技術的なアーキテクチャを行う人にとっては頭痛の種になります。 それは確かに私にとってのことでした。そのため、すべてがデフォルトでスケールを処理し、ゲートからすぐにパフォーマンスを処理するように設計されているCDNから提供されることを知っているJAMstackアプローチを実行することにもっと傾倒し始めました。 。

Phil Hawksworth：それで、私は開発者の経験にも賛成したいと思います。そして、これがそこに与える影響もあります。 さて、開発者エクスペリエンスはユーザーエクスペリエンスに勝るものと見なされるべきではありませんが、優れた開発者エクスペリエンスは摩擦を減らし、開発者が優れたユーザーエクスペリエンスを構築するためのはるかに優れた仕事をすることを可能にすると信じています！

Phil Hawksworth：ですから、開発者の経験がどこにあるのか、そして開発者にとって関心のある分野がここにあるのかを考えるとき、従来のスタックでは、これらすべての異なるコードをどのように取得するかを考える必要があるかもしれません。インフラストラクチャの一部、およびそれらすべてがどのように連携するか。 JAMstackの世界では、実際、私たちが話しているのは、ここの下部にあるこのボックスです。 ビルドとそれらをどのように実行したか、最初に何かを提供するためにデプロイメントを自動化する方法を知っていますか？ そして素晴らしいことは、JAMstackモデルでは、そのビルドで何をするかは完全にあなた次第だということです。

Phil Hawksworth：これは、非常に明確に定義された問題空間です。最終的には、CDNから直接提供できるものを構築しようとしているからです。 Ruby、Python、JavaScript、Go、PHPで構築された静的サイトジェネレーターであるかどうかにかかわらず、好きなツールを使用して何かを事前にレンダリングしたい場合は、その選択を自由に行うことができます。 そのため、作業に適した環境を作成できます。また、JAMstackサイトの本当の属性は、不変でアトミックなデプロイメントとしてはるかに簡単に機能できることであるため、開発者に本当の自信を持たせる機会が生まれます。

Phil Hawksworth：そして、スライドから少し離れて、それが何を意味するのかを説明したいと思います。不変の展開とアトミック展開は…（マーケティングの話のように聞こえるかもしれませんが）。私がやろうとしていることは、ブラウザに飛び込むことです。 さて…実は、ちょっと戻ってみます。 私に…これをしてください。

Phil Hawksworth：こちらです。 これは簡単になります。 ページに直接ジャンプします。 さて、スコット、あなたは私に言うでしょう、スコット、あなたが私のブラウザを見ることができないなら、私は望んでいます。 さて、誰もが私のブラウザを見ることができると仮定します。

スコット：すべてがよさそうだ。

Phil Hawksworth：すばらしい！ どうもありがとうございました！

Phil Hawksworth：つまり、ここで行っているのは、サービスの例として、例としてNetlifyを使用しているということです。 ただし、これは静的にホストできるサイトに共通の属性です。 つまり、不変のデプロイメントについて話すとき、つまり、コードの各デプロイメントはインフラストラクチャのさまざまな部分に触れ、多くのことを変更する必要があります。ここでは、サイトの状態を変更していません。サーバー。 発生したすべての展開に対して、サイトのまったく新しいインスタンスを作成しています。 サイトは静的アセットのコレクションであるため、これを行うことができます。

Phil Hawksworth：ここでは、自分のWebサイトから行われた展開を調べています。 御馳走を差し上げます。 そこにいる、それはそれがどのように見えるかです。 それは単なるブログであり、特に注目に値するものや刺激的なもののようには見えません。 これは静的に生成されたブログですが、CDNから提供される静的アセットのコレクションであるため、これまでに発生したすべての展開が永続的に存続します。 今、私は私の歴史が私を運ぶことができる限り戻って、それが戻ったので、その場所を見に行くことができました…これはいつでしたか？ これは2016年8月でした。静的アセットのセットであるため、永続的に存続する独自のURLでこれをホストできます。必要に応じて、アクセスして公開することもできます。展開。

Phil Hawksworth：それで、今、私のWebサイトを見ている人は誰でも、ここで私のWebサイトに戻ると、そのページを更新すると、以前にあったアセットを使用してCDNから直接提供されます。 今、私は再びナビゲートすることができます。 ここで、あなたは見ることができます。 ほら、私はこれについて強打していました。私は同形レンダリングのようなこれらのひどい用語を使用し、2016年にJAMstackについて話していました。それで、これは現在私のサイトでライブで提供されているものです。 繰り返しになりますが、永遠に生き続ける相互展開があるからです。 私は自分自身の、一種の、安心を置くつもりです、私はそうするつもりです—これは最初のページですか？ うん。 最新の展開に戻ります。 もう一度閉じて、現実の世界に戻らなければなりません。 これで問題ないことを確認しましょう。

Phil Hawksworth：わかりました！ すごい！ それで、今、これは私の前のバージョン、または私の最新バージョンのサイトの提供に戻っています。 基調講演に戻ります。 したがって、これは、物事が不変でアトミックであるために可能です。 そのアトミックな部分は、デプロイメントが完全に含まれていることを意味します。 そのため、一部のアセットがWebサーバーで利用できるようになることはありませんが、一部のアセットは利用できません。 すべてがコンテキスト内にあり、すべてが完全に存在する場合にのみ、サイトの提供を新しいバージョンに切り替えます。 繰り返しになりますが、これは、CDNから直接アセットの束として機能するJAMstackサイトとして構築する場合に、はるかに簡単に実行できる種類のことです。

Phil Hawksworth：基調講演から前後に戻った後、タイマーがリセットされたことに気づいたので、残り約6〜7分だと思います。 教えてください、スコット、もし-

スコット：それで、ええ、私たちはまだ約10分間は元気です。

フィルホークスワース： 10分？ さて、素晴らしい！

スコット：急ぐ必要はありません。

Phil Hawksworth：ありがとう、それは良いことです！

Phil Hawksworth：つまり、ギアを少し切り替えてAPIとサービスについて話すだけです（APIはJAMstackの一部であるため）。その後、使用できる可能性のあるサービスの種類は、ほとんどがJAMstackです。 ご存知のとおり、社内で構築したサービスを使用している場合もあれば、購入したサービスを使用している場合もあります。 私たちのために何かをすることができるさまざまなプロバイダーがたくさんあります、そしてそれは彼らの専門知識だからです。 APIを介して、コンテンツ管理システムからコンテンツをサービスとして取り込む可能性があります。このためのさまざまなプロバイダーがあり、優れたコンテンツ管理エクスペリエンスを提供し、APIを介してコンテンツを公開することを専門としています。それらを引き込むことができます。

Phil Hawksworth：同様に、資産を提供する方法はいくつかあります。 Cloudaryのような人々は、画像の最適化を行い、APIを介してアセットをサイトに直接提供するのに優れています。 またはeコマースはどうですか？ StripeやSnipcartのようにAPIを提供できる場所があるので、これらのサービスを自分で構築したり、eコマースエンジンの構築に伴う非常に複雑な問題に直面したりする必要はありません。 同様に、Oauthを使用しているAuth0のような人々からのアイデンティティ。 利用できるサービスはたくさんあり、ブラウザまたはビルド時、あるいは両方の組み合わせで、APIを介してこれらを利用できます。

Phil Hawksworth: Now, some people might think, “Well, that's fine, but I don't want to give the keys to the kingdom away. I don't want to risk giving these services over to external providers,” and to that, I say, well, you know, vendors who provide a single service really depend on its success. If there's a company that's core business, or entire business, is in building-out an e-Commerce engine, an e-Commerce service for you, they're doing that for all of their clients, all of their customers, so they really depend on its success and they have the specialist skills to do that.

Phil Hawksworth: So, that kind of de-risks it from you a great deal. Especially when you start to factor in the fact that you can have your technical and service-level contracts to give you that extra security. But it's not all about bought services, it's also about services you can build yourselves. Now, there's a number of ways that this can happen, but sometimes, you absolutely need a little bit of logic on the server. And so far, I've just been talking about taking the server out of the equation. では、どうすればよいのでしょうか。

Phil Hawksworth: Well, this is where serverless can really come to the rescue. Serverless and JAMstack, they just fit together really beautifully. And when I'm talking about serverless, I'm talking about no functions as a service. I know that serverless can be a bit of a loaded term, but here, I'm talking about functions as a service. Because functions as a service can start to enable a real micro-services architecture. Using things like AWS Lambda or Google Cloud functions or similar functions as a service, can allow you to build out server infrastructure without a server. Now, you can start deploying JavaScript logic to something that just runs on demand.

Phil Hawksworth: And that means, you can start supplementing some of these other services with, maybe, very targeted small services you build yourselves that can run the serverless functions. These kind of smaller services are easier to reason about, understand, build out and they create much greater agility. I want to just mention a few examples and results from JAMstack sites. I'm not going to go down the server list avenue too much, right now. We can, maybe, come back to that in the questions. I really just kind of want to switch gear and, thinking about time a little bit, talk about some examples and results.

Phil Hawksworth: Because there are some types of sites that lend themselves in a very obvious way to a JAMstack site. Things like the documentation for React, or Vuejs, those [inaudible 00:32:40], pre-rendered JAMstacks sites. As do sites for large companies, such as Citrix, this is a great example of Citrix multi-language documentation. You can actually view the video from the JAMstack conference that happened in New York, where Beth Pollock had worked on this project, talked about the change that went on in that project. From building on traditional, non-enterprised infrastructure to a JAMstack approach and building with Jekyll, which is not necessarily the fastest generating static site generator, but still, they saw a huge improvement.

Phil Hawksworth: Beth talked about the turnaround time for updates went from weeks to minutes. Maybe people are kind of frowning at the idea of weeks for updates to sites, but sometimes in big complex infrastructure, with lots of stakeholders and lots of moving parts, this really is the situation we're often finding ourselves in. Beth also talked about estimating the annual cost savings for this move to a JAMstack site. To get the site running properly, estimated their savings of around 65%. That's huge kind of savings. Changing gear to a slightly different type of site, something a little closer to home, Smashing Magazine itself is a JAMstack site, which might be a little bit surprising, because on one hand, yes, there's lots of articles and it's also content, which is published regularly, but not every minute of the day, for sure.

Phil Hawksworth: So, that might lend itself, perhaps, for something that's pre-generated, but of course, there's also a membership area and an event section, and a job board, and e-Commerce, and all of these things. This is all possible on the JAMstack because not only are we pre-rendering, but we're also enriching things with JavaScript and the front end to call out to APIs, which let some of these things happen. The project that I think I saw Vitaly arrive in the call, so that's going to be good, we might be able to come back to this in a few minutes.

Phil Hawksworth: But the project that migrated, Smashing Magazine onto a JAMstack approach, I believe, simplified the number of platforms from five, effectively down to one. And I'm using Vitaly's words directly here: Vitaly talked about having some caching issues, trying to make the site go quickly, using probably every single WordPress caching plug-in out there, and goodness knows, there are a few of them! So, Smashing Magazine saw an improvement in performance, time to first load went from 800 milliseconds to 80 milliseconds. Again, I'm simplifying the infrastructure that served the site up in the first place. So, it's kind of interesting to see the performance gains that can happen there.

Phil Hawksworth: Another totally different type of site. This is from the Google Chrome team, who built this out to demonstrate at Google I/O this year. This very much feels like an application. This is Minesweeper in a browser. I apologize if you're watching me play this. I'm not playing it while talking to you; I recorded this sometime ago and it's agony to see how terrible I seem to be at Minesweeper while trying to record. That's not a mine, that can't be!

Phil Hawksworth: Anyway, we'll move on.

Phil Hawksworth: The point of that is, this is something that feels very much more like an app, and it was built in a way to be very responsible about the way it used JavaScript. The payload to interactive was 25KB. This progressively would download and use other resources along the way, but it meant that the time to interact was under five seconds on a very slow 3G network. So, you can be very responsible with the way you use JavaScript and still package up JavaScript, as part of the experience for a JAMstack site.

Phil Hawksworth: So, I'm kind of mindful of time. We're almost out of time, so what is the JAMstack? Well, it's kind of where we started from. JAMstack sites are rendered in advance: they're not dependent on an origin server (that's kind of key), and they may be progressively enhanced in the browser with JavaScript. But as we've shown, you don't have to use JavaScript at all. You might just be serving that statically, ready to go, without that. It's an option available to you.

Phil Hawksworth: This key tenant, I think of, JAMstack sites is they're served without web service. They're pre-rendered and done in advance.

Phil Hawksworth: If you're interested in more, it's already been mentioned a little bit, there is a conference in London in July — July 9th and 10th. The speakers are going to be talking about all kinds of things to do with performance in the browser, things that you can do in the browser, results of building on the JAMstack and things to do with serverless.

Phil Hawksworth: There's also a bunch of links in this deck that I will share, after this presentation, including various bits and pieces to do with static site generation, things like headless CMS, the jamstack.org site itself, and a great set of resources on a website called “The New Dynamic” which is just always full of latest information on JAMstack. We're out of time, so I'll wrap it up there, and then head back across to questions. So, thanks very much for joining and I'd love to take questions.

Scott: Thanks, Phil. That was amazing, thank you. You made me feel quite old when you pulled up the Minesweeper reference, so—

Phil Hawksworth: (laughs) Yeah, I can't take any credit for that, but it's kind of fascinating to see that as well.

Scott: So, I do think Vitaly is here.

Vitaly: Yes, always in the back.

Phil Hawksworth: I see Vitaly's smiling face.

Vitaly: Hello everyone!

Phil Hawksworth: So, I'm going to hand it over to Vitaly for the Q&A, because I seem to have a bit of a lag on my end, so I don't want to hold you guys up. Vitaly, I'll hand it over to you.

Scott: Okay. ありがとう、スコット。

Vitaly: Thanks, Scott.

Vitaly: Hello—

Vitaly: Oh, no, I'm back. こんにちは、みんな。 Now Scott is back but Phil is gone.

Scott: I'm still here! Still waiting for everything.

Vitaly: Phil is talking. Aw, Phil, I've been missing you! I haven't seen you, for what, for days, now? It's like, “How unbelievable!” Phil, I have questions!

Vitaly: So, yeah. It's been interesting for us, actually, to move from WordPress to JAMstack — it was quite a journey. It was quite a project, and the remaining moving parts and all. So, it was actually quite an undertaking. So, I'm wondering, though, what would you say, like if we look at the state of things and if we look in the complexes, itself, that applications have. Especially if you might deal with a lot of legacy, imagine you have to deal with five platforms, maybe seven platforms here, and different things. Maybe, you have an old legacy project in Ruby, you have something lying on PHP, and it's all kind of connected, but in a hacky way. 右？ It might seem like an incredible effort to move to JAMstack. So, what would be the first step?

Scott: So … I mean, I think you're absolutely right, first of all. Re-platforming any site is a big effort, for sure. Particularly if there's lots of legacy. Now, the thing that I think is kind of interesting is an approach that I've seen getting more popular, is in identifying attributes of the site, parts of the site, that might lend themself more immediately to being pre-generated and served statically than others. You don't necessarily have to everything as a big bang. You don't have to do the entire experience in one go. So, one of the examples I shared, kind of, briefly was the Citrix documentations site.

Scott: They didn't migrate all of Citrix.com across to being JAMstack. They identified a particular part that made sense to be pre-rendered, and they built that part out. And then, what they did was they started to put routing in front of all the requests that would come into their infrastructure. So, it would say, “Okay, well, if it's in this part of the past the domain, either in the sub-domain or maybe, through to a path, route that through something which is static, then the rest of it, pass that through to the rest of the infrastructure.

Scott: And I've seen that happen, time and time again, where with some intelligent redirects, which, thankfully, is something that you can do reasonably simply on the JAMstack. You can start to put fairly expressive redirect engines in front of the site. It means that you can pass things through just that section of the site that you tried to take on as a JAMstack project. So, choosing something and focusing on that first, rather than trying to do a big bang, where you do all of the legacy and migration in one. I think that's key, because, yeah, trying to do everything at once is pretty tough.

Vitaly: It's interesting, because just, I think, two days, maybe even today, Chris Coyier wrote an article renaming JAMstack to SHAMstack where, essentially, it's all about JavaScript in which we need think about steady coasting, because JavaScript could be hosted steadily as well. And it's interesting, because he was saying exactly that. He actually — when we think about JAMstack, very often, we kind of tend to stay in camps. It's either, fully rendered and it lives a static-thing. Somewhere there, in a box and it's served from a city and that's it, or it's fully-expressive and reactive and everything you ever wanted. And actually, he was really right about a few things, like identifying some of the things that you can off-load, to aesthetic-side, generated assets, so to say, to that area.

Vitaly: And, JAMstackify, if you might, say some of the fragments of your architecture. Well, that's a new term, I'm just going to coin, right there! JAMstackify.

Phil Hawksworth: I'm going to register the domain quickly, before anybody else.

Phil Hawksworth: And it's a nice approach. I think, it kind of makes my eye twitch a little bit when I hear that Chris Coyier has been redubbing it the SHAMstack, because it makes it sound like he thinks it's a shambles. But I know that he's really talking about static-hosting and markup, which I—

Vitaly: Yes, that's right.

Phil Hawksworth： JAMstackという用語は非常に誤解を招く可能性があるため、非常に多くの異なることをカバーしようとしているので、私は本当に好きです。物事の。 それはとても広いですが、重要なのはサイトのコアを静的に事前レンダリングしてホストすることです。 Reactサイトがどこにある必要があるかについて宗教戦争に巻き込まれるのは非常に簡単です。 JAMstackサイトになるにはReactアプリである必要があります。そうでない場合は、Reactアプリであるため、JAMstackにすることはできません。 しかし、実際には、JavaScriptを使用するかどうか、APIを呼び出すかどうか、事前にレンダリングして非常にパフォーマンスの高い静的ホストに物事を取り込む場合、それがJAMstackのコアです。

ヴィタリー：はい、もちろんです。

Phil Hawksworth：ブラウザーの機能が大幅に向上していることは非常に幸運です。また、ブラウザー自体の中にあるAPIを使用すると、さらに多くのことができるようになります。 ですから、そのようなことはさらに扉を開きますが、それは私たちがJAMstackサイトとして構築するすべてのものがすべてを利用しなければならないという意味ではありません。 私たちが提供しようとしているものに応じて、それは私たちがそれらのものを展開するために遊んでいるツールを選択し始める方法です。

ヴィタリー：もちろんです。 ここにドランがいます。 ドラン、私は知っていると思う、ドラン。 ドランを知っているような気がします。 彼は次のように質問しています。「サーバーレスが[inaudible00：44：36]からJAMstackとのシームレスな統合に向けて重力をかけていると思いますか？ JAMではAと呼ばれるもの。

Phil Hawksworth：それは素晴らしい質問だと思います。サーバーレス機能はJAMstackサイトと非常によく合います。実際、多くの点で、誰かがJAMstackサイトがサーバーレスかどうかを尋ねられたので、私はサーバーレスはそのようなロードされた用語であるため、その質問。 しかし、多くの点で、オリジンサーバーがないことについて何度も何度も話していたので、それは大げさです。 管理するサーバーインフラストラクチャはありません。 実際、私はかつて「Webサーバーレス」というブログ投稿を書いたことがあります。世界には別の話題の用語が必要だからですよね。

Phil Hawksworth：実際、そのような点は、そうです、私たちはサーバーなしで物事を構築しているということでした。 これらのサーバーを管理する必要はありません。サーバーレス機能、またはサービスとしての機能は、それに完全に適合します。 そのため、リクエストを送信するAPIが必要な場合は、ブラウザから直接リクエストを送信することは実際には意味がありません。 したがって、たとえば、そのリクエストにシークレットまたはキーがある場合、それらのリクエスト（その情報）をクライアントに公開したくない場合があります。 しかし、確かにそれらをプロキシすることはできます。通常、従来、サーバーをスピンアップし、要求を処理し、セキュリティ認証を追加して、それらの要求を渡すだけのインフラストラクチャを備えています。 、それらをプロキシバックします。

Phil Hawksworth：サーバーレス機能はそのために最適です。 彼らはそのために絶対に理想的です。 そのため、サーバーレス関数、またはサービスの関数を、サーバー上にロジックが必要なだけで、インフラストラクチャ全体を作成する必要がない、エスケープハッチのようなものと考えることがあります。 そして、それを使ってますます多くのことを行うことができ、サービスが成熟しているときの機能のために、開発ワークフローの開発パイプラインをスタイピングすることができます。 JavaScript開発者がこれらのものを構築できるようになることで、よりアクセスしやすくなります。 ですから、ええ、私はこれら2つのことが非常にうまく調和していると本当に思います。

ヴィタリー：わかりました、それは非常に包括的な答えです。 実際、私は最近、Amazonのフロントエンドエンジニアがサーバーレスと彼らが使用しているLamda機能について話していた講演に出席しました—私はほとんどいなくなっていました。 彼は常にDockerとKubernetesについて話していましたが、それらすべて、Devox World、私はそこに座って、「どうして彼はそこにたどり着いたのか」と考えていました。 何が起こっているのかわかりません！」 何が起こっているのか分かりませんでした。

Phil Hawksworth：その通りですが、以前は…私は…その世界のどれも理解していないことを受け入れましたが、それはまったく異なる分野のためだったので、私は何の欲求もありませんでした。 。 そして、その規律はまだ本当に重要です。 ご存知のとおり、インフラストラクチャを設計している人々は、それでも本当に重要です。 しかし、今、私は誘惑されているように感じます。 フロントエンド開発のバックグラウンドを持つ人として、JavaScript開発者として、私はその世界でプレイしたいと思っています。なぜなら、ツールが私に近づいているからです。

Phil Hawksworth：私がかつてダッピングしていた私自身の実験としてではなく、これらのもののいくつかを使用して、ある種の安全なものを提供できる可能性がはるかに高いです。 ですから、Web開発者としてより強力になっているような気がします。これは私にとってわくわくすることです。

ヴィタリー：パワーレンジャーのようにね？

ヴィタリー：私があなたに聞きたいことの1つですが、これは実際にはすでに1週間前に話し合ったものですが、セッションで言及したことの1つは概念だったので、それでも取り上げたかったのです。すべてのデプロイのスタンドアロンインスタンスを持つことは本当に素晴らしいことです。 ただし、問題は、何万ページもの大きな割り当てがある場合、毎回すべてのものを再デプロイしたくないということです。 したがって、基本的に、もしあなたが持っているなら、例えば、あなたが主に物事の静的な側面を使用しているなら。 それで、私たちはしばらくの間この考えを持っていました、そして私はこれが実際にあなたが前回提起したものであることを知っています。 アトミック展開のアイデア。

Vitaly：実際には、文字通り、セットアップのスナップショットの2つの異なるバージョン間である種のdivが提供されました。 したがって、ヘッダーをどこでも変更すると、もちろん、すべてのページを再デプロイする必要があります。 ただし、たとえばカルーセルなど、1000ページにしか影響しないコンポーネントを変更した場合は、15000ページを再デプロイするのが理にかなっています。 しかし、この1000だけです。それで、私たちはそこに着くことができますか？ そこにあるのは魔法のアイデアですか、それともこの時点でかなり具体的なものですか？

Phil Hawksworth：おそらく、静的サイトジェネレーターとこの種のモデルの聖杯だと思います。確かに、克服すべき最大のハードルを特定したからです。 またはあなたがぶつかる最大の天井。 そしてそれは、数万、数十万、または数百万のURLを持つWebサイトです。これは、ビルドが非常に長くなる可能性があるという概念です。 コードの変更に基づいて、どのURLが変更されるかを検出できるようにすることは困難です。 それは乗り越えられないものではありませんが、それは大きな挑戦です。 サイト全体の依存関係グラフを理解し、それをインテリジェントに展開することは非常に困難です。

Phil Hawksworth：あなたが言ったように、コンポーネントの変更は非常に広範囲にわたる影響を与えるかもしれませんが、あなたは—それがどのように機能するかを知ることは常に困難です。 そのため、多くの静的サイトジェネレーターがあり、その課題の背後にいくらかの重みを置いており、部分的な再生成と増分ビルドをどのように行うかを理解しようとしているプロジェクトがあります。 それが一日で解決するかもしれないという見通しに非常に興奮していますが、現時点では、それは間違いなく大きな挑戦です。 サイトを論理的にシャーリングしようとするようなことを始めて、もう一度、移行の問題に似たようなことを考えることができます。 ええと、私が知っているこのセクションは、それが使用するアセットの種類、またはそこに存在するコンテンツのタイプに関して独立しているので、それらを個別に展開できます。

Phil Hawksworth：しかし、それは私にとって理想的ではありません。 それは本当に完璧なシナリオではありません。 概念実証として、私が少し調べたアプローチの1つは、404をインテリジェントに使用するなど、どのように行うかを考えることです。 したがって、たとえば、非常に大きな看板の大きな使用例は、ニュースサイトである可能性があります。ニュース速報が発生したときにURLが必要な場合は、最初にURLを公開する必要があります。 彼らはそこにURLを取得する必要があります。 BBCニュースのように、ニュース記事がWebサイトに到着し、時間の経過とともに徐々に追加されることがわかりますが、最初にそこに到達することが重要です。 したがって、ビルドに10分、20分かかる場合は、それが何であれ、問題になる可能性があります。

Phil Hawksworth：しかし、コンテンツが抽象化されていて、APIから呼び出されていた可能性があります。 私は、Contentful、Sanity、またはそれらの束のように抽象化されたコンテンツ管理システムについて言及しました。 コンテンツAPIを持つものはすべて、ビルドをトリガーするコンテンツ構造に変更され、実行が実行されますが、他に発生する可能性があるのは、そのURLを公開してから、そのURLを公開することです。 、ビルドが実行されていない場合でも、誰かがそのURLをヒックした場合、404の最初のストップが「まだ取得していません」と言う代わりに、実際にはそのAPIを直接ヒットすることである場合は、次のように言うことができます。 、「まあ、ビルドはまだそれを実装し終えていませんが、クライアントでそれを行うことができます。」 APIに直接アクセスして取得し、クライアントに入力できます。

ヴィタリー：うーん、面白い。

Phil Hawksworth：それで、ビルドがまだ行われている間でさえ、あなたはそれらのものを投入し始めることができます。 そして、ビルドが完了すると、もちろん404にはヒットしません。静的に実行されているページにヒットします。 ですから、テクニックとそれに取り組むための戦略がありますが、それでも、それは非常に長く、とりとめのない答えです。申し訳ありませんが、私の結論は、ええ、それは挑戦です。 指が交差した私たちはより良い戦略を得るでしょう。

ヴィタリー：ええ、それは素晴らしいことです。 ですから、現時点では、コンテンツ配信のパフォーマンスだけでなく、ビルド速度のパフォーマンスも考えていません。 建物の展開のように。 ですから、これも私たちが探していたものであり、かなりの時間です。

ヴィタリー：もう1つお聞きしたいことがあります。 だから、あなたが言ったこのテクニックのように、これは興味深いです。 これについてどうやって学びますか？ これは、人々が自分のブログで公開する傾向があるものです。それは、メディアであるか、JAMstackの方法、つまり企業が荷降ろし中にどのように移動したか、または移動に失敗したかについて、ある種のケーススタジオを取得できる中央リポジトリがあります。 JAMstack。

Phil Hawksworth：それで、現時点では、この風景を少し成熟させているようなものです。 つまり、これらの例のいくつかは、私は非常に幸運な立場にあると思います。私はおもちゃで遊んでいる役割を果たしている場所で働いており、それを使用する興味深い方法を考え出し、実験を開始します彼らと一緒に。 したがって、これらの概念実証は、私が実験してこれらの課題に対処しようとするものです。 しかし、先ほど申し上げたように、ニューヨークで開催されたJAMstackカンファレンスで紹介されたケーススタディ、そして確かに、そのようなイベントでは、ベストプラクティスや業界慣行、業界アプローチがそのようなもので話題になり始めています。イベントの。 そして確かに、私はもっと多くの事例研究を見て、Smashing Magazinesのような場所に行き、この情報をもっと簡単に共有できるようにしたいと思っています。

Phil Hawksworth：大企業と企業スペースは、さまざまな場所でさまざまな方法でJAMstackを徐々に採用していると思いますが、世界はまだそこに到達するために傾斜しているので、企業がJAMstackを採用して共有するたびに経験、私たちは皆それから学ぶことができます。 しかし、私はこれらのケーススタディがますます公開されることを本当に望んでいます。そうすれば、特にこの種の課題をどのように克服するかについて学ぶことができます。

Vitaly：わかりました。では、私はいつも質問を読むのが好きなので、おそらく最後の質問です。 ですから、JAMstackの土地は、何かを変えることができれば、展開を超えて、必死に見たいと思うものがあるかもしれません。 あなたを本当に幸せにする他の何かはありますか？ それはあなたの日を作りますか？ それは何でしょうか？ JAMstackのウィッシュリストには何がありますか？

Phil Hawksworth：なんて質問でしょう。 つまり、インクリメンタルビルドについて話していなかったとしたら、それは—

ヴィタリー：やった。 今では手遅れです。 このカードはすでに合格しています。 他に何かが必要です。

Phil Hawksworth：そう—

Vitaly：つまり、プラットフォームのように、後ろのプラットフォームを見ると、非常に多くのエキサイティングなことが起こっています。 Houdiniがあり、Webコンポーネントが登場します。すべての適切なコンポーネントの全体像を変えることができるので、すべてがあります。 その一方で、SS NGSを備えたこの魔法のようなファンシーな世界がすべてあります。もちろん、もちろん、シングルページアプリケーションなどもあります。 何に一番興奮していますか？

Phil Hawksworth：進行中のことがたくさんあり、エキサイティングで、ブラウザーで利用できる新しい機能がたくさんあるので、ここでは鈍感になります。 私が本当にワクワクしているのは、人々が抑制を示していることです（笑）、そして私が言ったように、鈍い答えですが、より広い聴衆について、思慮深く、抑制されて行われる素晴らしい処刑を見るのが大好きです。 本当に楽しいし、最も光沢のある新しいJavaScriptライブラリまたは新しいブラウザAPIを使用して構築することは喜ばしいことです。これは、私たちが今、切実に必要としているブラウザの機能をスクラッチおよびスニッフィングします。

Phil Hawksworth：しかし、私は自分が知っていることが多くの場所で機能するのを見るのが本当に好きです。 彼らは本当にパフォーマンスが良く、存在するブラウザに共感するでしょう—おしゃれなおもちゃを手に入れたCEOやCTOの机だけでなく、はるかに低電力のデバイスを手にした人々、または彼らは困難なネットワーク条件とそのようなものがあります。 私は、プラットフォームに共感し、幅広い視聴者に思いやりのある方法で提供される興味深い体験と豊かな体験を見るのが好きです。なぜなら、ウェブは、それのために物を作る開発者である私たちよりもはるかに遠くまで届くと思うからです。 。 そして、より多くの人々に届く方法で、面白いことが行われているのを見て興奮します。

Phil Hawksworth：それはおそらくあなたが必ずしもそうであった答えではありません—

ヴィタリー：ああ、それはいい結末だ。 どうもありがとう。 いいえ、それは完璧です、それは本当にそうです。 大丈夫、私はすべてがうまくいったと感じました！ 一緒にいてくれてありがとう！ スコットに配っています！

Phil Hawksworth：すばらしい！

Vitaly：私は質問と回答をするためにここにいます。 だから、どうもありがとう、フィル！ 私はまだここにいますが、スコット、ステージはあなたのものです！ たぶん、Smashing TVで次に何が起こるかを私たちと共有できますか？

スコット：私はそうしますが、最初に、フィル、スクラッチアンドスニフAPIの実装がどのように機能するかを見るのが待ちきれません。 とてもおもしろそうですね。 そして、Vitaly、JAMstackifyはすでに使用されています。

ヴィタリー:(落胆した）取った？！ 買えますか？

スコット：いいえ、存在します！

ヴィタリー：まあ、それは手遅れです。 私はいつも遅れています。

Phil Hawksworth：それはそれ自体がエキサイティングです。

ヴィタリー：それは私の人生の物語です。 私はいつも遅れています。

スコット：次に来るメンバーは、13日木曜日に、私の昔のザック・レザーマンが、彼が最もよく話していること、つまりフォントについて話していると思います。 それで、彼はフォント実装の5つのYについて話している。 そして、19日に登場するJavaScriptとCSS、EvaFariaを使ったビデオの編集にも非常に興味があります。 ですから、これらの両方にご期待ください。

スコット：それはまた、来週の木曜日にザックレザーマンと、そして19日にJavaScriptとCSSでビデオを編集することについて話し合うエヴァとです。 それで、そのメモで、フィル、私はもうあなたに会えません、あなたはまだそこにいますか？

Phil Hawksworth：私はここにいます！

スコット：その点で、皆さん、どうもありがとうございました！ また、トロントエリアの近くに誰かいますか？ または、トロントに行きたいと思ったことのある人はいますか？ 6月末に会議が開催されますが、チケットはまだ数枚残っています。 だから、多分私たちはそこにあなたの何人かを見るでしょう。

ヴィタリー：ありがとうございました！

ヴィタリー：ああ、ちなみに、もう1つだけです！ Philがそれについて言及したかもしれませんが、7月にロンドンでJAMstackカンファレンスも開催されます。 ですから、それも注意が必要です。 しかし、私はサインオフしてサラダを手に入れようとしています！ 何をしているのかわからない—

スコット：さようなら、みんな！

ヴィタリー：わかった、さようなら、みんな。

おしまいです！

Smashingメンバーの継続的で親切なサポートに心から感謝します。今後さらに多くのウェビナーを開催するのが待ちきれません。

また、Philは来週のSmashingConf Toronto2019とJAMstack_confでMCを務めます。そこでもお会いしましょう。

この一連のインタビューが役に立ったかどうか、誰にインタビューしてほしいか、またはどのトピックを取り上げてほしいかをお知らせください。すぐに対応します。