API-ul său primitiv permite programarea pentru internet, iar clientul său este o capodoperă de moderație.
Cum funcționează Google Calendar și ce putem învăța din el ca ingineri.
Arhitectură
Framework frontend: Niciuna (!). Doar câteva biblioteci interne pentru lucruri precum autentificarea și utilitățile partajate.
Stilizare Frontend: Nume de clase CSS, invocate prin JS.
Stocare Frontend: Cache Storage, IndexedDB (mod offline), CDN (imagini & fonturi).
Stocare API: Spanner DB.
API-uri Externe: Google Meet, Google Contacts, Google Auth.
Servicii: heartbeat, eventing, notificări.
Altele: Un compilator intern care face ca JS-ul să se descarce și să ruleze mai rapid.
Probleme Interesante
Sigur, un calendar este o aplicație CRUD mare. Dar nu te lăsa păcălit — au existat numeroase probleme tehnice dificile care trebuiau rezolvate.
Calendar API
- REST+JSON din 2011 (inițial REST+RSS-style feed)
- Modelul de date se bazează puternic pe șirurile de recurență RFC 5545 iCalendar (Microsoft & Apple folosesc obiecte proprietare)
- Clienții pot urmări/abona pentru a primi o notificare webhook când se schimbă evenimentele
- Suportă sincronizări incrementale pentru viteză... dar necesită și gestionarea propriilor expirări și re-sincronizări
- Folosește cote & limite de rată pentru a reduce problemele de performanță
- Puternic dar primitiv. Îți vor oferi suficient pentru a face orice ai nevoie, dar nu vor rezolva pentru tine.
Layout HTML
Da, structurarea HTML poate fi de fapt interesantă! Deoarece vizualizările calendarului sunt bogate în conținut, apar probleme majore de performanță dacă elementele nu sunt izolate.
Iată cele mai importante straturi HTML:
- Grila: rând pentru întreaga zi, coloane pentru zile, evenimente programate, container
- Evenimentul de previzualizare, care nu poate fi blocat pe un rând/coloană
- Stratul de tragere. Aceasta îți permite să folosești DND pentru sarcini în grilă
- Formulare: plutitoare lângă evenimente pe grilă și extinse într-un dialog pe ecran complet
- Toast-uri: Pentru mesaje de confirmare
Algoritmi Frontend
Fiecare client de calendar are câțiva algoritmi interesanți
- Poziția evenimentului: lungimea, înălțimea și coordonatele (X, Y) ale fiecărui div de eveniment. Pentru a calcula acest lucru, trebuie să ții cont de durata evenimentului și scala de vizualizare.
- Lungimile evenimentelor de o zi întreagă: Lățimea și coordonatele Y, care trebuie ajustate pe baza evenimentelor înconjurătoare.
- Evenimente suprapuse: cum să ajustezi evenimentele când împart orele. Implementarea Gcal este mai sofisticată comparativ cu cea a Outlook (care înjumătățește fiecare eveniment). Pseudo-cod mai jos.
// 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
\
Vezi repo-ul Compass pentru implementarea completă a acestor algoritmi.
Servicii
Acestea sunt caii de bătaie externi care permit codului client să rămână simplu și fiabil
- Serviciu Heartbeat — Permite GCal să fie fiabil și să revină la modul offline cu grație
- Serviciu Eventing — evenimente în stil pub/sub care alimentează webhook-urile pentru clienți. Acest lucru permite altor aplicații să construiască pe API-ul GCal.
- Serviciu de Notificări — coordonarea momentului notificărilor tale pre-eveniment. Clientul ar putea face asta singur în teorie, dar ar fi mai puțin fiabil.
[
\
Concluzii
Construirea unei aplicații CRUD la scară globală ar putea părea directă din diagrama de arhitectură, dar acea simplitate încă cere un nivel înalt de execuție.
- Fiabilitatea API: Deoarece atât de multe aplicații se bazează pe sincronizarea bidirecțională cu GCal-ul unui utilizator, API-ul trebuie să fie simplu, extensibil și fiabil. Dacă greșesc, strică o armată de alte aplicații în aval.
- Securitatea datelor: Datele calendarului sunt extrem de sensibile. Se bazează puternic pe roluri bazate pe domeniu pentru a asigura că doar persoanele/aplicațiile pe care le autorizezi pot accesa datele tale.
- Servicii de monitorizare: Verificări de sănătate, înregistrare și sincronizare se întâmplă non-stop în culise.
Date fiind cerințele de scară, poți să îți faci viața mai ușoară pur și simplu prin a nu face lucruri.
- Nu trebuie să folosești stack-ul la modă. Imaginează-ți dacă renunțau la tot pentru a rescrie aplicația în Angular. Apoi React. Apoi Svelte. Apoi NextJS. Apoi HTMX. Toate acestea au apărut după ce Google Calendar a fost lansat. GCal a ales JS, s-a mutat în banda dreaptă și a mers cu 103 km/h timp de decenii. Nimănui nu îi pasă.
- Nu trebuie să publici pe fiecare platformă. Deschide aplicația desktop Google Calendar chiar acum. Aștept.
- Nu trebuie să ții pasul cu tendințele de stilizare. Bootstrap. Bulma. styled-components. Tailwind. Nume de clase CSS.
- Nu trebuie să ai cel mai bun UX. Mod întunecat. Formulare care economisesc spațiu. #FFFFFF mod luminos. Formulare pe pagină întreagă.
- Nu trebuie să ai cea mai bună performanță. Scorul lor lighthouse pentru Performanță este 31/100.
La fel ca în viață, merită să te cunoști pe tine însuți când lansezi un produs.
Google Calendar nu încearcă să fie aplicația modernă pe care asistenții executivi o folosesc pentru a programa 40 de întâlniri pe zi (Asta face Vimcal).
Google Calendar își propune să fie o aplicație simplă pe care oricare dintre cei 2 miliarde de utilizatori o poate opera fără îndrumare. Obține scorul 88/100 la accesibilitate. UI-ul nu se schimbă. Nu pică și are suport offline dacă o face.
Pur și simplu funcționează.
Asta e suficient.
Pentru a primi aceste analize aprofundate în inbox-ul tău, abonează-te la newsletter-ul meu, Fullstack Engineer.
\