Google Calendar 的秘密工程武器:克制
其原始的 API 為網路排程提供了可能,而其客戶端則是克制美學的傑作。
Google 日曆如何運作,以及我們作為工程師可以從中學到什麼。
架構
前端框架:無(!)。只有一些內部函式庫用於身份驗證和共享工具等功能。
前端樣式:CSS 類別名稱,由 JS 調用。
前端儲存:Cache Storage、IndexedDB(離線模式)、CDN(圖片和字型)。
API 儲存:Spanner DB。
外部 APIs:Google Meet、Google Contacts、Google Auth。
服務:心跳、事件處理、通知。
其他:一個內部編譯器,使 JS 下載和運行更快。
有趣的問題
當然,日曆是一個大型的 CRUD 應用程式。但別讓這個迷惑你——有許多艱鉅的技術問題必須解決。
日曆 API
- REST+JSON 自 2011 年起(最初為 REST+RSS 風格的 feed)
- 資料模型大量依賴 RFC 5545 iCalendar 重複字串(Microsoft 和 Apple 使用專有物件)
- 客戶端可以監看/訂閱以在事件變更時接收 webhook 通知
- 支援增量同步以提高速度...但也需要您自行處理過期和重新同步
- 使用配額和速率限制來減少效能問題
- 強大但原始。他們會給您足夠的資源來做您需要做的任何事情,但不會替您想出解決方案。
HTML 佈局
是的,構建 HTML 實際上可能很有趣!由於日曆檢視包含豐富的內容,如果元素沒有隔離,會出現重大效能問題。
以下是最重要的 HTML 層級:
- 網格:全天列、日期欄、定時事件、容器
- 預覽事件,無法鎖定到列/欄
- 拖曳層。這允許您將任務拖放到網格中
- 表單:浮動在網格上的事件旁邊,並展開為全螢幕對話框
- 提示訊息:用於確認訊息
前端演算法
每個日曆客戶端都有一些精妙的演算法
- 事件位置:每個事件 div 的長度、高度和座標(X、Y)。要計算這個,您需要考慮事件持續時間和檢視比例。
- 全天事件長度:寬度和 Y 座標,需要根據周圍事件進行調整。
- 重疊事件:當事件共享時間時如何調整事件。Gcal 的實作比 Outlook 的更複雜(Outlook 將每個事件減半)。偽代碼如下。
// 重疊事件邏輯 if start or end of targetEvent overlaps with any(events): if start and end of targetEvent = start and end of any(events): orderEventsAlphabeticallyByTitle() if start of targetEvent = start of any(events) and end != end of any(events): orderByDuration() //最長的事件在較短事件後面 if start or end of targetEvent != start or end of any(events): if targetEvent overlaps multiple events: targetEventGoesInFrontOfEvents() else: orderEventsByStart() //較早開始的事件在後面
\
請參閱 Compass 儲存庫以獲取這些演算法的完整實作。
服務
這些是外部工作引擎,使客戶端程式碼保持簡單和可靠
- 心跳服務——使 GCal 保持可靠並優雅地退回到離線模式
- 事件處理服務——發布/訂閱風格的事件,為客戶端提供 webhooks 支援。這允許其他應用程式在 GCal API 之上進行建構。
- 通知服務——協調事件前通知的時間。理論上客戶端可以單獨完成此操作,但可靠性會降低。
[
\
心得
建構全球規模的 CRUD 應用程式從架構圖看起來可能很直接,但這種簡單性仍然需要高水準的執行。
- API 可靠性:由於許多應用程式依賴與使用者的 GCal 進行雙向同步,API 需要簡單、可擴展且可靠。如果他們搞砸了,會破壞下游的一大批其他應用程式。
- 資料安全:日曆資料極為敏感。他們大量依賴基於範圍的角色來確保只有您授權的人/應用程式才能存取您的資料。
- 監控服務:健康檢查、日誌記錄和同步在幕後不間斷地進行。
考慮到規模需求,您可以透過簡單地不做某些事情來讓自己的生活更輕鬆。
- 您不需要使用流行的技術堆疊。想像一下,如果他們放下一切用 Angular 重寫應用程式。然後是 React。然後是 Svelte。然後是 NextJS。然後是 HTMX。所有這些都是在 Google 日曆發布之後出現的。GCal 選擇了 JS,切換到右車道,並以 64MPH 的速度巡航了幾十年。沒人在意。
- 您不需要在每個平台上發布。現在就打開 Google 日曆桌面應用程式。我等著。
- 您不需要跟上樣式趨勢。Bootstrap。Bulma。styled-components。Tailwind。CSS 類別名稱。
- 您不需要擁有最好的 UX。深色模式。節省空間的表單。#FFFFFF 淺色模式。全頁表單。
- 您不需要擁有最好的效能。他們在效能方面的 Lighthouse 得分是 31/100。
就像在生活中一樣,在交付產品時認識自己是值得的。
Google 日曆並不試圖成為行政助理每天用來安排 40 次會議的現代應用程式(那是 Vimcal 的用途)。
Google 日曆旨在成為一個簡單的應用程式,其 20 億使用者中的任何一個都可以在沒有手把手指導的情況下操作。它在無障礙性方面得分 88/100。UI 不會改變。它不會當機,如果當機了也有離線支援。
它就是能用。
這就足夠了。
要在您的收件匣中獲得這些深入分析,請訂閱我的電子報 Fullstack Engineer。
\
