歡迎閱讀全端開發雙週報第 21 期。在進到本期的內容前,跟大家說聲農曆新年快樂!上週因為農曆新年關係,我們將原本排定的雙週報,往後延了一週發布。在農曆年好好休息後,讓我們一起重拾技術與職涯的懷抱吧。
在開頭再次感謝讀者們的支持,目前 E+ 成長計畫已經有超過兩百五十位讀者參與,今天也是早鳥階段的最後一天,在今天結束前使用 EARLY80,都可享有終身 8 折訂閱優惠,期待在 E+ 的專屬 Discord 社群中見到大家 (E+ 的介紹頁面可以點這看到)。
講完 E+ 後,讓我們進到本週的雙週報主題吧~
[前端] 從前端工程角度聊付費牆的技術實現
最近科技媒體界的一個大新聞,是 TechCrunch 收掉了訂閱服務。早在這之前,Business Insider 等媒體也關閉付費牆 (paywall)。 身為一個聊技術的電子報,這邊不從商業面討論這個網路時代許多媒體常用的商業模式,而是從技術面來看看相關的實作。
所謂的付費牆,是指你需要付費訂閱該媒體,才可以閱讀完整的內容;如果沒有訂閱,只能看到少部分的內容,然後會有一個牆擋著,要你訂閱。今天聊聊從前端的角度破解付費牆。
特別注意,這篇文章僅是從前端工程的角度討論,是技術分享,藉由了解如何實現,來更清楚不同的技術概念。大家理解完雖然會獲得能破解付費牆的技術能力,但去破解就算不違法也不道德。
好的內容需要大家付費支持,好媒體才能永續經營。所以假如真的喜歡某個內容,就付費支持吧 (或可以付費訂閱 E+ 來支持 ExplainThis)~
從瀏覽器存儲角度看付費牆
首先來聊一種常見的付費牆,是一開始會給你免費的額度,例如可以免費看三篇,然後當超過額度後,就要訂閱後才能繼續閱讀。這種機制第一個要問的是,該網站要怎麼知道你看了多少篇?
這個關鍵問題背後意味著,有一個存儲機制,在記錄你讀了多少篇文。而在瀏覽器中,有幾種不同的存儲機制。我們先前分別在 《請描述 cookie, sessionStorage 和 localStorage 的差異》以及 《你知道 localStorage 但你知道 IndexedDB 嗎?》 等文章介紹過。一般來說,這種記下你已經讀過幾篇的,因為量比較小,且是每次發送請求時會確認,所以會選擇存在 cookie。
以 Harvard Business Review 哈佛商業評論來說,只要在瀏覽器,開啟開發者工具,然後在 Application 分頁當中找到 Cookie,然後把 https://hbr.org 相關的 Cookie 清除掉,就會發現這個計數器被清掉,然後付費牆就沒有再出現了。
從伺服器端渲染 (SSR) 角度來看付費牆
先前在《什麼是 SPA (Single-Page Application)?有什麼優點和缺點?》一文中有談到,假如要讓網頁的 SEO 好,現今比較常見的做法,是透過伺服器端渲染 (SSR) 來達成。
所謂的伺服器端渲染,是指先把網頁在伺服器 (server) 渲然完後,把完整的 HTML 檔案傳送到客戶端,然後客戶端就可以直接呈現。在最開始送 HTML 到前端時,JavaScript 還沒有送過來。而要有付費牆,需要有寫在 JavaScript 的邏輯才能完成。
換句話說,如果沒有 JavaScript 的邏輯,付費牆就沒辦法出來。在網頁中,一樣可以開啟開發者工具,然後用 Windows 系統用 Control+Shift+P、Mac 系統用 Command+Shift+P 打開搜尋欄,然後搜尋 JavaScript,接著點擊 disable JavaScript。
這時就會看到,因為沒有 JavaScript,網頁就只有 HTML 跟 CSS,所以會有內容,但沒有付費牆。
從快取 (cache) 的角度來看付費牆
最後來談談從快取的角度怎麼突破付費牆。在這之前需要瞭解一些技術概念。搜尋引擎在做的事情基本上是爬蟲,上面談到 SSR 的 SEO 會比較好,是因為 SSR 會先把內容渲染好才傳到客戶端,所以搜尋引擎爬得到內容。
接著聊另個技術概念,是很多人都知道的快取 (cache),在 《系統設計五大心法:水平擴張、快取、非同步、避免單點故障、監控》我們有比較詳細談,推薦不熟的讀者可以讀下。
許多瀏覽器都會快取爬蟲爬下的內容,這能在網頁載入不穩定時,仍呈現內容給瀏覽網頁的人。但 Google 的搜尋引擎在今年把這個功能拿掉 連結,因為現今的網頁技術比較成熟,不穩的狀況被大幅改善。但是微軟的 Bing 還保有這功能。
所以你可以在搜尋結果點擊快取,然後看到過去爬蟲爬下的內容。因為希望讓內容被爬,讓 SEO 變好,付費牆通常不會擋下爬蟲。所以從快取的頁面,通常能看到完整的內容。
以上,希望透過付費牆的解說,讓大家對於瀏覽器存儲機制、伺服器端渲然,以及快取 (cache) 的概念都有更熟悉。然後再次聲明,這篇的目的是跟大家分享前端的技術;對於優質的內容,請務必付費支持 (想持續在前端、後端、工程師職涯的路上成長,可以付費訂閱 E+ ,獲得好內容與社群,同時支持 ExplainThis 的內容創作)。
[後端] 淺談限流器 (Rate Limiter)
過去一周在推特上,看許多人在討論 Upstash 的開源限流器 (Rate Limiter) 套件 GitHub 連結,讓人可以非常輕鬆地做限流 連結。所以決定也來讀這個限流器原始碼,我們有根據 Upstash 的原始碼,改寫出一題面試題,是要實作限流器的快取 (cache)。有興趣的讀者可以參考這篇 連結(備註:這題是限流器的快取,不是限流器本身)
這週的雙週報,延伸限流器的主題,來聊一下限流器是什麼,以及常見的限流策略。先前 CI/CD 的下篇我們會順延未來的雙週報聊。
限流器 (Rate Limiter) 顧名思義,是用來限制流量的。在全端的世界中,限流器可能是用來限制來自客戶端的請求,或者服務對其他服務發送請求時,也可以用限流器來限流。舉例來說,可以從 IP 的角度,限制每個 IP 每天的請求數;或者以使用者為維度,來限每個使用者在某段時間的請求數量。
限流器的好處,一來可以阻擋像是 DoS (Denial of Service) 攻擊,避免伺服器過載;二來可以降低成本,特別是如果你有用第三方 API,流量大起來帳單費也會變很可觀。
限流器一般多半不會在客戶端實作,因為請求在客戶端比較容易被偽造;所以一般可能會放在伺服器端,或者是放在 API Gateway;或者像是 Upstash 的這個開源套件,是放在 Edge 上。
限流有幾種策略,一般常見的做法包含
令牌桶(Token Bucket)
漏桶(Leaky Bucket)
固定窗口(Fixed Window)
滑動窗口(Sliding Window)
而 Upstash 的開源限流器,提供了令牌桶、固定窗口,以及滑動窗口三種策略,並分析了他們的優缺點。
首先來談令牌桶(Token Bucket),可以想像一個裝滿 {maxTokens}
個令牌的水桶,它會以每隔 {interval}
時間會以 {refillRate}
速率,自動補充相對應的令牌。每次請求都會從水桶中取走一個令牌,如果水桶中沒有令牌,則請求會被拒絕。
這做法的優點在於能夠讓突發性的請求高峰變平滑,讓系統可以用穩定的速率處理請求。如果將 maxTokens
設置得比 refillRate
更高,可以允許系統在一開始承擔更高的請求。而缺點則是運算成本比較高。
固定窗口 (Fixed Window) 的做法是,將時間劃分為固定窗口。例如,每個窗口為 10 秒。當有新的請求進入時,將使用當前時間來判斷所屬窗口,並增加一個計數器。如果計數器超過設定的限制,該請求就會被拒絕。
固定窗口的優點包含,在數據量和計算成本上節省、較新的請求不會因為過去的高流量突發而延遲。但也有一些缺點,例如可能會導致窗口邊界處的高流量突發,以及如果許多用戶試圖在一個新窗口開始時,訪問你的伺服器,就會引發請求堵塞。
而滑動窗口 (Sliding Window),是建立在固定窗口的基礎上,但與固定窗口不同的是,它採用了滑動的窗口機制。舉例來說,我們設定每分鐘 10 個請求的限流。如同固定窗口的作法,我們將時間切分為 1 分鐘的區間。第一個窗口將從 00:00:00 到 00:01:00。假設當前時間為 00:01:15,並且在第一個窗口中收到了 4 個請求,在當前窗口中收到了 5 個請求。用來判斷請求是否該通過的近似計算方法如下:
limit = 10
// 4 個請求來自舊的窗口,把它們放入權重,同時加上當前的窗口
rate = 4 * ((60 - 15) / 60) + 5 = 8
return rate < limit // True 代表我們會讓請求通過
滑動窗口的優點在於,解決了固定窗口演算法中因窗口邊界導致的問題。但同時會造成存儲和運算耗費更大。並且因為這做法,假設先前窗口中的請求流是均勻的,因此雖然滑動,實際上是近似而非完全準確 (但在大多數情況下這並不會構成大問題)。
[職涯] 年後換工作,該如何有效提高通過面試的成功率
上一期雙週報有談到如何有效提高「獲得」面試的成功率,這一期延續這話題,來談如何有效提高「通過」面試的成功率。
我們一樣會從訊號 (signal) 的角度切入。這時你或許會問,面試時該展現什麼訊號呢? 要回答這個問題,我們要從面試官的角度想,面試官想要看到什麼訊號?
很多人直觀會認為,對工程師來講,在面試中要展現有實力,解出技術問題是最直接的訊號;當然這非常重要,但是多半面試官不僅會想找這個訊號,還有其他訊號。
其中與技術能力幾乎同等重要的,是溝通能力的訊號。畢竟面試官是要找未來加入公司,甚至可能是加入團隊的同事。如果找來的同事,在溝通上有問題,可以預期未來一起共事會有額外的成本。
很多人在面試有順利解出程式問題,但最終沒被錄取,很有可能是因為在溝通的維度上,沒有讓面試官可以記錄的特點。所以綜合下來沒辦法被錄取。
這時你可能會問,具體來說,什麼樣叫做溝通能力好,什麼樣不是? 這邊用 Google 的技術面試評標準為例 (其他間公司的大同小異),來看看區別在哪。
4 Points: Throughout the interview, the candidate communicated with perfect clarity. The interviewer had no difficulty understanding the candidate's thought process, the trade-offs of the candidate's different approaches, and how the candidate approached the problem. The candidate's answers were well-organized and succinct. 面試過程中,候選人以完美清晰的方式進行溝通。面試官不會無法理解候選人的思考過程、不同方法的取捨,以及候選人如何處理問題。候選人的回答組織良好且簡潔。
3 Points: The candidate communicated with their interviewer adequately throughout the interview. The interviewer may have needed to ask the candidate follow-up questions about their thought process, the approach, etc. 面試過程中,候選人與面試官進行了充分的溝通。面試官可能需要就候選人的思考過程、方法等方面提出跟進問題。
2 Points: The candidate did not communicate very well or clearly throughout the interview. The interviewer may have had difficulty following the candidate's thought process. The candidate may have been disorganized in their answer or jumped right into coding without properly explaining themselves. 面試過程中,候選人的溝通不夠清晰。面試官可能難以跟上候選人的思路。候選人的答案可能缺乏條理,或者在沒有適當解釋的情況下直接跳下去寫程式。
1 Point: The candidate could not communicate with any clarity. The interviewer had extreme difficulty following or understanding the candidate's thought process or approach. The candidate may have stayed silent for much of the interview, even when directly addressed by the interviewer. 候選人的溝通非常不清晰。面試官非常難以理解候選人的思路。候選人在整個面試過程中,長時間保持沉默,即使面試官直接提問,回答也簡短或沈默。
推薦大家平常在練習面試時,可以自己用這個評分標準,來評斷自己在溝通的面向,是否有做好。此外,如果有訂閱 E+ 的讀者,在 E+ 的專屬內容中,有一篇《白板題面試 — 如何持續溝通與互動? (含模板句型)》 詳細分析在一場技術面試中的各個環節,可以如何讓面試官覺得「這個候選人在溝通上做得很好」,推薦在準備面試時也可以先詳讀那篇。
[本期推薦]
在社群呼聲很高的 Zed 最近宣布開源,這款 IDE 以 Rust 來寫,效能很好。我們實測後,覺得功能目前有限,但未來值得期待 [連結]。這篇談 Zed 如何把搜尋從 1 秒優化到 4 毫秒的文章,很值得一讀 [連結]
OpenAI 推出了文字轉影像的模型 Sora,其成果在社群掀起一波討論。去年在文字生成上帶給世界的震撼,今年在影像生成上再度重現 [連結]
jQuery 發布 4.0 beta,在社群引起一陣討論 連結。 Million.js 發佈了 v3.0.0,這個以效能好著稱的 JavaScript 框架,又有了新的突破 [連結],同時 React 發出最新的部落格文,React Compiler 已經被 Instagram 用在生產環境,而 React 19 也不遠了 [連結]
最近蘋果的 Vision Pro 推出後,對於 Web 的發展多了很多想像,這個 Podast 節目談到這主題,推薦一聽 [連結]
Arc 瀏覽器最近推出了 Arc Search,雖然功能還很陽春,但可以感受到 Arc 挑戰重新定義瀏覽器的企圖心 [連結] ,另外很推薦 Arc 團隊最近分享的他們的願景影片,不是很制式的風格,讓特別期待他們未來的發展 [連結]
Clerk 最近的事故檢討 (post mortem),寫得很精彩,感覺這問題可以成為資深工程師的
auth
主題的面試考題,推薦大家一讀 [連結]Svelte 創作者 Rich Harris 最近接受訪談,聊 Web 的發展,也談如何把前端框架做得更好 [連結]