現代Web應用程式也被稱為單頁應用程式（Single Page Applications）。這是什麼意思？ 在過去，當瀏覽器的功能比現在差得多，JavaScript的性能也很差時，每個頁面都是從服務器上請求的。每次點擊某些東西時，都會向服務器發送一個新的請求，然後瀏覽器會加載新的頁面。 只有非常創新的產品才會以不同的方式工作，並嘗試新的方法。 如今，受到像React這樣的現代前端JavaScript框架的推動，一個應用通常被構建為單頁應用程式：你只加載一次應用程式代碼（HTML，CSS，JavaScript），當你與應用程式交互時，通常發生的是JavaScript截取瀏覽器事件，而不是向服務器發送新的請求，然後返回一個新文檔，用戶看到的頁面從未完全被刷新，表現得更像桌面應用程式。 單頁應用程式是使用JavaScript構建的（或至少編譯為JavaScript），並在瀏覽器中運行。 技術總是一樣的，但應用程式的工作方式的哲學和一些關鍵組件是不同的。 單頁應用程式的一些例子 一些值得注意的例子： Gmail Google Maps Facebook Twitter Google Drive 單頁應用程式的優缺點 單頁應用程式對用戶來說感覺更快，因為不需要等待客戶端和服務器之間的通信，也不需要等待瀏覽器重新渲染頁面，現在可以立即獲得反饋。這是應用程式製造者的責任，但你可以使用過渡效果、旋轉圖示和任何一種優化用戶體驗的方式，這肯定比傳統的工作流程要好。 除了讓用戶體驗更快之外，服務器會消耗更少的資源，因為你可以專注於提供一個高效的API，而不是在服務器端構建佈局。 如果你還在API之上構建一個移動應用程式，那麼這將非常理想，因為你可以完全重用現有的服務器端代碼。 單頁應用程式易於轉化為漸進式Web應用程式（Progressive Web Apps），從而為你的服務提供本地緩存和支持離線體驗（或者如果用戶需要在線時提供更好的錯誤消息）。 當不需要搜索引擎優化（SEO）時，單頁應用程式是最合適的選擇。例如，對於需要登錄的應用程式。 儘管搜索引擎每天都在提升，但它們在索引使用單頁應用程式方法構建的網站時仍然存在問題，而不是傳統的服務器渲染頁面。這對於博客來說也是如此。如果你依賴搜索引擎，除非同時具有服務器呈現的部分，否則不要麻煩去創建一個單頁應用程式。 在編寫單頁應用程式時，你需要編寫大量的JavaScript。由於應用程式可能長時間運行，你需要更加注意可能的內存泄漏 - 如果在過去，你的頁面的壽命計算在幾分鐘內，那麼現在一個單頁應用可能會長時間打開，在這段時間內，如果有任何內存問題，它將使瀏覽器的內存使用量大大增加，並導致不愉快的緩慢體驗，如果不加以處理的話。 在團隊中工作時，單頁應用程式很棒。後端開發人員可以專注於API，而前端開發人員可以專注於創建最佳的用戶體驗，並利用後端構建的API。 作為缺點，單頁應用程式嚴重依賴於JavaScript。這可能會導致在低功率設備上運行應用程式時速度較慢。此外，有些訪問者可能會禁用JavaScript，你還需要考慮到你所構建的任何內容的可訪問性。 重寫導航 由於你摒棄了默認的瀏覽器導航，URL必須手動管理。 這部分被稱為路由器。一些框架已經為你處理了它們（例如Ember），其他的則需要使用能完成這項工作的庫（例如React Router）。 問題在哪裡？在開發單頁應用程式時，這曾經是開發者的一個事後考慮。這導致了常見的“後退按鈕失效”問題：當在應用程式中導航時，URL不會改變（因為瀏覽器的默認導航被劫持），當按下後退按鈕時，這通常是用戶返回到上一個屏幕的操作，卻可能跳到多年前的網站。 這個問題現在可以通過瀏覽器提供的History API解決，但大多數情況下，你會使用一個内部使用該API的庫，如React Router。tags:Single Page Applications, JavaScript, frontend frameworks

什麼是無伺服器(Serverless)，為什麼你應該關心呢？ 無伺服器(Serverless)是一種運行程式的方式，不需要自行管理伺服器。 你只需要創建一個函數，將其放置在雲端伺服器的某個位置，然後你只需要一個URL來呼叫。 當你呼叫該URL時，函數就會執行。 其他人負責管理伺服器、擴展性和安全性。無需擔心核心更新或升級到Linux發行版的下一個LTS版本。 從價格模型上看，無伺服器也非常方便。傳統上，你可能每月租用一個VPS（虛擬私有伺服器），無論你實際使用量如何，你都需要支付每月價格。 如果你的網站在某個熱門地方被分享，用戶數量激增，除非你升級到更大的伺服器，否則伺服器可能無法處理所有請求。 使用無伺服器，你只需支付每個請求的費用，而不是伺服器的價格。如果沒有人使用你的服務，你不需要支付任何費用。如果有10萬人同時訪問你的網站，你的函數將自動擴展，因為為你管理函數的公司已經為處理流量準備好了一切，它會自動為你的函數提供更多的資源。你只需支付實際使用的資源，而不是某些未來可能使用的資源。 對於獨立開發者來說，當做得好時，無伺服器也從心理角度上為他們帶來很大的解放感。你不需要負責支撐你的應用程式的伺服器，所以你不需要全天候提供支援來解決可能發生的任何問題。你不需要成為系統管理員或運維專家來執行你的應用程式。 聽起來像是夢幻世界，那麼有什麼問題呢？ 首先，無伺服器仍處於早期階段。各大廠商對於無伺服器都有不同的實現方式，周邊工具的品質也各有不同。 從價格的角度來看，如果你的流量有一定的預測性且你可以以較低的成本購買伺服器，例如在AWS上預訂實例，那麼使用無伺服器可能並不划算。 你也無法控制伺服器，這意味著你必須依賴於可用的基礎設施進行日誌記錄、監控和調試，並且很難在本地複製你的設置。 市場上有哪些主要的參與者？ AWS Lambda Azure Functions Google Cloud Functions AWS Lambda可能是最著名和最被使用的，目前支援Java、Go、PowerShell、Node.js、C#、Python和Ruby的無伺服器函數的創建。 AWS Lambda是為開發人員提供簡化無伺服器方案的產品所使用的底層服務： Netlify Lambda Functions Apex Up 他們在 https://aws.amazon.com/lambda/faqs/ 上有一個很棒的常見問題解答，我建議你去閱讀一下。

資料庫和資料庫管理系統（DBMS）的主要特性。 資料庫是一個仔細組織成系統的信息集合。 在電腦系統中，可以讓我們組織數據並表示信息的技術被稱為資料庫管理系統。 DBMS是一個軟件，它封裝了資料庫的數據，並為我們提供了一種集中的方式來存儲、檢索、編輯、持久化等數據。 讓我們定義一些資料庫管理系統的主要特性： 高效：資料庫需要提供最優性能來存儲和檢索數據。 持久性：存儲在資料庫中的數據是永久性存儲的。當資料庫軟件終止或機器重啟時（除了硬件故障），數據應該仍然存在。 隱私與安全：資料庫允許我們隱私地和安全地存儲數據。它允許多個用戶訪問，並且每個用戶只能訪問和編輯其被允許的數據。某些用戶可能只能訪問數據而不能編輯或刪除數據。 共享訪問：多個用戶需要能夠通過適當的權限訪問共享數據。多個應用程序也可以訪問同一個資料庫。 強大：資料庫可以處理大量的數據，並且可以根據您的需求進行擴展，使用各種高級技術。這並不意味著只有在擁有大量數據時資料庫才有用 - 基於上述特性，即使只有很少的數據記錄，資料庫也可以很有用。 市場上有很多不同的資料庫管理系統。有些類似，有些相差很大。 基於關聯模型的關聯式資料庫管理系統是現實世界中最常用的一些。 很快，我將詳細介紹3個流行的開源關聯式資料庫管理系統：PostgreSQL、MySQL和SQLite。

了解網絡中的端口是什麼 在進行網絡請求時，你會使用一個IP地址或者主機名稱以及一個端口。 像這樣： http://localhost:8080 （端口8080） ftp://127.0.0.1:29392 （端口29392） 那麼，什麼是端口？ 它是一種技術，用於允許多個應用程序在同一台計算機上使用同一個協議進行響應。 例如，我們可以在機器上運行一個Web服務器。可以在不同的端口上啟動第二個Web服務器。 假設第一個運行在80端口，這是使用HTTP協議的Web服務器的默認端口。同樣的服務可以運行在除了端口80之外的任何其他端口。例如，常用的是端口8080或81。 HTTPS默認運行在端口443上。 每種協議都有不同的默認端口，但程序不必使用該端口。它們可以使用任何未使用的1至65535之間的端口（16位無符號= 2^16）。這是所有基於TCP和UDP的協議的默認端口列表。 在歷史上： FTP使用21 Telnet使用23 SMTP使用25 POP3使用110 ……雖然現在對於所有這些服務，你應該使用基於其他端口的安全對應服務。

這是什麼症候群？你有嗎？如何解決這種騙子的感覺？ 每個人遲早都會遭受到我們稱之為「騙子綜合症」的困擾。 也許你現在就有這種感覺，但你不知道它有一個特定的名字。 讓我來描述一些你可能在現實生活中遇到騙子綜合症的情況。 你是一名開發人員，沒有計算機科學學位，你覺得那些有計算機科學學位的人比你懂得多，所以你也應該去拿個學位，才能被稱為一個開發人員。 你在一個項目上工作，而你稱它為一個小項目，不是一個真正的項目，因為 - 你知道 - 它只是一個簡單的應用程序。 你經常貶低自己，對自己的能力缺乏信心。 你認為其他開發人員比你知道得多。 你認為總有一天會有人發現你不配擔任你的工作，因為你無法在一本隨機書上解決第423個編程面試測驗題。 你覺得自己不屬於「程序員俱樂部」。 你想開始寫博客，但你害怕別人的意見，甚至認為自己無法提供任何新內容，所以你連開始都不敢。 我之所以知道這些例子，是因為有人發送電子郵件給我，寫明了這些非常具體的問題。 現在有時候我認為解決的方法是告訴自己： 每個人都在背水一戰 沒有人真的知道自己在做什麼 你崇拜的人在公開場合喜歡顯得自信滿滿，但內心其實並非如此 從根本上講，事情永遠都會是這樣 但這仍然是一種自卑的表現。 對於這樣的思考，真正的回應是意識到自己從一開始走了多遠。 回頭看看。 有一天你甚至不知道如何打開電腦。甚至不知道什麼是代碼。你不知道你實際上可以創建程序並讓計算機按你的意願運行。 現在看著你自己。 你是自己最好的版本，但你絕對確信明天你會成為更好的版本。 你在進步，就像你的代碼一樣。 但你知道自己的手藝還不是完美的，而且我認為這種感覺可能永遠不會消失。畢竟，編程是如此廣泛的領域。 我們都知道那些非常自信的人，他們會因為別人不懂他們特別擅長的一個領域而貶低他人……我們不要成為那樣的人。 找到你的舒適點。 我相信，如果你開始更相信「你就是為這個而生的」，你會在自己的手藝上進步得更好。 解決一個錯誤的最困難的部分是識別這個錯誤。其餘的就變得容易起來了。

或者說，作為一名開發者，如何更滿足自己。同時也讓其他開發者有一個更充實的生活。 每當你在Reddit上對某些事物或某個人發表尖酸刻薄的評論時，一個開發者的水桶就會漏水。 每當你在一個庫的問題上發表一個問題，試圖推動你自己的議程，同時對那些花了無數時間來做好該項目的人不友好時，一個開發者的水桶就會漏水。 每當你發表一條刻薄的推特，垃圾另一個庫並支持另一個庫時，一個開發者的水桶就會漏水。 倒空水桶 所有在Reddit、Hacker News或任何大型網站上發佈過他們的作品的人都知道這個過程充滿了恐懼。害怕不夠好，害怕被評斷。即使你的作品很出色，有時候也會出現尖酸刻薄的評論。即使只有一條尖酸刻薄的評論，也能抵消數十條正面評論的力量。我不知道有哪個心理學理論可以解釋這一經歷，但就是這種感覺。 幾天前，我決定在Reddit上發佈我的一篇博客文章。有人在評論中說，我寫的這篇博客文章純粹是為了引人購買我寫得很差的電子書，對我精心撰寫了多天的博客文章進行了抨擊。 那條評論在我腦海中停留了整個下午，不是激勵我做得更好，而是讓我生氣。我的水桶在2秒鐘內就被倒空了，又花了一整天的時間才填滿。 那個人走開了，但什麼好事都沒有發生。對於所有參與其中的人來說，這是一件非常沒有生產力的事情。 一些建議：尤其是在書面文字中，要多注意接收方可能如何解釋它們。要友善，甚至比現實生活中更友善，因為表達文字時情感變得脫水。 如何填滿水桶 就像人們可以迅速倒空水桶一樣，他們也可以迅速將水桶再次填滿。這些時刻非常美妙。 我已經連續幾個月在寫博客時，有人給我發了一封電子郵件。他說我寫的一篇博客對他非常有幫助，幫他解決了一個問題。然後他繼續說：“你應該寫一本書。” 對於一個博主來說，這真是太好聽了。這意味著你的工作已經證明是有用的。有人甚至希望你寫一本書。猜猜怎麼著，我的水桶裡充滿了歡樂和動力，我決定當晚開始寫一本書。 我們如何做得更好 我們開發者每天都以空桶為開始，理想的情況是在一天結束時擁有滿滿的水桶。 我們的水桶已經漏掉了很多，因為我們認為自己總是落後於他人，我們有“冒牌者症候群”，我們可以輕易接觸到那些一天到晚在推特上吹噓他們正在建立的奇蹟的代碼巨星，或者每天發出一個YouTube螢幕錄影，或者像這是最自然的事情一樣直播。 很容易讓你覺得自己不夠好。但如果你對大多數人來說已經夠好，就不用在意少數人的看法。你無法取悅所有人。作為一名參與培訓的開發者，我通常為初學者準備內容。當人們通過發送快速感謝或分享一個推特來回饋時，這是很棒的。 我認為我們都處在同一條船上。當一些人試圖通過在世界上推出他們強烈的觀點來給人留下印象時，我們必須在與其他人溝通時特別注意。對於開發者來說，這一點尤其重要，因為我們幾乎完全通過文字進行溝通，如果你不非常小心地解釋一個句子的內容，很容易產生誤解。 專注填滿水桶 你是否曾經在Twitter或通過電子郵件向一個拯救了你10個工作小時的庫的開發者表示感謝？做這件事，並填滿那個人的水桶。 當你閱讀一篇博客文章，它幫助你解決了你卡住的問題時，花點時間感謝寫這篇文章的人。只需要發一封電子郵件或一條推特的一行文字，就能讓那個人的一天變得美好，並激勵他們將來寫更多的文章，因為他們覺得對世界有用。他們幫助了你，所以你也應該回報他們！ 你是否曾經在GitHub上提出一個問題，只是為了說好的話並提供建設性的反饋？做這件事，並填滿項目開發者的水桶。 開發者因為大家只是要求他們幫助建立自己的付費項目而感到疲憊。GitHub有一個"問題"標籤(這需要維護者的工作)和一個"合併請求"標籤(這更多的工作，因為維護者需要理解其他人寫的代碼，判斷是否值得添加，如果是這種情況還需要管理拒絕)。 但是卻沒有一個"感謝"標籤，讓人們可以讚美項目。人們只能給一個項目加星，但那意義不大。考慮多做一點事情，為那些做了非常辛苦工作的人做更多的事情，幫助他們填滿他們的水桶。 你是否曾經公開感謝過一位開源代碼的開發者？ 你是否曾經提交一個PR只是為了修復一個小錯誤，即使是在文檔中，只是為了確保明天不會再有人看到那個小毛病？做這件事，並填滿項目開發者的水桶。 有人像你一樣指出一個被忽視的錯別字，那個錯別字已經存在了幾個月了，這是很好的。其他人可能已經看過它，並立即降低了對項目質量的認識。充滿水桶比倒空水桶總是更加困難，但我認為它是值得的。 我們一起可以走很長的路。

了解 Electron，這是由 GitHub 開發的跨平台框架，用於建立創新且非常受歡迎的跨平台應用程式。 Electron 是一個使用 JS、HTML 和 CSS 來建立跨平台桌面應用程式的免費開源工具，由 GitHub 開發。 許多非常受歡迎且成功的應用程式都使用了 Electron，包括 VS Code、Slack、Discord 等等。 Electron 是一個宏大的專案，它革命性地改變了原生桌面應用程式的開發方式，使之成為可能以 JavaScript 為基礎的過程。 需要注意的是：在 Electron 出現之前，已經有其他工具可以用 JavaScript 來開發桌面應用程式，但 Electron 讓這種開發方式更加普及。 尤其是 Electron 可以用於建立跨平台的桌面應用程式。在此之前，沒有任何工具可以讓你在不同平台上運行相同的應用程式。 直到 2014 年，Electron 首次發布。 快速了解 Electron 的內部結構 Electron 基本上是將 Chromium 渲染庫和 Node.js 打包在一起（Chromium 是由 Google 開源的專案，用於構建 Chrome 瀏覽器）。 你既可以使用由 Chromium 提供的畫布，運行 V8 JavaScript 引擎，也可以使用任何 Node.js 套件並運行自己的 Node.js 代碼。 你可以把它想象成桌面版的 Node.js。它本身不提供任何 GUI 元素，而是讓你使用 HTML、CSS 和 JavaScript 來創建使用者界面。 Electron 旨在提供核心功能，同時保持速度快、體積小、精簡。這些核心功能可以滿足所有應用程式的需求。 你可以使用 Electron 創建哪些類型的應用程式 你可以創建各種不同類型的應用程式，包括：...

ES 模組是 ECMAScript 的模組化標準。儘管 Node.js 已經使用 CommonJS 標準多年，但瀏覽器從未擁有模組系統，因為關鍵的決策，如模組系統，必須首先由 ECMAScript 標準化，然後由瀏覽器實現。 這個標準化過程於 ES6 完成，瀏覽器開始實現這個標準，盡力保持一切保持協調，以相同的方式工作，現在 ES 模組在 Chrome、Safari、Edge 和 Firefox（版本 60 以後）中得到支援。 模組非常強大，因為它可以將各種功能封裝起來，並將這些功能作為庫暴露給其他 JavaScript 檔案。 ES 模組語法 導入模組的語法如下： import package from 'module-name' 而 CommonJS 使用： const package = require('module-name') 模組是一個使用 export 關鍵字將一個或多個值（物件、函式或變數）導出的 JavaScript 檔案。例如，這個模組導出了一個將字串轉換為大寫的函式： export default str => str.toUpperCase() 在這個例子中，模組定義了一個預設導出，所以可以是一個匿名函式。否則它需要一個名稱來區別於其他導出。 現在，任何其他的 JavaScript 模組可以透過導入它來使用 uppercase.js 提供的功能。 可以通過使用具有特殊屬性 type="module" 的 <script> 標籤將模組添加到 HTML 頁面中： <script type="module" src="index.js"></script> 注意：這種模組導入的行為類似於 defer 的腳本加載。請參見 使用 defer 和 async 高效加載 JavaScript...

學習 JWT 基礎知識及如何使用它 JSON Web Token 是一種用於創建應用程式的訪問令牌的標準。 它的運作方式是，伺服器生成一個令牌，用於驗證使用者身份，並將其發送給客戶端。 客戶端將在每個後續請求中將令牌發送回伺服器，因此伺服器知道該請求來自特定身份。 這種架構在現代 Web 應用程序中非常有效，在使用者驗證之後，我們會對 REST 或 GraphQL API 執行API請求。 誰在使用 JWT 呢？以 Google 為例，如果你使用 Google APIs，你會使用 JWT。 JWT 是被加密簽名的（但不會被加密，因此在將用戶數據存儲在 JWT 中時，使用 HTTPS 是必須的），所以當我們收到它時，我們可以確信它的可信度，沒有中間人可以截取並修改它，或者無效化它所保存的數據。 儘管如此，JWT 經常因過度使用而受到批評，尤其是在可以使用更少問題的解決方案時使用它們。 你需要對該主題形成自己的觀點。我並不主張某種技術優於其他，只是展示你在手邊擁有的所有機會和工具。 它們有什麼用途？主要用於 API 認證和服務器到服務器的授權。 JWT 令牌如何生成？ 使用 Node.js 你可以通過以下代碼生成令牌的第一部分: const header = { "alg": "HS256", "typ": "JWT" } const encodedHeader = Buffer.from(JSON.stringify(header)).toString('base64') 我們設定 HMAC SHA256 作為簽名算法（JWT 支持多種算法），然後我們從這個 JSON 編碼對象創建一個緩存，並且使用 base64 編碼它。 部分的結果是 eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9。 接下來我們添加 payload，我們可以使用任意類型的數據自定義它。有一些預留的鍵，包括 iss 和 exp，它們標識令牌的發行者和過期時間。...

這篇文章旨在通過我的80/20方法，幫助你開始使用 Remix。跳過冗餘的部分，學習核心內容。 Remix是一個基於React的新框架，已經達到了1.0版本，並以MIT許可證公開發布，這是我們都喜愛的許可證。 注意：昨天它還是贊助軟件，現在它是公開的和免費的 你知道Next.js嗎？或者 SvelteKit？嗯，Remix有點像它們，但是具有一些獨特的功能，使它成為一個有趣的選擇。但是它不支持靜態網站，因此它始終需要一個服務器。這使它對於一些用例很合適，對於另一些用例可能不太合適。 它適用於具有數據庫、動態數據、具有私有數據的用戶帳戶等用例，例如Rails、Django或Laravel應用程序。 在JavaScript世界中，它更像是RedwoodJS或Blitz.js的替代品，也就是它更多地用於構建應用程序，而不僅僅是網站。 是的，這看起來是一個很好的定位。 我們可以使用npx創建一個新的Remix項目，這樣我們就不需要先安裝任何東西或創建文件夾。 只需進入包含您的項目的文件夾（對我來說通常是dev或www），然後輸入以下命令： npx remix init 選擇要安裝的文件夾： 选择“Remix App Server”（內置服務器）選項： 选择JavaScript，或者如果您喜歡的話可以選擇TypeScript： 確保告訴安裝程序運行npm install以便為您設置一切： 然後運行cd <文件夾名>，然後運行npm run dev。 看到默認安裝的結果總是令人愉悅的： 生成此結果的代碼如下： 但是，我們實際上只對app文件夾感興趣，其他部分只是樣板/配置： 讓我們來分析一下。 src文件夾中有3個文件： entry.client.jsx entry.server.jsx root.jsx 這些文件用於設置整個網站的功能，包括所有頁面的HTML輸出。如果您觸摸它們，整個應用程序都會受到影響。這也是錯誤處理的地方，在Remix中，錯誤處理是一個一級方面，這很酷。 然後，我們有一個routes文件夾，其中有一個index.jsx文件，以及一個demos文件夾，其中包含一些示例應用程序。 讓我們從routes/index.jsx開始。 這是一個很長的React組件： 現在，此文件可以簡化成以下簡單的React組件： 如果您這樣做並保存文件，您將在應用程序中看到以下內容： 但是，此文件不僅僅輸出一些JSX，它還加載了服務器端的數據，通過loader()函數： json()是一個特殊的實用工具，可以輕鬆創建一個JSON端點，Remix在頁面加載時將調用它，以填充所需的數據。 在渲染組件的JSX時，我們必須導入並調用useLoaderData()： 文件還導出了一個meta()函數，用於設置頁面HTML頭部的元數據。 在Remix中，路由是發生“核心”功能的地方。這是可以理解的，因為Remix是由創建React Router的人創建的，所以路由器是應用程序的核心部分。 官方教程已經講解了如何創建自定義路由和處理表單，所以我現在不再進一步詳細介紹。 我建議您瀏覽一下教程，尤其是關於表單的部分。 為什麼呢？因為在React中，表單是一個很大的痛點，所以能夠看到這種非常簡單的方法來創建表單，而無需編寫大量的樣板代碼，這是很好的。 Remix最好的部分是子路由以及在前React時代Ember的outlets如何基本上複製了我們之前所做的事情，這是合理的，因為我記得Ryan Florence曾經活躍於Ember社區。 看到一個領域取得進展很棒，畢竟這個領域沒有出現任何大的老牌競爭者，Next.js基本上是樹上的大象，到目前為止，當我要編寫應用程序時，我一直首選它。 在適當的時候，我仍然會選擇它。我喜歡新技術，但是它也需要很長的時間才能成熟，有人編寫庫、教程等等。 但是競爭能夠促進創新，所以擁有一個不同於現有選擇的特殊選項總是很好。