L'Arme Secrète d'Ingénierie de Google Calendar : La Retenue

Son API primitive permet de programmer pour Internet, et son client est un chef-d'œuvre de retenue.

Comment fonctionne Google Calendar, et ce que nous pouvons en apprendre en tant qu'ingénieurs.

Architecture

---

Framework Frontend : Aucun (!). Juste quelques bibliothèques internes pour des éléments comme l'authentification et les utilitaires partagés.

Stylisation Frontend : Noms de classes CSS, invoqués par JS.

Stockage Frontend : Cache Storage, IndexedDB (mode hors ligne), CDN (images & polices).

Stockage API : Spanner DB.

APIs Externes : Google Meet, Google Contacts, Google Auth.

Services : heartbeat, événements, notifications.

Autre : Un compilateur interne qui rend le téléchargement et l'exécution de JS plus rapides.

Problèmes Intéressants

---

Certes, un calendrier est une grande application CRUD. Mais ne vous y trompez pas — il y avait de nombreux problèmes techniques exigeants à résoudre.

API Calendar

• REST+JSON depuis 2011 (à l'origine flux de style REST+RSS)
• Modèle de données s'appuie fortement sur les chaînes de récurrence iCalendar RFC 5545 (Microsoft & Apple utilisent des objets propriétaires)
• Les clients peuvent surveiller/s'abonner pour recevoir une notification webhook lorsque les événements changent
• Prend en charge les synchronisations incrémentielles pour la vitesse... mais nécessite également que vous gériez les expirations & re-synchronisations par vous-même
• Utilise des quotas & limites de débit pour réduire les problèmes de performance
• Puissant mais primitif. Ils vous donneront suffisamment pour faire tout ce dont vous avez besoin, mais ils ne le découvriront pas pour vous.

Mise en page HTML

Oui, structurer le HTML peut être intéressant ! Étant donné que les vues du calendrier sont riches en contenu, de gros problèmes de performance se produisent si les éléments ne sont pas isolés.

Voici les couches HTML les plus importantes :

• La grille : ligne toute la journée, colonnes de jour, événements programmés, conteneur
• L'aperçu de l'événement, qui ne peut pas être verrouillé sur une ligne/colonne
• La couche de glissement. Cela vous permet de faire glisser-déposer des tâches vers la grille
• Formulaires : flottants à côté des événements sur la grille et étendus dans une boîte de dialogue plein écran
• Toasts : Pour les messages de confirmation

Algorithmes Frontend

Chaque client de calendrier a quelques algorithmes intéressants

• Position de l'événement : la longueur, la hauteur et les coordonnées (X, Y) de chaque div d'événement. Pour calculer cela, vous devez tenir compte de la durée de l'événement et de l'échelle d'affichage.
• Longueurs des événements toute la journée : La largeur et les coordonnées Y, qui doivent être ajustées en fonction des événements environnants.
• Événements qui se chevauchent : comment ajuster les événements lorsqu'ils partagent des heures. L'implémentation de Gcal est plus sophistiquée comparée à celle d'Outlook (qui divise chaque événement par deux). Pseudo-code ci-dessous.

// logique des événements qui se chevauchent 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() //les événements les plus longs vont derrière les événements plus courts if start or end of targetEvent != start or end of any(events): if targetEvent overlaps multiple events: targetEventGoesInFrontOfEvents() else: orderEventsByStart() //les événements qui commencent plus tôt vont derrière

\

Voir le dépôt Compass pour notre implémentation complète de ces algorithmes.

Services

Ce sont les chevaux de bataille externes qui permettent au code client de rester simple et fiable

• Service Heartbeat — Permet à GCal d'être fiable et de basculer en mode hors ligne avec élégance
• Service d'événements — événements de style pub/sub qui alimentent les webhooks pour les clients. Cela permet à d'autres applications de s'appuyer sur l'API GCal.
• Service de notifications — coordonner le moment de vos notifications avant l'événement. Le client pourrait le faire seul en théorie, mais ce serait moins fiable.

[

\

Points à retenir

---

Construire une application CRUD à l'échelle mondiale peut sembler simple d'après le diagramme d'architecture, mais cette simplicité exige toujours un haut niveau d'exécution.

• Fiabilité de l'API : Puisque tant d'applications reposent sur la synchronisation bidirectionnelle avec le GCal d'un utilisateur, l'API doit être simple, extensible et fiable. S'ils se trompent, ils cassent une armée d'autres applications en aval.
• Sécurité des données : Les données de calendrier sont extrêmement sensibles. Ils s'appuient fortement sur des rôles basés sur la portée pour garantir que seules les personnes/applications que vous autorisez peuvent accéder à vos données.
• Services de surveillance : Les contrôles de santé, la journalisation et la synchronisation se produisent sans arrêt en coulisses.

Compte tenu des exigences d'échelle, vous pouvez vous faciliter la vie en ne faisant pas certaines choses.

• Vous n'avez pas besoin d'utiliser la pile tendance. Imaginez s'ils avaient tout abandonné pour réécrire leur application en Angular. Puis React. Puis Svelte. Puis NextJS. Puis HTMX. Tous sont arrivés après le lancement de Google Calendar. GCal a choisi JS, s'est mis sur la voie de droite et roule à 64 MPH depuis des décennies. Personne ne s'en soucie.
• Vous n'avez pas besoin de publier sur toutes les plateformes. Ouvrez l'application de bureau Google Calendar maintenant. J'attends.
• Vous n'avez pas besoin de suivre les tendances de style. Bootstrap. Bulma. styled-components. Tailwind. Noms de classes CSS.
• Vous n'avez pas besoin d'avoir la meilleure UX. Mode sombre. Formulaires qui économisent l'espace. Mode clair #FFFFFF. Formulaires pleine page.
• Vous n'avez pas besoin d'avoir les meilleures performances. Leur score Lighthouse sur les performances est de 31/100.

Tout comme dans la vie, il est payant de se connaître soi-même lors de l'expédition d'un produit.

Google Calendar n'essaie pas d'être l'application moderne que les assistants de direction utilisent pour planifier 40 réunions par jour (c'est à cela que sert Vimcal).

Google Calendar vise à être une application simple que n'importe lequel de ses 2 milliards d'utilisateurs peut utiliser sans assistance. Il obtient 88/100 en accessibilité. L'interface utilisateur ne change pas. Elle ne tombe pas en panne, et elle a un support hors ligne si c'est le cas.

Ça fonctionne tout simplement.

C'est largement suffisant.

---

Pour recevoir ces analyses approfondies dans votre boîte de réception, abonnez-vous à ma newsletter, Fullstack Engineer.

\