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

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

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

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

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

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

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

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

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

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

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

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

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

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

2番目の引數(shù)に関しては、Jamstack Webアプリケーションとサーバー側(cè)のレンダリングアプリケーションがサードパーティに依存する程度を測定することは困難です?，F(xiàn)在、多くのサーバー側(cè)のレンダリングアプリケーションはAPIに依存して多くの機(jī)能を?qū)g裝しています。これにより、開発、プロバイダーの特定の専門分野を活用し、法的なコンプライアンスの問題やその他のコンプライアンスの問題に対する責(zé)任を放送することができます。これらの場合、サーバー側(cè)のレンダリングされたバージョンは、Jamstackバージョンよりも依存したり、依存したりすることはありません。確かに、アプリケーションが主に內(nèi)部または自家製のソリューションに依存している場合、事態(tài)は異なる場合があります。

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

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

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

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

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

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

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

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

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

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

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

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

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

「Jamstack」の利點(diǎn)を促進(jìn)する美しい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）で構(gòu)築されていません。同時に、EleventyなどのツールはJavaScriptで構(gòu)築されていますが、JavaScriptフレームワークに依存していません。これらのツールはどれもJavaScriptフレームワークの使用を妨げませんが、必要ありません。

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

改善できる場所

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

シンプルさ

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

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

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

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

バインディングサービス

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

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

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

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

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

次に行く場所

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

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

以上がジャムスタックに関する5つの神話の詳細(xì)內(nèi)容です。詳細(xì)については、PHP 中國語 Web サイトの他の関連記事を參照してください。