JAMstack

Gatsby是一個使用React構建應用程序和網站的平台。 它是一個允許你使用一系列技術和實踐來構建的工具，這些技術和實踐被統稱為JAMstack。 Gatsby是當前前端開發領域中最火熱的工具之一。為什麼呢？我認為有以下幾個原因： “JAMstack"方法用於構建Web應用程序和網站的大幅增長 行業中對於"Progressive Web Apps”（漸進式Web應用程序）技術的快速采用，這也是Gatsby的關鍵功能之一 它是使用React和GraphQL構建的，這兩個技術非常流行和備受追捧 它功能強大 它的速度很快 文檔很好 網絡效應（有人使用它，創建站點，製作教程，更多人了解它，形成一種循環） 一切都是JavaScript（不需要學習新的模板語言） 它隱藏了複雜性，但允許我們逐步定制每一步 以上都是很好的優點，Gatsby絕對值得一試。 它是如何工作的？ 使用Gatsby，您可以使用React組件來構建應用程序。 您通常會使用Markdown編寫在站點中呈現的內容，但您也可以使用任何類型的數據源，例如無頭CMS或像Contentful這樣的Web服務。 Gatsby會構建站點，並將其編譯為靜態HTML，可以部署在任何Web服務器上，例如Netlify、AWS S3、GitHub Pages、常規託管提供商、PAAS等。您只需要找一個可以提供普通HTTP頁面和內容給客戶端的地方。 我在上面的列表中提到了漸進式Web應用程序。Gatsby會自動將您的站點生成為PWA，並使用服務工作器加快頁面加載和資源緩存。 您可以通過插件來增加Gatsby的功能。 安裝 您可以在終端中運行以下命令安裝Gatsby： npm install -g gatsby-cli 這將安裝gatsby命令行工具。 （當有新版本時，可以使用相同的命令進行更新） 您可以運行以下命令創建一個新的"Hello World"站點： gatsby new mysite https://github.com/gatsbyjs/gatsby-starter-hello-world 此命令將在mysite文件夾中創建一個全新的Gatsby站點，使用位於https://github.com/gatsbyjs/gatsby-starter-hello-world的starter。 Starter是您可以基於的示例站點。另一個常見的starter是default，可在https://github.com/gatsbyjs/gatsby-starter-default上找到。 您可以在這裡找到所有可用的starter的列表 運行Gatsby站點 在終端完成安裝starter之後，可以運行以下命令來運行網站： cd mysite gatsby develop 這將在本地主機的8000端口上啟動一個新的Web服務器並提供網站。 以下是我們的Hello World starter的運作示例： 檢查站點 如果用您喜歡的代碼編輯器（我使用VS Code）打開您創建的站點，您會發現有3個文件夾： .cache：一個包含Gatsby內部代碼的隱藏文件夾，您在現在不需要更改其中的任何內容 public：在構建站點後包含生成網站的靜態文件 src：包含React組件的文件夾，這裡只有index組件 static：將包含靜態資源，例如CSS和圖片 現在，對默認頁面進行簡單的更改非常容易，只需打開src/pages/index.js文件，將“Hello World！”更改為其他內容，然後保存。網頁應立即熱重載該組件（這意味著網頁實際上不會刷新，但內容會更改 - 這是由底層技術支持的一個技巧）。 要添加第二個頁面，只需在此文件夾中創建另一個.js文件，與index.js具有相同的內容（調整内容）並保存。 例如，我創建了一個名為second.js的文件，具有以下內容： import React from 'react' export default () => <div>Second page!...

如何使用 Netlify Lambda 函数，为 JAMstack 网站添加动态处理功能 之前我在我的Netlify教程中写到了Netlify。我使用它来托管这个博客，而且效果非常好。 我还使用它来运行其他网站，而且所有的网站都是基于 Hugo 构建的 - 这使得我的堆栈100%基于JAMstack。 JAM 的有趣之处在于它不仅仅局限于静态和"哑"网站 - 你可以实现任何你想要的动态功能。 其中大部分的功能由“lambda 函数”实现。 你可以让你的网站上的 JavaScript (或纯 HTML 表单) 调用 URL 接口，当调用时执行一些预先确定的代码。不同的供应商支持不同的编程语言。Netlify 目前支持 Node.js 和 Go。 在本教程中，我们将专注于使用 Node.js 编写的 lambda 函数。 Netlify 给我们提供了一个慷慨的免费使用限额，每个月最多可以调用 125,000 次函数，并且总计运行时间为 100 小时。函数提供了 128MB 的内存，每个函数可以执行最长 10 秒。对于一般需要，这已经足够了。 在内部，Netlify 在 AWS Lambda 上运行该函数，并为你抽象了 AWS 的所有复杂性。 我们如何创建函数呢？我们将一个 JavaScript 文件上传到站点的 functions 文件夹中。 在该文件中，我们必须遵循一个名为 handler 的方法： exports.handler = (event, context, callback) => { //功能实现 } 如果您对 AWS Lambda 比较熟悉，这段代码会让您感到亲切。如果您从未使用过它，不用担心 - 这里是我们 handler 接收到的参数的简要概述：...

了解 JAMstack 的意義以及這組技術的優勢 你在過去幾年中一定聽過 JAMstack 這個詞語。 JAMstack 是一組技術，結合使用以實現目標，如果你熟悉 LAMP 和 MEAN 的話，你可能已經知道了。 JAMstack 是什麼意思？ JAM 表示 JavaScript、API 和 Markup。 它描述了在創建網絡應用程式和網站時具有以下特點的趨勢： 有一個“愚蠢”的網絡伺服器（或者CDN），傳送運行應用所需的 HTML，通常是使用靜態站點產生器生成的。HTML 不是在伺服器上生成。 應用程式可以載入一些 JavaScript，從 API 中接收數據。頁面互動，如導航，可以導致從 API 獲取更多數據。認證也是通過 API 完成的。 這種新的方法是一種新的方式，與傳統的方式不同： 傳統網站提供應用程序中已有的內容（如靜態站點）。 基於 CMS 的網站從後端的數據庫中加載信息。 使用任何種類的後端語言進行服務器渲染的應用程式。 它也不同於具有服務器渲染部分的客戶端渲染網站（例如使用 React 構建）。JAMstack 完全不涉及服務器渲染。 使用 JAMstack 的優勢是什麼？ 它快速。HTML 已經生成並且網絡伺服器只需提供它，而無需進行從數據庫查找數據或為每個請求生成頁面 HTML 等任何後端操作。它可以通過 CDN（內容傳遞網絡）輕鬆提供。 它高效。由於沒有後端，所以沒有瓶頸（例如沒有數據庫）。 它更便宜，因為通過 CDN 提供資源比通過後端伺服器提供資源要便宜得多。 它更安全，因為後端僅通過 API 公開。 傳統的動態服務器渲染網站應用程序的方式（如 WordPress、Laravel 和 Rails）在許多情況下正被一種較輕的方式所取代。 一個典型的 WordPress 網站在每次頁面加載時可能對數據庫進行30-100次請求，這取決於安裝的插件數量。除非頁面被大量緩存，否則當一個 WordPress 網站在 Hacker News、Reddit 或任何其他大型網站上變得流行時，你會看到一個空白頁面-這意味著伺服器上發生了故障，因為該網站無法應對所有的流量。這往往是一個失去的機會，因為當網站以其最高的流行度時它無法運作。 相比於這些情況，提供一個靜態 HTML 頁面要有效得多，並且在 HTML 載入後可以根據需要仍然獲取動態數據，使用獨立的 API 呼叫。...

在使用現有服務或平台和建立自己的平台之間做出決策 我現在遇到了一個很大的問題。 我正在試用各種平台，看看它們是否適合成為我將來托管課程的地方。 我現在使用的平台是基於靜態網站的，使用自定義集成和無代碼工具（如Airtable）進行接口。付款和課程報名使用Node.js服務進行管理。你可以稱它為JAMstack，serverless，或者任何當下流行的時髦術語。 事實上，我有幾個類似的SAAS平台，供我每門課程使用。我喜歡把事情保持簡單和直接。一開始，我為一門課程制作了一個網站。 然後當我需要開設另一門課程時，我只需複製那個網站，製作另一個「版本」。 現在課程的數量增加到了7門，是時候重新檢視我使用的整體基礎設施了。 我第一個想法是使用一個我可以使用的平台，它可以作為課程材料的集中式中心，並提供我不必自己構建的功能。 所以我去試用了一些流行的服務，包括Teachable，Podia，和其他許多平台。 但我遇到了我所謂的開發者困境。 乍一看，這些平台都很棒。設計精美，界面流暢，它們的行銷也很出色，看起來很棒。 然後我開始使用它們。 我開始感到越來越沮喪。 「這看起來很棒」 「整體上我喜歡，但這個東西可以不同一點」 「編輯器糟糕透了」 「我希望我能使用 Markdown」 「這裡有個bug，怎麼可能只有我遇到這個問題？」 「嘿，支援，我遇到這個問題了」 - 「我們已經將它提交給工程團隊，我們會保持你的最新動態」 「我的天啊，我已經在這上面浪費了很多時間」 我是一個懶惰的開發者。我認為這是我最好的技術能力。 當你是一個懶惰的開發者時，過度設計軟體不是問題。這永遠不會發生。我只寫出執行任務所需的最小量的程式碼。 我抵制複雜性。 這有何好處？你不能預測明天的需求，明天的問題。我隨著時間的推移學到了這一點。 作為一名合約工，我曾經在非常複雜的程式碼庫上工作，讓我想哭，每當可能的時候，我都更喜歡過度簡化而不是過度複雜。 作為一個懶惰的開發者，這也使我在編寫軟體之前多思考很多。 因為編寫軟體是一種責任。 你正在寫下你未來要承擔的負擔。 假設，繼續我上面關於選擇課程平台的事情，假設我決定自己編寫我的課程平台。 這意味著我首先必須編寫它。 我需要做出決策。可能是對的，也可能是錯的。 在我建立我夢想中的軟體之後，我需要在未來維護這段程式碼。我為此負責。不再有「向支援請求」的按鈕。 作為開發者，我們有這種令人難以置信的能力創建我們需要的工具。然而，這也代表著責任。 但這也是一個擁有問題。我想依賴於這個特定平台未來的5-10年嗎？如果他們的決策與我的不一致怎麼辦？如果他們提高價格怎麼辦？我能輕易地轉移到其他平台嗎？ 在理想情況下，我總是會選擇自己的平台而不是由其他人管理的平台。但我同樣也會選擇最簡單的路線。 對我來說，最大和最珍貴的資源是時間。選擇現有解決方案，我可以有更多的時間。 我應該花一個月的時間來編寫自己的課程平台嗎？ 這就是我目前面臨的開發者困境。 我試用了所有可能的現成解決方案。 它們都沒有兌現其承諾（或我心中對它們的形象）的某種方式。 我決定我要寫自己的解決方案。當然，是最簡單的解決方案。