ジャムスタックに関する5つの神話

Jamstackは新しいものではありません。この用語は2016年に正式に登場しましたが、それが説明するテクノロジーとアーキテクチャは長い間存在してきました。最近、Jamstackは広範囲にわたる注目を集めており、主要なWebサイトや出版物が関連するレポートを公開しており、多くのアクティビティ、ニュースレター、ポッドキャストなどがJamstackに焦点を当てています。 Jamstackを密接に追跡する開発者として、Twitterで関連する議論の大幅な増加さえ観察しました。その多くは最初にコンセプトにさらされています。

ホットな議論には批判も伴います。批判のいくつかは正当化され、後でそれらのいくつかについて話しますが、他の人はJamstackに関する持続的な一般的な誤解のいくつかに基づいているようです。それがまさに私が最初に解決しようとしていることです。それでは、私が遭遇したジャムスタックについての5つの一般的な誤解を見てみましょう。多くの誤解のように、それらは通常いくつかの実際の状況に基づいていますが、誤った結論につながります。

誤解1：Jamstackは、静的Webサイトの単なる交換用パッケージです

Jamstack 99.9％はブランドマーケティング、0.1％が実際のコンテンツです。 ?? https://www.php.cn/link/33f976eca39ccf5a14627fc9f6cf1b9

- ニコールサリバン - ブラックライフマター（@stubbornella）2020年2月9日

はい、先に述べたように、「Jamstack」という用語は、間違いなく「静的Webサイト」と呼ばれるものの再包装です。これは、まだ完全に形成されていない製品を誤解させたり販売したりすることを意図したものではありません。 「静的ウェブサイト」という用語は、人々が何を構築しているかを説明することができませんでした。静的なWebサイトジェネレーター（SSG）で構築されたWebサイトには、さまざまな動的なコンテンツと機能が含まれています。

静的Webサイトは主にブログとドキュメントと見なされ、そのユーザーインターフェイスは主に修正されています。相互作用の範囲は、コメントと連絡先フォームを埋め込んでいる場合があります。一方、Jamstack Webサイトには、ユーザー認証、動的コンテンツ、eコマース、ユーザー生成コンテンツなどの機能が含まれています。

証拠が必要ですか？ Jamstackで構築された有名な企業やWebサイトには、Smashing Magazine、Sphero、Postman、Prima、Impossible Foods、Trinetが含まれています。

誤解2：Jamstack Webサイトは脆弱です

Jay Freestone、「Jamstackについて質問：バックエンドが必要かもしれません」という記事で

Smashing Magazineの依存関係リストを読むことは、Algolia、Gocommerce、Gotrue、Gotell、およびさまざまなNetlifyサービスなど、サーバー上のnode_modulesのようなものです。何がアウトソーシングできるのか（いつ）できるかを知ることは大きな価値がありますが、「基礎に戻る」という明らかな試みで複雑さが導入されることは注目に値します。それは、非常に多くの異なるサードパーティサービスに依存することに伴う潜在的な脆弱性を言う必要はありません。

はい、Jamstackと静的Webサイトを区別する動的機能を実装するために、Jamstackプロジェクトは通常、ファーストパーティやサードパーティのサービスを含むさまざまなサービスに依存しています。これにより、Jamstack Webサイトが2つの理由で特に脆弱になると考える人もいます。第一に、彼らは、いずれかの部分が失敗した場合、ウェブサイト全体の機能がクラッシュすると言います。第二に、あなたのインフラストラクチャは、あなたが持っていないツールとサービスに依存しすぎるようになります。

最初の議論を解決しましょう。 Jamstack Webサイトのコンテンツのほとんどは、事前にレンダリングする必要があります。これは、ユーザーがウェブサイトにアクセスすると、ページとそのコンテンツのほとんどが静的リソースとしてCDNから配信されることを意味します。そのため、Jamstackはスピードとセキュリティのほとんどを取得しています。ショッピングカート、認証、ユーザー生成コンテンツ、検索などの動的な機能は、サーバーレス関数とAPIの組み合わせに依存して動作します。

大まかに言えば、アプリケーションは、APIに接続するためのバックエンドとして機能するサーバーレス関数を呼び出します。たとえば、eコマース機能がStripeのAPIに依存して動作し、Stripeがダウンする場合、はい、eコマース機能は機能しません。ただし、Webサイトがダウンしないことに注意することが重要です。ユーザーに問題を伝えることで、この問題を優雅に処理できます。 eコマースのストライプAPIに依存するサーバー側のレンダリングページは、同じ問題に直面します。サーバー側のレンダリングページがまだ支払いのために非同期にバックエンドコードを呼び出していると仮定すると、Jamstackバージョンよりも脆弱でも脆弱ではありません。一方、サーバー側のレンダリングが実際にAPI呼び出しに依存している場合、ユーザーは応答を待ったりエラーメッセージを受け取ったりする可能性があります（ネットワークを使用している人は誰でもこれに精通しています）。

2番目の引数に関しては、Jamstack Webアプリケーションとサーバー側のレンダリングアプリケーションがサードパーティに依存する程度を測定することは困難です。現在、多くのサーバー側のレンダリングアプリケーションはAPIに依存して多くの機能を実装しています。これにより、開発、プロバイダーの特定の専門分野を活用し、法的なコンプライアンスの問題やその他のコンプライアンスの問題に対する責任を放送することができます。これらの場合、サーバー側のレンダリングされたバージョンは、Jamstackバージョンよりも依存したり、依存したりすることはありません。確かに、アプリケーションが主に内部または自家製のソリューションに依存している場合、事態は異なる場合があります。

誤解3：コンテンツを編集することは困難です

Kev Quirk、記事「なぜ静的Webサイトジェネレーターを使用しない理由」：

LinuxボックスにSSHを使用して、VIMに関する記事を編集する必要があるように思えます。モバイルライティングに関しては、エントリに対する非常に高い障壁のようです。あなたがそれを好むかどうかにかかわらず、今日の世界はモバイルファーストなので、モバイルライティングは簡単なはずです。

この問題は、過去に静的なWebサイトの遺産のように感じられます。明確にするために、Webサイトのコンテンツを編集するためにLinuxボックスを入力するためにSSHは必要ありません。完全に無料でオープンソースから、大企業にコンテンツを提供する商用製品まで、さまざまなヘッドレスCMSオプションがあります。彼らが提供する編集機能は、従来のCMSに匹敵します（私はこれについて前に話しました）。ポイントは、ブログサイドプロジェクトでさえ、Markdown、Yaml、またはJSONファイルを手動で編集する理由がないということです。これらすべての部品を接続する方法がわかりませんか？解決策もあります！

合理的な批判は、ヘッドレスCMSとビルドプロセスにより、編集中のコンテンツとWebサイトの変更との間の切断を引き起こす可能性があるということです。公開前、または複雑なビルドプレビュープロセスなしで、ライブWebサイトでの変更の影響を正確にプレビューすることは困難です。エコシステムはこの問題を解決しています。 Stackbit（私が働いている場所）のような企業は、このプロセスをシームレスにするツールを構築しています。

この問題の解決にコミットしているのは私たちだけではありません。その他のソリューションには、TinacmsやGatsbyのプレビューが含まれます。 JamstackのWixなどのツールでWysiWyg編集のシンプルさを実装しようとしていると思います。

誤解4：JamstackのSEOは難しいです

Kym Ellis、「Jamstackがマーケティングのために意味するもの」という記事で：

プラグインの概念をあきらめ、「Just HTML」Jamstack Webサイトを選択することは、機能をあきらめる必要があるというわけではありません。また、Webサイトとそのコンテンツを管理するために、フロントエンド開発者のようにコーディングを突然学習する必要があるわけではありません。

近年、この問題が頻繁に発生するのを見ていません。SEOに関連するメタデータを管理するYAMLベースのFrontMattersの手動編集に関連する静的Webサイトの時代からのレガシー批判であると思います。 SEOを正しく行うことは、特に生成された各ユニークなページに異なるメタデータを注入するか、検索リストを強化するために不可欠なJSON-LDのような構造化されたデータを作成する場合、退屈で維持が困難になる可能性があることを心配しています。

Jamstackのコンテンツ管理の進歩は、多くの場合、SEOメタデータを維持する複雑さに対処します。さらに、ページは事前にレンダリングされているため、必要なメタデータが存在する場合、サイトマップとJSON-LDの追加は比較的簡単です。プレレンダリングにより、Webサイトのインデックス作成を必要とする検索エンジン（つまりGoogle）を簡単に作成できます。また、CDNと組み合わせることで、Webサイトのランキングを改善するパフォーマンスベンチマークを簡単に実現できます。

基本的に、Jamstackは「Technical SEO」が得意であると同時に、コンテンツエディターに必要なキーワードやその他のメタデータを提供します。 JamstackとSEOをより包括的に理解するために、BejamasのJamstack SEOガイドをチェックすることを強くお勧めします。

誤解5：Jamstackには、多くのJavaScriptフレームワークが必要です

「Jamstack」の利点を促進する美しいWebサイトは、通常のWebサイトを最新のフレームワークに取りつかれた経営陣に販売しようとする場合に非常に便利です。

- Jdietrich、ハッカーニュース

最近、JamstackはフロントエンドのJavaScriptフレームワークと同義語になっているようです。実際、最も有名なソリューションの多くは、Gatsby（React）、Next.js（React）、Nuxt（Vue）、Vuepress（Vue）、Gridsome（Vue）、Scully（Angular）などのフロントエンドフレームワークに依存しています。これは、Jamstackの「J」に関する混乱によって悪化しているようです。 JavaScriptの略ですが、これはすべてのJamstackソリューションがJavaScriptベースであることを意味するものではなく、すべてがNPMまたはJavaScriptフレームワークを必要とすることを意味しません。

実際、最も広く使用されているツールの多くは、JavaScript、特にHugo（Go）、Jekyll（Ruby）、Pelican（Python）、最近リリースされたBridgetown（Ruby）で構築されていません。同時に、EleventyなどのツールはJavaScriptで構築されていますが、JavaScriptフレームワークに依存していません。これらのツールはどれもJavaScriptフレームワークの使用を妨げませんが、必要ありません。

ここでのポイントは、JavaScriptフレームワークを放棄したり、ツールを使用したりしないことです。これらは、多くの開発者がうまく使用している優れたツールです。 JavaScriptフレームワークは、非常に複雑なタスクを簡素化できる非常に強力なツールです。ここでのポイントは、JavaScriptフレームワークをJamstackを使用するために要求するという考えが間違っているということです。Jamstackには460のスタイルがあります。

改善できる場所

それは本当ですか？ Jamstackは、すべてが完璧であるだけでなく、非常に簡単なWeb開発の理想的な世界です。残念ながら、そうではありません。 Jamstackには多くの合理的な批判があります。

シンプルさ

Sebastian de Deyne、「Jamstackを扱った後、考えるべきこと（および質問）」の記事で：

私の経験では、Jamstack（JavaScript、API、およびTags）は、もはや大きくないまで素晴らしいです。ある日、私はいくつかの動的なコンテンツを追加する必要があり、この日は常に来るとき、私は頭をかき始めます。

正直に言うと、Jamstackを始めるのは簡単ではありません。もちろん、静的なWebサイトジェネレーターを使用してブログや簡単なWebサイトを構築することは特に難しくないかもしれません。しかし、動的な機能を備えた実際のWebサイトを構築しようとすると、物事はすぐに複雑になります。

通常、タスクを完了するための多くのオプションに出くわします。これにより、長所と短所の重量が困難になります。 Jamstackの最良の側面の1つは、規範的ではないことですが、複雑なタスクには適していないかもしれないという印象を残すことができないように見えることです。

バインディングサービス

実際にこれらの動的な機能の構築を開始すると、あなたのウェブサイトはさまざまなサービスとAPIに依存することになります。ヘッドレスCMSを呼び出してコンテンツを取得したり、APIのサーバーレス関数を呼び出して支払いトランザクションを実行したり、Algoliaなどの検索サービスを使用したりすることができます。これらすべての部品をまとめることは非常に複雑なタスクです。通常、各セクションに独自のダッシュボードとAPI/SDKの更新があるという事実に加えて、事態はさらに複雑になります。

そのため、StackbitのようなサービスやRedwoodJのようなツールは、Jamstack Webサイトの背後にあるさまざまな部品をまとめ、それらのパーツを構築と管理しやすくするため、重要だと思います。

フレームワークの過剰使用

私の意見では、現代のフロントエンド開発におけるJavaScriptフレームワークへの依存は、最近質問する必要があります。ティム・カドレックの最近の記事が述べているように、トレードオフがあります。前にも言ったように、Jamstackで動作するためにJavaScriptフレームワークは必要ありません。

ただし、多くのJamstackツールがJavaScriptフレームワークに依存しているため、この印象は生じます。ジャムスタックに教える方法は、主にフレームワークの使用に焦点を当てています。私はこの理由を理解しています - 多くのJamstack開発者はJavaScriptフレームワークに精通しており、各ツールを教えることは不可能であるため、好きなツールを選択します。それにもかかわらず、私は個人的には、Jamstackの長期的な成功はその柔軟性に依存していると思います。これは、JavaScriptフレームワークを使用するかどうかにかかわらず、それが提供するさまざまなソリューションを紹介する必要があることを意味します。

次に行く場所

うわー、あなたはそれをしました！私は多くのことを知っていることを知っています。執筆を始めたときに気づいたよりも多いので、明らかに、その欠陥にもかかわらず、Jamstackの価値を非常に確信している人の観点からこれらの誤解を提示したことを除いて、長い結論に迷惑をかけることはありません！

サーバー側のレンダリングでJamstackを選択しないときについての良い記事を探している場合は、Chris Coyierの最近の記事Staticかどうかをチェックしてください。 》。

以上がジャムスタックに関する5つの神話の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。