Google Calendarの秘密の工学的武器：制約

そのプリミティブなAPIはインターネット上でのスケジューリングを可能にし、そのクライアントは抑制の傑作です。

Google Calendarの仕組みと、エンジニアとして学べること。

アーキテクチャ

フロントエンドフレームワーク: なし(!)。認証や共有ユーティリティなどのための社内ライブラリがいくつかあるだけ。

フロントエンドスタイリング: CSSクラス名、JSで呼び出し。

フロントエンドストレージ: Cache Storage、IndexedDB(オフラインモード)、CDN(画像とフォント)。

APIストレージ: Spanner DB。

外部API: Google Meet、Google Contacts、Google Auth。

サービス: heartbeat、eventing、notifications。

その他: JSのダウンロードと実行を高速化する社内コンパイラ。

興味深い課題

確かに、カレンダーは一つの大きなCRUDアプリです。しかし、それに惑わされてはいけません。解決しなければならない多くの厳しい技術的課題がありました。

Calendar API

• REST+JSON 2011年から(当初はREST+RSS形式のフィード)
• データモデルはRFC 5545 iCalendar繰り返し文字列に大きく依存(MicrosoftとAppleは独自オブジェクトを使用)
• クライアントは監視/購読してイベント変更時にWebhook通知を受け取ることができる
• 速度のために増分同期をサポート...ただし有効期限と再同期を自分で処理する必要がある
• パフォーマンス問題を軽減するためにクォータとレート制限を使用
• 強力でありながらプリミティブ。必要なことをするのに十分なものを提供しますが、解決策は自分で考える必要があります。

HTMLレイアウト

はい、HTMLの構造化は実際に興味深いものです!カレンダー表示はコンテンツが豊富なため、要素が分離されていないと大きなパフォーマンス問題が発生します。

最も重要なHTMLレイヤー:

• グリッド: 終日行、日列、時刻付きイベント、コンテナ
• プレビューイベント、行/列に固定できない
• ドラッグレイヤー。これによりタスクをグリッドにDNDできる
• フォーム: グリッド上のイベントの横にフローティングし、全画面ダイアログに展開
• トースト: 確認メッセージ用

フロントエンドアルゴリズム

各カレンダークライアントにはいくつかの重要なアルゴリズムがあります

• イベント位置: 各イベントdivの長さ、高さ、座標(X、Y)。これを計算するには、イベント期間と表示スケールを考慮する必要があります。
• 終日イベントの長さ: 幅とY座標、周囲のイベントに基づいて調整する必要がある。
• 重複するイベント: 時間を共有するときにイベントを調整する方法。Gcalの実装はOutlookの実装(各イベントを半分にする)と比較してより洗練されています。以下は疑似コード。

// overlapping events logic 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() //longest events go behind shorter events if start or end of targetEvent != start or end of any(events): if targetEvent overlaps multiple events: targetEventGoesInFrontOfEvents() else: orderEventsByStart() //events that start earlier go behind

\

これらのアルゴリズムの完全な実装については、Compassリポジトリを参照してください。

サービス

これらは、クライアントコードをシンプルで信頼性の高い状態に保つ外部の働き者です

• Heartbeatサービス — GCalを信頼性の高いものにし、優雅にオフラインモードにフォールバックできるようにする
• Eventingサービス — クライアント向けWebhookを動かすpub/subスタイルのイベント。これにより、他のアプリがGCal APIの上に構築できます。
• Notificationsサービス — イベント前通知のタイミングを調整。理論的にはクライアントだけでもできますが、信頼性が低くなります。

[

\

まとめ

グローバル規模のCRUDアプリの構築は、アーキテクチャ図からは単純に見えるかもしれませんが、そのシンプルさには依然として高いレベルの実行が求められます。

• API信頼性: 多くのアプリがユーザーのGCalとの双方向同期に依存しているため、APIはシンプルで拡張可能で信頼性が高い必要があります。彼らが失敗すると、下流の他のアプリの軍団を壊してしまいます。
• データセキュリティ: カレンダーデータは非常に機密性が高いです。承認した人/アプリだけがデータにアクセスできるように、スコープベースのロールに大きく依存しています。
• 監視サービス: ヘルスチェック、ログ記録、同期が裏で絶え間なく行われています。

規模の要求を考えると、単に何もしないことで自分の生活を楽にすることができます。

• トレンドのスタックを使う必要はない。彼らがすべてを捨ててAngularでアプリを書き直したと想像してみてください。次にReact。次にSvelete。次にNextJS。次にHTMX。これらはすべてGoogle Calendarがリリースされた後に登場しました。GCalはJSを選び、右車線に移動し、何十年も時速64マイルで巡航しています。誰も気にしません。
• すべてのプラットフォームで公開する必要はない。今すぐGoogle Calendarデスクトップアプリを開いてください。待ちます。
• スタイリングのトレンドに追いつく必要はない。Bootstrap。Bulma。styled-components。Tailwind。CSSクラス名。
• 最高のUXを持つ必要はない。ダークモード。スペースを節約するフォーム。#FFFFFFライトモード。フルページフォーム。
• 最高のパフォーマンスを持つ必要はない。パフォーマンスのLighthouseスコアは31/100です。

人生と同じように、製品をリリースする際には自分自身を知ることが重要です。

Google Calendarは、エグゼクティブアシスタントが1日に40の会議をスケジュールするために使用する最新のアプリになろうとはしていません(それはVimcalの役割です)。

Google Calendarは、20億人のユーザーの誰もが手取り足取り教えなくても操作できるシンプルなアプリを目指しています。アクセシビリティのスコアは88/100です。UIは変わりません。ダウンしませんし、もしダウンしてもオフラインサポートがあります。

ただ動くのです。

それで十分です。

これらの詳細な分析をメールで受け取るには、私のニュースレター「Fullstack Engineer」を購読してください。

\