ポッドキャストエピソード29をLeslieCohn-Weinとスマッシング：ドッグフードをJamstackでNetlifyする方法

このエピソードでは、NetlifyでJamstackをドッグフードするのはどのようなものかを尋ねています。 アプリ全体をCDNにデプロイできますか？ DrewMcLellanがNetlifyのスタッフエンジニアであるLeslieCohn-Weinに話を聞いて調べました。

メモを表示

• レスリーの個人サイト
• Twitterのレスリー
• Netlify

毎週の更新

• react-three-fiberを使用したReactとThree.jsの詳細
  フォーチュン池地脚本
• EコマースUIデザインのベストプラクティス
  スザンヌスカッカによって書かれました
• Auth0を使用したReactアプリの認証
  NefeEmadamerho-Atoriによって書かれました
• 専門家から：COVID-19中のグローバルデジタルアクセシビリティ開発
  ロビンクリストファーソンによって書かれました
• Vue 3の新機能
  TimiOmoyeniによって書かれました

トランスクリプト

ドリュー・マクレラン：彼女はオースティン出身の受賞歴のあるフロントエンドのスペシャリストですが、現在はニューヨーク市のスティントを経由してテキサス州ダラスに住んでいます。 その間、代理店で働いていた彼女は、任天堂、ワールドプライド、ジェリーサインフェルドなどのクライアント向けのサイトを構築しました。 彼女は現在、Netlifyのスタッフフロントエンドエンジニアであり、とりわけ、顧客がサービスと展開を管理するために使用するアプリケーションの構築に取り組んでいます。 それで、彼女が熟練したフロントエンドエンジニアであることは知っていますが、ニューヨーク市に住んでいるとき、彼女は3年連続でチリ料理コンテストのアシスタントジャッジを務めていました。 そして、それは実際に真実です。 私の壊滅的な友人、レスリー・コーン・ウェインを歓迎してください。 こんにちは、レスリー。 元気ですか？

Leslie Cohn-Wein：私は壊している。

ドリュー：今日は、Jamstackでの構築に関して、Netlifyが独自のドッグフードをどのように食べ、その魅力的な表現を使用するかについてお話ししたいと思います。 数か月前まで、私たちはNetlifyの同じチームで一緒に働いていたと言って、これを少し文脈に入れておく必要があります。 そして、私がそこに着いたとき、開発者として20年経った後でも、開発プロセスは実際には私にとって本当に異質でした。 私はそれが本当に魅力的で、より多くの聴衆と一緒に少し探索する価値があると思いました。 これについて話しているのは、本当に興味深いケーススタディであり、Netlifyのスポンサー付きの大きな広告ではないためです。 誰もがVercelをチェックする必要があります。 しかし、特にJamstackの観点から、それについて議論することから学ぶことができる貴重なことがたくさんあると思います。 NetlifyはJamstackアプローチの非常に大きな支持者であり、サービスは一種の顧客に提供されており、Jamstackプロジェクトを構築するというアイデアに基づいて構築されているためです。 ただし、サービスはこれらの原則自体を使用して構築されています。 そうですね。

レスリー：そうですね。 多くの人がそのJamstackアーキテクチャを静的サイトと考えていますが、Netlifyフロントエンドを使用してJamstackアプリを構築することの意味を実際に理解しています。 これは、NetlifyをNetlifyにデプロイする完全なJamstackアプリであるReactアプリであるため、…ええ、私たちは実際に試して、可能なことの限界を押し広げています。

Drew：あなたが言うように、Jamstackは静的なサイトだけに最適であるという考えがあると思います。フォームをメールアドレスに送信したい場合は、APIの側面が取り入れられ、そのような簡単なことを行うことができますが、そのようにしてWebアプリ全体を構築できる可能性があります。 しかし、あなたはそれをしているのではありませんか？

レスリー：ええ、もちろんです。 app.netlify.comにログインした場合に表示される内容について具体的に説明している私たちのアプリは、内部REST APIを備えていますが、フロントエンドは、私が言ったように、純粋なJamstackです。 そのため、独自のビルドステップがあり、アプリがアプリにビルドされるのを監視し、独自のシステムにデプロイします。

Drew：つまり、バックエンドプロセスが関係していて、ある種のレベルのバックエンドプロセスが常に存在する場合、データを永続化するか、Netlifyの場合は、デプロイメントまたは何を持っているかから始めて、そのバックエンドだけを使用します。フロントエンドで使用できる一連のAPIとして構築されますか？

レスリー：ええ、これを機能させる方法にはいくつかの異なるモデルがあります。 ほとんどの場合、私たちのアプリでは、Reactでクライアント側のフェッチを使用していますよね？ そのため、アプリの静的シェルのようなものを提供し、リクエスト時に内部RESTAPIからユーザーの情報を取得します。 Jamstackは、事前に構築できるものがいくつかあるので興味深いものです。可能な場合は、それに依存するようにしています。 そして、より動的なデータのいくつかについて話しているときは、最新のデータを確実に取り込むために、そのクライアント側のフェッチを使用します。

Drew：アプリの開発を始めたとき、特に外部APIやものとのやり取りに関して、フロントエンドでどれだけの成果が得られているかは驚きだと思います。 NetlifyがGitプロバイダーとやり取りするとき、GitHubに移動し、リポジトリのリストのリストを取得することを知っています。これはすべて、ブラウザーとGitHubの間で発生します。 そして多分…リクエストにいくつかの秘密を置くサーバーレス関数またはそのような軽量なものを通過することを除けば、そのほとんどはJamstackのような方法で起こっているだけです。 Netlifyのようなコアバックエンドインフラストラクチャを経由していません。 だから、それは非常に魅力的です。 これは、小さなことを行うためのAPI呼び出しがいくつかある静的サイトをはるかに超えています。 それが本当のコア機能ですよね、それはブラウザに実装されていますか？

レスリー：もちろんです。 フロントエンドの開発者エンジニアとは何かという概念を本当に推し進めていると思いますよね？ そしてそれは、フロントエンドエンジニアとして、私をより良くし、そのような種類の…APIレイヤーについてもっと考えるように私を駆り立てるものです。これは、私が伝統的に近づいてきたものではありません。 私はUI、色、デザインシステムでより多くの作業を行っているので、実際には…Jamstackアプリを大規模に作業することで、より優れた開発者になることができました。

ドリュー：フロントエンド開発者であることは、CSSを裏返しに知っているわけではありませんが、それはその一部です。 HTMLを前後に認識しているわけではありませんが、それはその一部です。 それはまた、伝統的にバックエンドエンジニアの保護区であったこの領域に迷い込んでいます。これは非常に興味深いことです。 Netlifyは新しいサーバー側レンダリングを使用しますか？

レスリー：私が知っていることではありません。

Drew：つまり、あなたが言うように、それはすべて文字通り行われ、シェルを提供し、その後、さまざまなAPIエンドポイントに戻ってリクエストが入力され、すべてが入力されます。

レスリー：その通りです。

ドリュー：それはReactアプリだとあなたは言いますか？

レスリー：はい。 はい。 反応する。 現在ReactReduxを使用しており、現在はPostCSSですが、CSSアーキテクチャも実験しています。

ドリュー：みんなじゃないの？ では、Reactでアプリをビルドしてから、Netlifyにデプロイしますか？

レスリー：はい。 たぶん、そのプロセス全体の中で私のお気に入りの部分は、Netlifyを介して取得するDeployPreviewsの魔法です。 つまり、何が起こるかというと、あなたは…GitHubで作業していて、PRを押し上げます。 つまり、GitHubでPRを開くと、アプリのデプロイプレビューのビルドが自動的に作成されます。 そのため、実際にはアプリ自体のDeploy Previewsを使用してテストし、すべてが正常に機能していることを確認します。 テストを実行します。 これは、コードレビュー中に手動で検証するために使用するものです。 そのため、GitHubから直接セットアップされた継続的デプロイのようなものがあります。

レスリー：そして、私たちが設定した他のクールなことの1つは、アプリが存在する同じリポジトリからプルしている2つの異なるNetlifyサイトが実際にあることです。 つまり、両方のアプリがあり、アプリのUIコンポーネントのようなものを含むStorybookのインスタンスがあります。 つまり、アプリ自体とStorybook UIコンポーネントの両方があり、基本的にStorybookUIを表示するNetlifyサイトがあります。 そして、webpackバンドルアナライザーを実行する3番目のサイトもあります。 つまり、ツリーマップ、すべてのアプリバンドルの視覚化を提供するビジュアルUIであり、それらのサイズをある程度測定することができます。これは、一種の再確認を思い出させるためのものです。 アプリのデプロイが完了するたびに、バンドルサイズで何か変なことをしていないことを確認できます。 したがって、これら3つのサイトはすべて、アプリの1つのプルリクエストで生成されます。 そのため、アプリストーリーブックとそのアプリプロファイルの両方のプレビュー、基本的にはデプロイプレビューへのリンクが表示され、確認することができます。

Drew：そして、Deploy Previewsを使用すると、本質的にそのようなものがステージング環境になりますか？

レスリー：その通りです。 従来のステージング環境は実際には実行していません。これは、デプロイプレビューが、マージボタンを押してメインアプリでメインブランチの公式ビルドを開始したときに、基本的にライブになると確信しているためです。 ですから、ステージング環境としてDeployPreviewsを信頼できるのが大好きです。 私たちは、それが生産と一致することを本当に信じています。 すべての本番変数、すべての環境変数を使用してビルドしています。これらはすべて、DeployPreviewでビルドされます。 ですから、それは心配のない状況のようなものです。 Deploy Previewが機能している限り、アプリも機能することがわかります。

Drew：組織として、Deploy Previewが公開されるものと一致しない場合、それはNetlifyが解決したいサービスの問題だと思います。 したがって、実際には、その観点からは非常にうまく機能します。 つまり、Deploy Previewを確認しました。すべてが見栄えが良く、PRがマージされます。 それではどうなりますか？

レスリー：つまり、Netlifyはすべての継続的デプロイを実行するため、基本的にすべてを接続して、メインブランチへのマージがアプリでの公式の本番デプロイを自動的に開始するようにします。 したがって、通常、独自のPRをマージした開発者の場合は、実際のP​​Rにアクセスします。アプリのデプロイプレビューを開いてアプリを開いている場合は、タブを再確認する必要があります。確認する必要があります…通常、実際のアプリをフォローしたいと思います。 だから、あなたはあなたのタブをチェックする必要があります。 ただし、ええ、アプリでは通常、開始したばかりのマージのビルドログを確認できるため、すべて自動で実行されます。 そして、これらのビルドログが完了し、サイトが稼働するとすぐに、ブラウザウィンドウを更新するだけで、デプロイしたばかりのものがアプリで更新されます。

ドリュー：問題が発生した後、問題が発生したとしましょう。それではどうしますか？

レスリー：それはとても良い質問です。 そして、Netlifyで働く前から、Netlifyを使用することについての私のお気に入りのひとつかもしれません。これは、Netlifyが一種の焼き付け、いわゆるロールバックを行っているため、私にとってはちょっとした魔法のようでした。 つまり、基本的にNetlifyでのすべてのデプロイは、このJamstackアーキテクチャを使用しているため、すべてのデプロイはアトミックです。 つまり、これまでにサイトで行ったあらゆる種類のデプロイの完全な履歴があり、それらのいずれかに即座にロールバックできるということです。 したがって、誤ってバグをデプロイしたり、何かが壊れたりした場合、通常最初に行うことは、その継続的インテグレーションを実際に停止することです。 では、Netlify UIのボタン1つで、「自動公開を停止」と言うだけで、GitHubとの接続が停止します。 したがって、私のチームメイトが突然PRもマージする場合、バグを再導入することはなく、そのようなことは起こりません。

レスリー：それで、これらの自動展開をすべて停止します。 そして、私がしなければならないのは、デプロイリストに戻って最後に機能しているデプロイを見つけ、「これを公開する」というボタンをもう1つ押すだけで、ライブになります。 つまり、実際に戻ってコードを確認し、実際に何が起こったのかを理解できるようにするために、そのプレッシャーを取り除くことができます。 これは、メインブランチでGitを元に戻し、メインブランチを必要な場所に戻すことを意味する場合があります。 また、ホットフィックスである場合や、ブランチに移動して修正された場合でも、Gitで元に戻すことを心配する必要はありません。 そして、戻る準備ができたら、アプリのデプロイプレビューですべてが機能していることを確認し、すべてをリセットして元に戻すことができます。 したがって、これらの自動展開を開始するとすぐに、基本的にビジネスに戻ります。

ドリュー：それで、私はここで問題を見つけました。

レスリー：うーん。

Drew： Netlifyを使用してNetlifyアプリに変更をデプロイしています。 展開したバグによってロールバックが停止した場合はどうなりますか？ だったらどうしようか？

レスリー：悪夢があります。 いいえ。実際、これを処理する方法はいくつかあります。 そのため、アプリを停止し、UIを使用してこのプロセスを実行できない場合、DeployPreviewsは実際に本番APIに対して実行されます。 つまり、アプリが機能していなくても、それらのアトミックデプロイが残っているということです。 したがって、GitHubから、おそらく古いまたは最近のPRからのリンクがあり、そのデプロイプレビューURLがある場合は、実際にアプリのデプロイプレビューにアクセスして必要な変更を加え、戻って古いデプロイを公開できます。デプロイプレビューから。 そして、それはまだ本番APIにヒットしているので、それでもアプリに影響を与え、それからアプリを元に戻します。 脳の絵文字が爆発するようなものですが、それを行う1つの方法です。 一部のバックエンドシステムから古いデプロイを公開することもできます。 バックエンドエンジニアに公開してもらうことができます。 または、いつでもGitを使用して元に戻し、それを押し上げることができますが、何をしているのかを見ることができないため、少し怖いです。

ドリュー：その状況を管理するには、非常に明確な心が必要だと思います。

レスリー：うん。

ドリュー：しかし、それは完全に回復可能です、それはそれのように聞こえます。

レスリー：うん。 さて、作業用デプロイを公開すると、すべてのプレッシャーはなくなります。 それは本当に素晴らしい部分です。 そして、私はこれが代理店でも機能していることを発見しました。 ロールバックできることは、本当に命の恩人でした…また、新しい変更を公開することについての心配が少なくなります。 何かを壊した場合、それをロールバックするのに1秒かかります。これは、ある種の動きにすばやく適合し、モデルから物事を取り出します。

ドリュー：もちろん。 通常、この種のワークフロー全体は、非常に小さな変更を処理する場合に最適に機能すると思います。 つまり、理想的には、ブランチを作成し、小さな変更を実装し、PRを上げてから、それをできるだけ早くマージしたいと考えています。 これは明らかに微調整やバグ修正などの小さなことには問題なく機能しますが、主要な機能の展開が開始されるまでに数週間から数か月かかる場合は、主要な機能の作業にはあまり効果がありません。 そのようなプロセスをどのように管理しますか？

レスリー：ええ、それは素晴らしい質問です。 そのため、最近、機能フラグをもう少し使用し始めました。 それをどのように行うかについてもう少し話す前に、私たちが以前行っていたことについて話します。 したがって、フィーチャーフラグを使用する前は、誰もが長期的なフィーチャーブランチのアイデアに精通していると思います。 私たちは皆、彼らを嫌っていますよね？ しかし、私たちはより小さなPRに取り組みます。 コードレビューの後、これらのそれぞれを個別に、このより長く実行されている機能ブランチにマージします。 したがって、基本的にすべての新機能を1つの場所に配置し、その新機能をテストできる1つのデプロイプレビューを作成できます。 このモデルでは、他のチーム間で調整された展開が必要になる場合があります。 つまり、「この機能ブランチは、マージしてライブにする準備ができています」と言う準備ができたとき、「バックエンドがすでに変更をデプロイしていることを確認する必要があります」という意味でした。この機能で行っているAPI作業は準備ができています。 この機能と同時に公開する必要のあるドキュメントがドキュメントサイトにある場合は、調整とボタンの押下を同時に行う必要があります。

レスリー：このモデルは…私たちにとってはうまくいきましたが、あなたは正しいです、それはおそらく最もスムーズではなかったということです。 Netlifyの共同創設者兼CEOであるMattBiilmannは、昨年、Jamstack Conf Londonのステージで、このプロセスを使用して分析機能を実際に立ち上げました。 そこで、彼は私たちのロックデプロイ機能を使用して、基本的にアナリティクスの新機能のデプロイプレビューを取得し、ステージ上でライブで公開しました。 だから、それはかなりクールでした。

レスリー：しかし、あなたが言ったように、それは…あなたは少し自信がありません。 このプルリクエストには、まだすべてが隠されています。 少し扱いに​​くくなります。 通常は非常に大きい最終的なプルリクエストを誰かが承認する必要があります。 それは少し圧倒的です。 そのため、最近は主にフィーチャーフラグを使用しています。 LaunchDarklyというサービスを使用します。これにより、基本的に新機能のUIをこれらのフラグでラップできるため、UIが顧客に見せたいものでなくても、コードを継続的にマージできます。 したがって、本番環境で機能フラグがオフになっていることを確認するだけで、コードをデプロイしてマージできます。一般ユーザーであると仮定すると、その新しいUIは表示されません。

ドリュー：つまり、機能フラグは基本的に、「この機能が有効になっている場合はこの新しいコードを使用し、そうでない場合はこの古いコードを使用する」というコードのスイッチのようなものです。

レスリー：その通りです。

Drew：それは、これらすべてのフォークが配置された、ある種の厄介なコードベースを取得することを意味しますか？ どのように対処しますか？

レスリー：ええ、そうだと思います…フィーチャートグルを使用する人は、フィーチャートグルをいつクリーンアップするかというこの種の戦いにおそらく慣れていますか？ どれくらいそこに置いておきますか？ 主要な機能がリリースされてから約2週間で、リマインダーがあります。 幸い、LaunchDarklyは実際に最近Slackに通知する機能を設定しました。 つまり、Slackに接続すると、次のように表示されます。「ねえ、あなたのフィーチャートグルは…2週間本番環境で稼働しています。 コード内のフラグを確実にクリーンアップする時が来ました。」

レスリー：それで、私たちは試してみて、それをかなり迅速にクリーンアップしますが、その間に、旗がまだそこにあることを知っているのはいいことです。 この機能をリリースした場合でも、ワンクリックでそのフラグを元に戻すことができ、何かポップアップが表示された場合はバグが発生します。 そのため、機能が実際にベイク処理されている間、人々がそれに慣れている間は、大きな問題がないことを確認するために、少しの間それらを残しておくのが好きです。 ただし、コードに戻ってみると、少しクリーンアップされるため、理想的なプロセスではありませんが、通常、フラグを削除するのにそれほど時間はかかりません。数行のコードを削除するだけです。

ドリュー：つまり、機能フラグを実装するための最も簡単なアプローチは、「この機能はオンまたはオフです」というアプリの構成変数のようなものかもしれませんが、それを確認する方法が必要です。適切な人のためにオンになり、適切な人のためにオフになります。 そして、LaunchDarklyのようなサービスが登場するのは、それが必要だからだと思います…つまり、基本的に、変数のオンとオフを極端なレベルに切り替える必要がありますね。

レスリー：はい。 はい。 まさにそれです。 したがって、LaunchDarklyがなくても、基本的に自分で構成変数を設定して、自分で管理する方法があります。 LaunchDarklyで私が気に入っていることの1つは、さまざまな環境があることです。 したがって、私たちができることは、基本的に、DeployPreviewsの機能フラグをオンにすることです。 そのため、Netlifyで内部的に表示しているユーザーは誰でも、アプリのデプロイプレビューで新機能にアクセスしてテストできますが、本番環境で公開されるとすぐに、そのフラグはオフになります。 ですから、ほとんどありません…繰り返しになりますが、タブをチェックして、自分がどのセグメントに属しているかを確認する必要があります。自分を驚かせたくないし、何かを立ち上げたと思っているからです。あなたはそうしませんでした、あなたはそこで少し注意しなければなりません。 ただし、一般的には非常にうまく機能し、LaunchDarklyではこれらの選択的なロールアウトも実行できます。 そのため、コードベースの一部、または特定のユーザーセグメント、特定の種類のプランを持つユーザー、または特定の種類のユーザーに機能を展開できます。 そのため、リリース先をより細かく制御できます。

ドリュー：うん。 これは非常に強力な場合があります。特に、新しい機能や、問題の解決を期待している可能性のある機能の場合はそうです。 機能を拡張して理解しやすくしたり、10％のユーザーで試して、同じ問題が発生しているかどうかを確認したりできます…

レスリー：その通りです。 ええ、それはフィードバックを得るための素晴らしい方法でもあります。

Drew： LaunchDarklyをこのように使用することは、独自のソリューションを展開するのではなく、Jamstackアプローチの別の側面のようなものだと思いますね。 この機能を提供するAPIを使用しているだけで、自分で実装する方法や開発する方法、維持して維持する方法を気にすることなく、次のようにアウトソーシングできます。このAPIを使用する予定であり、他のすべてが処理されます。」

レスリー：うん。 うん、その通り。

Drew：つまり、このアプローチでは、基本的に小さな新機能を本番環境にコミットすることができますが、それらはフラグの背後に隠されているだけです。 そして、すべての準備が整ったら、フラグを反転するだけで、問題が発生した場合にすばやく元に戻すことができます。

レスリー：そうだね。 それは私たちの打ち上げを少しエキサイティングなものにします。 以前は、これらの大きなボタンを押していて、このすべてのコードがマージされ、ビルドログを監視していて、これが期待の瞬間です。 そして今、あなたはズームコールに飛び乗って、ボタンを1つクリックするだけで、ライブになります。

ドリュー：うん。 前回の機能起動であるNetlifyに取り組んだと思いますが、このアプローチを使用しました。 そして、チーム全体で数週間の作業が行われ、リリースを調整するためにZoomコールに参加し、全員がパーツの準備ができていることを確認しました。 次に、機能フラグを反転して、すべてのユーザーに対してオンにしました。これで完了です。

レスリー：できました。

ドリュー：そしてそれは数分で終わり、それは本当に反気候的でした。

レスリー：ええ、それはちょっと悲しいです。

ドリュー：汗をかいた手のひらはなく、何もありませんでした。もちろん、まさにあなたが望むものですよね？ みんなのために何かをオンにすることが大したことではない場合、それはあなたが堅牢なプロセスを持っていることをあなたが知っている方法です。

レスリー：その通りです。 そして、それをロールバックする必要がある場合も、それは非常に簡単で、ワンクリックです。 それはその圧力、不安のいくらかを和らげます。

ドリュー：つまり、おそらく、すべての変更がフロントエンドの変更だけになるわけではないということです。 バックエンドが変更されることもあり、おそらくほとんどのバックエンドシステムにも独自の機能フラグがあります。 だから、あなたはドキュメントについても言及しました。 これらすべてを一緒に調整する方法はありますか？ 全員が同時に旗を立てるだけですか？ またはそれはどのように機能しますか？

レスリー：うん。 つまり、これは現在Netlifyでチーム全体で積極的に取り組んでいる分野であり、すべてのシステムが使用しているLaunchDarklyの1つのフラグにすべてを結び付けることができるソリューションに向けて取り組んでいます。 、すべてのコードベースが使用しています。 したがって、理想的な世界では、フラグを反転して次のように言うことができます。「これは、機能フラグでラップされたこの新しいUIを使用して、フロントエンドでも使用されている新しいAPIエンドポイントを切り替えています。ドキュメントサイトのこの部分だけでなく、この新機能に関する新しい情報もあります。」 そして、その1つのフラグを反転すると、それらすべてのリポジトリに影響を与えます。 私たちはまだそこにいません。 私たちはそれを処理していますが、それらすべてを調整して機能させることができるかどうかを確認することに興奮しています。

Drew： Netlifyは、サービスがこのようにサイトを構築するために非常に調整されているためです。 あなたとあなたのチームが製品を使用して行っている作業は、実際に製品開発にまったく影響を与えましたか？

レスリー：確かにそうだと思います。 誰もがあなたはあなたのユーザーではないといつも言っていますが、あなたがあなたのユーザーである場合を除いて、ほとんどの場合そうだと思います。 特にフロントエンドチームのほとんどの人は、以前にNetlifyを製品として使用したことがある人だと思うので、これはNetlifyで面白いです。 そして確かに、Netlifyを使用してNetlifyをデプロイしているため、一部のユーザーと同じ課題に直面しています。 したがって、ある意味で、問題が発生した場合は、それを会社の他の人に伝えようとします。 エンジニアリングコールでそれについて言及するか、CTOを引き込んで、「ねえ、これは私たちが苦労していることです。 私たちと、私たちと同じようなものを展開しているすべてのユーザーにとって、これを簡単にする製品に組み込むことができるものはありますか？」 ですから、それはある種のユニークな立場ですが、製品ロードマップがどのように開発されるかを見るのは楽しいことです。

ドリュー： Netlify自体と同じくらい集中的にNetlifyを使用している人はおそらく少ないと思います。

レスリー：うん。 うん。 そうだと思います。 私はNetlifyを構築しているときと展開しているときの両方を見つめているので、かなりよく知っています。

ドリュー：そして週末にサイドプロジェクトに取り組み、再びNetlifyに戻ってきました。

レスリー：うん。 それは実際には非常に真実です。 うん。 はい。 はい、確かに。

ドリュー：チームが行った作業によって製品の方向性がどのように影響を受けたかなどの例はありますか？

レスリー：うん。 そのため、ごく最近、チーム概要と呼んでいるアプリ用の新しい種類のランディングダッシュボードをリリースしました。 そのため、Netlifyにログインすると、サイトのページが表示されます。これは、基本的にはサイトの長いリストになります。 そして、私たちは人々に、多くの重要な情報を一目で見ることができ、彼らにとって最も役立つものにアクセスできる、もう少しミッションコントロールエリアを提供したかったのです。 そして、それは私たちが構築した新しい機能でした。 最初のイテレーションでは、すぐにそれを取得しようとしています。そのUIには、最新のビルドにリンクする小さなカードがあります。 チーム全体のビルドが表示され、そのカードに表示されます。

レスリー：最初は、実際にはそれらをビルドにリンクしていませんでした…表示ログ自体。 だから、それはあなたがそれをチェックすることができる単なるリストでした。 ビルドページをクリックすると、似たようなビューが表示されます。 しかし、私は実際に週末に個人的なサイトで何かに取り組んでいました。このチームの概要をオンにしていて、Netlifyにログインしていて、自分のプロジェクトで行われているこのビルドをチェックしたいと思ったので、イライラしました。そして、私はそれをクリックしてそれを正しく理解することができませんでした。 ビルドページをクリックしてから、もう一度クリックする必要がありました。 それで、仕事の翌日、私は入ってその変更を追加し、それらのビルドをリンクしました。それは私を悩ませていたからです。 ですから、それは製品を使って、それを改善する機会が非常に少ないことを実感した一例でした。 そして、私たちはそれを取りました。

レスリー：しかし、他にもいくつかの例があります。 おそらくもう少し影響力があります。 1つは、このフォーム検出機能を追加したことです。 したがって、少し背景がわかりませんが、Netlifyフォームは、フロントエンドフォームを作成できるNetlifyの機能です。 そして、Netlifyは、提出物を管理するすべてのバックエンド作業を行います。 これは、フロントエンドで構築したフォームのデータベースのようなものです。 つまり、フォームの送信を管理するために、サーバー側のコードや大量の追加のJavaScriptを記述する必要はありません。 Netlifyにデプロイした実際のサイトでは、ビルドが行われているときに、ビルドボットがデプロイ時にサイトのHTMLを解析して、Netlifyが注意を払って管理する必要のあるNetlifyフォームがあるかどうかを基本的に検出します。 そして、ビルドボットがそれを探しているこのフォーム検出は、デフォルトで有効になっています。

レスリー：しかし、それが意味するのは、ご想像のとおり、ボットがこの余分なステップを探しに行く必要があるため、ビルド時間が少し消費されるということです。 そのため、Netlifyアプリ自体は、実際には使用していません。現在、アプリにNetlifyフォームはありません。 したがって、これは基本的にビルド時間に少し追加するステップですが、必ずしも実行する必要はありません。 そのため、Netlifyは実際に、すべてのユーザーがそのフォーム検出を無効にできる新機能を構築しました。 つまり、サイト設定でその設定をオフにできるということです。ビルドボットは、探す必要のあるものが何もないことを認識しているため、ビルドでの余分な処理時間を少し節約できます。

ドリュー：生産性の面では素晴らしいと思います。物事が少し早く完了するからです。

レスリー：その通りです。

ドリュー：しかしまた、従量制サービスとして、あなたが持っている種類の手当からより多くを得ることができます。

レスリー：うん。 丁度。 ですから、これは私たちのユーザーや顧客からも聞いたことであり、私たちも気づいたことでした。 それは、「まあ、私たち自身の製品ではこの余分なステップは必要ありません。 では、すべてのユーザーに提供して、すべてのユーザーの生活を少し楽にし、この機能を使用していない場合は、すべてのユーザーのビルドを少し速くする方法はありますか？」

ドリュー：危険はありますか…つまり、あなたはあなたがあなたのユーザーではないと言いますが、Netlifyではあなたがあなたのユーザーであることがよくあります。 製品を使用する強度が高いと、使用しているユーザーの種類を見落としたり、すべてが複雑になりすぎたり、高度になりすぎたりして、入手が非常に困難になる危険性はありますか？で始まった？

レスリー：それは素晴らしい質問です。 また、Netlifyのユーザー調査機能とデータサイエンス機能も実際に構築しており、全体として、アプリの使用と展開に関する私の逸話的な経験よりもはるかに信頼していると思います。 しかし、Netlifyを使用しているのは誰か、どのタイプのユーザーと話しているのかをより正確に把握できるように、これらすべてのデータが一緒になっていると思います。 さまざまなタイプのニーズを持つ人々がいます。 スターターチームにはブログや個人サイトを管理している人々がいます。また、Netlify自体とそれほど変わらない、大規模なマーケティングキャンペーンや大規模なWebアプリを立ち上げている大企業もいます。 したがって、ユーザーベースが拡大するのを見て、これらすべてのユースケースについて考え、それらすべてのユーザーに対応する方法を理解することは、わくわくすることです。 そして確かに、私たちの内部経験だけでなく、それらのユーザーが誰であるかを理解することに頼るために、私たちの研究機能の多くを使用しています。

ドリュー：レスリー、Netlifyが提供しているスクリーンショットサービスについて教えてください。 それは本当に面白いと思ったからです。

レスリー：うん。 私たちが持っているUIでは…Netlifyにサイトをデプロイすると、UIには、あなたが感じたサイトのホームページがどのように見えるかを一般的に示す小さなスクリーンショットがあります。 少し前にサーバーレスでChrisCoyierのエピソードを聞いていたので、これを取り上げたのは実際には面白いです。彼はCodePenでもスクリーンショットを作成する方法について話していましたが、実際にはNetlifyの方法とそれほど変わりません。 ただし、基本的にはPuppeteerを実行して、ユーザーサイトのスクリーンショットをキャプチャします。すべての実行方法は、Netlify関数を使用してセットアップすることです。 ですから、これもまた、私たちが自分たちの製品をドッグフーディングしている例です。 したがって、基本的には、独自のアプリ内のNetlify関数であるこのエンドポイントを使用して、スクリーンショットのその画像のURLを返します。これにより、アプリでそれを提供できます。

ドリュー：つまり、Netlify関数はNetlifyのサーバーレス関数の実装ですよね？ 基本的に、JavaScriptファイルをソースの一部として指定されたフォルダーにドロップするだけで、クラウド関数として実行できるようになります。

レスリー：はい、その通りです。

ドリュー：超スマートですね。

レスリー：うん。 すばらしい。 This is one of those areas where it really pushes me as a frontend engineer to really be more of this JavaScript or Serverless engineer, and think a little bit more about how you're basically writing like an internal API end point for yourself when you create one of these Serverless functions. So, it's exciting because there's so much you can do, but that can make it a little intimidating also because there's so much you can do.

Drew: I sort of find it funny how it's like… that's seemingly a core piece of functionality for Netlify, displaying images alongside your site of what it looks like, yet, it's just implemented with another Netlify feature. And you wonder how far you go before it all disappears in on itself in a big cloud of smoke.

Leslie: Yeah. うん。

Drew: This sounds like a really nice way to be working, and a very modern way to we're working, but it can't be without its challenges, can it?

Leslie: Absolutely not. I think I've spoken a little bit about what it means sort of as a frontend engineer pushing into sort of some new areas just for me to be thinking about in terms of Serverless and how can we leverage this in the product? I think for me, mastering that sort of back of the frontend side has been an exciting challenge, but certainly there's a lot to learn there. An example of that in our app right now, is that we use Cypress for end-to-end testing of some of the critical flows in our app, and right now we have that set up so that the Cypress end-to-end tests are running on our Deploy Previews in Pull Requests using a GitHub action. So, we use the GitHub action to run those Cyprus tests against the Deploy Previews of the app.

Leslie: Which is really cool, but there's probably a better way to do this than actually using a GitHub action. I actually think that we could use a Netlify Serverless function because those can be triggered on certain events, like a deploy succeeded event. So, there's an opportunity there for us to actually leverage again, Netlify, a little bit more, instead of relying on some of these other tools that maybe we're more familiar with or more comfortable using. So, in terms of challenges, I think it's opening our minds to what this sort of new model of development allows us to do and trying to leverage it.

Drew: Yes, there's so many different ways on there to… with the tooling that's available, to be able to attack a particular problem. At Smashing, we probably shouldn't say there's more than one way to skin a cat.

Leslie: Yikes.

Drew: What's interesting about the workflow as well, is that it's really intensively Git based, which I think suits… it's really developer friendly, isn't it? As a frontend engineer, something that's Git based kind of just feels like home. So, is that all great or are there any problems that come in with that?

Leslie: I think as a developer Git is wonderful. I think in general it solves big, big problems and I'm very happy to have it. But, because we rely on it so heavily and as our internal team has grown as well, you end up having the same problems that Git has when you're talking about Netlify in this workflow, right? So, you end up with a bug on your main branch, yes, it's really easy to roll back the app itself, we talked through what that looks like, and then go in the code and fix it. But what if someone else on your team is working from a broken version of that main branch? Everyone's going to have to rebase, everyone's going to have to communicate, or at least be aware of what happened. And so, it's not so much a Jamstack problem or a Netlify problem, but more of just the age old, how do you coordinate on a team of human beings and how do you use the technology to do that properly?

Drew: And of course, as you add more tools and infrastructure in around what you're doing, then you've got the problem of everything taking a long time to run. I mean, you mentioned Cypress is one thing. I know Cypress is a real headache with the amount of time those end-to-end tests can take to run. Is there other challenges around that growing build time?

Leslie: Yeah, I think that's one of the other things that Jamstack… You're introducing this build time, which for developers is not great. I always try and think about it as what I sort of eat up in that build time, my users are saving in the performance of what they're getting. So, I always try to keep that in mind when I'm frustrated about how long something is taking to build, but certainly I think that's an area of opportunity and a challenge, is figuring out how to keep those build times fast, how to make sure that we can deploy as quickly as possible. Some of it is this sort of tension between wanting to run all your tests, wanting to make sure that you don't deploy a build if a test fails, but at the same time, then you've got to run all those tests.

Leslie: So, it's this constant sort of back and forth between wanting to keep the build times fast, while also making sure that you feel like you're doing your due diligence before you actually deploy something. And we're playing around with some ideas here as well about potentially moving our Cypress tests to be running against production and having some alerting setup that would let us know after the fact, if something had failed. Which is sort of an interesting model, too. So yeah, stay tuned.

Drew: I certainly know that, yes, the dangers of growing build times, just from a developer point of view, from productivity point of view, that if something takes too long to run, you context switch, you start working on something else, and then it just… you lose all the momentum, and maybe you forget to go back and find out whether the build succeeded because you're then so far into the next task.

Leslie: Yeah, definitely.

Drew: So, I guess this isn't the ultimate workflow as it stands at the moment. There must be further we can take it. What sort of opportunities might lie ahead for this way of working?

Leslie: Yeah. So, I think for me, and Netlify in particular, is sort of the thought of collaboration for larger teams. I mean, I know a lot of developers are sort of… have used Netlify for side projects and other things that they're working on, on their own, but thinking about how it can be leveraged on larger teams, like mine. As we get larger and we're growing, more of us are in the app, more of us are using Netlify to deploy our own services, and so everything from even more robust audit logs so that you can go and see who changed this site setting, or who was the last person to deploy something. I think having the ability to organize your sites within your Netlify dashboard, even knowing… assigning someone to a build is sort of an interesting idea to me. Could that be helpful if I knew that my teammate had worked on this build, but then I realized they had to roll it back? And maybe I'm just aware of who's managing that process could be a really useful thing within Netlify itself.

Leslie: And one thing that I've seen sort of thrown around a little bit is perhaps the ability to link to a specific log line in build log. So, for debugging, if you have your build log of your Deploy Preview, and there's an error that got thrown, either from Netlify or from your own code, it'd be nice to be able to link directly to that log line. So, that's sort of a fun, small improvement that I've been thinking about a bit. And that's not even to say we have some new features at Netlify as well, that are pretty exciting. Edge handlers and background functions. I'm still trying to wrap my head around what they all do and exactly how they work, but I know that edge handlers are going to give us the opportunity to do some things with localized content, which could be… have some interesting implications for features we could build in the Netlify app as well.

Drew: Yeah, it's really exciting. I think there are all sorts of people within the Jamstack community who are pushing this the whole thing forward. But I think Netlify, as a service, is one that is really behind it and doing exciting things. And, as I say, I didn't want this to be a big ad for Netlify, but I think you and I both really love the service, so it is exciting to talk about isn't it? If listeners want to get more engaged with learning how to build Jamstack sites or want to get more into this ecosystem, is there a good place to go to learn this stuff?

Leslie: I feel like it's exploding right now. I would certainly point you to the Netlify blog. We try and post some tips and tricks there and announce new features as well. I would give a shout out too, to Learn With Jason. My coworker, Jason Lengstorf does sort of a live stream show, and he does cover… he covers a range of topics, but does some Jamstack specific ones as well. And it's a fun hour of live coding and picking that out. Twitter, I think, is huge, too. So check out Jamstack hashtag.

Drew: Good advice. So, we've been learning all about how Netlify builds Netlify on Netlify. What have you been learning about, Leslie?

Leslie: Oh, that's always a big question. I mentioned Cypress before, we've been working through some of our processes around exactly how we want to run our end-to-end tests, and so I would say that, in general, I've been thinking a lot about that workflow. So, less about the technology itself, but more about what workflows exist for end-to-end testing on the frontend, and what makes sense sort of in this Jamstack model. So, that's been a fun sort of side tangent. And then, on the CSS side of things, we talked a bit about CSS architecture, and I'm starting to get my hands dirty with Tailwind, which has been a fun and exciting and lots to learn and lots of class names to memorize and… Yeah.

Drew: That's exciting stuff. If you, dear listener, would like to hear more from Leslie, you can find her on Twitter where she's @lesliecdubs, and her personal site is leslie.dev. Thanks for joining us today, Leslie, did you have any parting words?

Leslie: Have a great day?