Tajna broń inżynieryjna Kalendarza Google: Powściągliwość

Jego prymitywne API umożliwia planowanie w internecie, a jego klient to arcydzieło powściągliwości.

Jak działa Google Calendar i czego możemy się nauczyć jako inżynierowie.

Architektura

---

Framework frontend: Żaden (!). Tylko kilka wewnętrznych bibliotek do rzeczy takich jak uwierzytelnianie i wspólne narzędzia.

Stylowanie frontend: Nazwy klas CSS, wywoływane przez JS.

Przechowywanie frontend: Cache Storage, IndexedDB (tryb offline), CDN (obrazy i czcionki).

Przechowywanie API: Spanner DB.

Zewnętrzne API: Google Meet, Google Contacts, Google Auth.

Usługi: heartbeat, eventing, powiadomienia.

Inne: Wewnętrzny kompilator, który sprawia, że JS pobiera się i działa szybciej.

Interesujące problemy

---

Jasne, kalendarz to jedna wielka aplikacja CRUD. Ale nie daj się zwieść — było wiele wymagających problemów technicznych do rozwiązania.

Calendar API

• REST+JSON od 2011 roku (pierwotnie REST+kanał w stylu RSS)
• Model danych w dużym stopniu opiera się na ciągach powtórzeń RFC 5545 iCalendar (Microsoft i Apple używają zastrzeżonych obiektów)
• Klienci mogą obserwować/subskrybować, aby otrzymywać powiadomienia webhook, gdy zdarzenia się zmieniają
• Obsługuje synchronizacje przyrostowe dla szybkości... ale wymaga również samodzielnej obsługi wygasania i ponownych synchronizacji
• Używa limitów i ograniczeń szybkości w celu zmniejszenia problemów z wydajnością
• Potężne, ale prymitywne. Dadzą ci wystarczająco dużo, aby zrobić cokolwiek potrzebujesz, ale nie rozwiążą tego za ciebie.

Układ HTML

Tak, strukturyzowanie HTML może być naprawdę interesujące! Ponieważ widoki kalendarza są bogate w treść, duże problemy z wydajnością występują, jeśli elementy nie są izolowane.

Oto najważniejsze warstwy HTML:

• Siatka: wiersz całodniowy, kolumny dni, zaplanowane wydarzenia, kontener
• Podgląd wydarzenia, którego nie można zablokować do wiersza/kolumny
• Warstwa przeciągania. Pozwala to na przeciąganie i upuszczanie zadań do siatki
• Formularze: pływające obok wydarzeń na siatce i rozwijane do pełnoekranowego okna dialogowego
• Powiadomienia: Dla wiadomości potwierdzających

Algorytmy Frontend

Każdy klient kalendarza ma kilka soczystych algorytmów

• Pozycja wydarzenia: długość, wysokość i współrzędne (X, Y) każdego diva wydarzenia. Aby to obliczyć, musisz uwzględnić czas trwania wydarzenia i skalę widoku.
• Długości wydarzeń całodniowych: Szerokość i współrzędne Y, które muszą być dostosowane na podstawie otaczających wydarzeń.
• Nakładające się wydarzenia: jak dostosować wydarzenia, gdy dzielą czas. Implementacja GCal jest bardziej zaawansowana w porównaniu do Outlooka (który dzieli każde wydarzenie na pół). Pseudokod poniżej.

// logika nakładających się wydarzeń 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() //najdłuższe wydarzenia idą za krótszymi wydarzeniami if start or end of targetEvent != start or end of any(events): if targetEvent overlaps multiple events: targetEventGoesInFrontOfEvents() else: orderEventsByStart() //wydarzenia, które zaczynają się wcześniej, idą z tyłu

\

Zobacz repozytorium Compass, aby zobaczyć naszą pełną implementację tych algorytmów.

Usługi

To są zewnętrzne robocze konie, które pozwalają kodowi klienta pozostać prostym i niezawodnym

• Usługa Heartbeat — Pozwala GCal być niezawodnym i płynnie przejść do trybu offline
• Usługa Eventing — zdarzenia w stylu pub/sub, które zasilają webhooki dla klientów. Pozwala to innym aplikacjom budować na GCal API.
• Usługa powiadomień — koordynowanie czasu powiadomień przed wydarzeniem. Klient mógłby to teoretycznie robić sam, ale byłoby to mniej niezawodne.

[

\

Wnioski

---

Budowanie aplikacji CRUD w skali globalnej może wyglądać prosto z diagramu architektury, ale ta prostota nadal wymaga wysokiego poziomu wykonania.

• Niezawodność API: Ponieważ tak wiele aplikacji polega na dwukierunkowej synchronizacji z GCal użytkownika, API musi być proste, rozszerzalne i niezawodne. Jeśli się pomylą, zepsują armię innych aplikacji niżej w łańcuchu.
• Bezpieczeństwo danych: Dane kalendarza są niezwykle wrażliwe. W dużym stopniu polegają na rolach opartych na zakresie, aby zapewnić, że tylko osoby/aplikacje, które autoryzujesz, mogą uzyskać dostęp do twoich danych.
• Monitorowanie usług: Kontrole stanu, logowanie i synchronizacja odbywają się non-stop za kulisami.

Biorąc pod uwagę wymagania skali, możesz ułatwić sobie życie po prostu nie robiąc rzeczy.

• Nie musisz używać modnego stosu. Wyobraź sobie, gdyby porzucili wszystko, aby przepisać swoją aplikację w Angularze. Potem React. Potem Svelte. Potem NextJS. Potem HTMX. Wszystkie z nich pojawiły się po uruchomieniu Google Calendar. GCal wybrał JS, przejechał na prawy pas i jedzie z prędkością 64 MPH od dziesięcioleci. Nikt się tym nie przejmuje.
• Nie musisz publikować na każdej platformie. Otwórz teraz aplikację desktopową Google Calendar. Poczekam.
• Nie musisz nadążać za trendami w stylowaniu. Bootstrap. Bulma. styled-components. Tailwind. Nazwy klas CSS.
• Nie musisz mieć najlepszego UX. Tryb ciemny. Formularze oszczędzające miejsce. #FFFFFF tryb jasny. Formularze na całą stronę.
• Nie musisz mieć najlepszej wydajności. Ich wynik lighthouse w wydajności to 31/100.

Podobnie jak w życiu, opłaca się znać siebie, gdy wysyłasz produkt.

Google Calendar nie próbuje być nowoczesną aplikacją, którą asystenci wykonawczy używają do planowania 40 spotkań dziennie (To jest do czego służy Vimcal).

Google Calendar ma być prostą aplikacją, z której każdy z jego 2 miliardów użytkowników może korzystać bez wsparcia. Zdobywa 88/100 w dostępności. Interfejs się nie zmienia. Nie zawiesza się, a jeśli tak, ma wsparcie offline.

Po prostu działa.

To wystarczy.

---

Aby otrzymywać te dogłębne analizy w swojej skrzynce odbiorczej, zapisz się do mojego newslettera, Fullstack Engineer.

\