Su API primitiva permite programar eventos en internet, y su cliente es una obra maestra de contención.
Cómo funciona Google Calendar y qué podemos aprender de él como ingenieros.
Arquitectura
Framework Frontend: Ninguno (!). Solo algunas bibliotecas internas para cosas como autenticación y utilidades compartidas.
Estilo Frontend: Nombres de clases CSS, invocados por JS.
Almacenamiento Frontend: Cache Storage, IndexedDB (modo sin conexión), CDN (imágenes y fuentes).
Almacenamiento API: Spanner DB.
APIs Externas: Google Meet, Google Contacts, Google Auth.
Servicios: heartbeat, eventing, notificaciones.
Otros: Un compilador interno que hace que JS se descargue y ejecute más rápido.
Problemas Interesantes
Claro, un calendario es una gran aplicación CRUD. Pero no te dejes engañar: había muchos problemas técnicos exigentes que tuvieron que resolverse.
Calendar API
- REST+JSON desde 2011 (originalmente fuente de estilo REST+RSS)
- El modelo de datos se basa en gran medida en cadenas de recurrencia iCalendar RFC 5545 (Microsoft y Apple usan objetos propietarios)
- Los clientes pueden observar/suscribirse para recibir una notificación webhook cuando cambien los eventos
- Admite sincronizaciones incrementales para velocidad... pero también requiere que manejes las expiraciones y re-sincronizaciones por tu cuenta
- Usa cuotas y límites de tasa para reducir problemas de rendimiento
- Poderoso pero primitivo. Te darán suficiente para hacer lo que necesites, pero no lo resolverán por ti.
Diseño HTML
¡Sí, estructurar HTML puede ser realmente interesante! Dado que las vistas de calendario son ricas en contenido, ocurren grandes problemas de rendimiento si los elementos no están aislados.
Estas son las capas HTML más importantes:
- La cuadrícula: fila de todo el día, columnas de día, eventos programados, contenedor
- El evento de vista previa, que no puede bloquearse a una fila/columna
- La capa de arrastre. Esto te permite arrastrar y soltar tareas a la cuadrícula
- Formularios: flotando junto a eventos en la cuadrícula y expandidos en un diálogo de pantalla completa
- Toasts: Para mensajes de confirmación
Algoritmos Frontend
Cada cliente de calendario tiene algunos algoritmos jugosos
- Posición del evento: la longitud, altura y coordenadas (X, Y) de cada div de evento. Para calcular esto, necesitas tener en cuenta la duración del evento y la escala de vista.
- Longitudes de eventos de todo el día: El ancho y las coordenadas Y, que deben ajustarse según los eventos circundantes.
- Eventos superpuestos: cómo ajustar eventos cuando comparten tiempos. La implementación de Gcal es más sofisticada en comparación con la de Outlook (que reduce a la mitad cada evento). Pseudo-código a continuación.
// lógica de eventos superpuestos 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() //los eventos más largos van detrás de los más cortos if start or end of targetEvent != start or end of any(events): if targetEvent overlaps multiple events: targetEventGoesInFrontOfEvents() else: orderEventsByStart() //los eventos que comienzan antes van detrás
\
Consulta el repositorio Compass para nuestra implementación completa de estos algoritmos.
Servicios
Estos son los motores externos que permiten que el código del cliente permanezca simple y confiable
- Servicio Heartbeat: permite que GCal sea confiable y vuelva al modo sin conexión sin problemas
- Servicio de Eventing: eventos estilo pub/sub que alimentan los webhooks para clientes. Esto permite que otras aplicaciones se construyan sobre la API de GCal.
- Servicio de Notificaciones: coordina el momento de tus notificaciones previas al evento. El cliente podría hacer esto solo en teoría, pero sería menos confiable.
[
\
Conclusiones
Construir una aplicación CRUD a escala global puede parecer sencillo desde el diagrama de arquitectura, pero esa simplicidad aún exige un alto nivel de ejecución.
- Confiabilidad de la API: dado que muchas aplicaciones dependen de la sincronización bidireccional con el GCal de un usuario, la API debe ser simple, extensible y confiable. Si la estropean, rompen un ejército de otras aplicaciones downstream.
- Seguridad de datos: los datos del calendario son extremadamente sensibles. Dependen en gran medida de roles basados en alcance para garantizar que solo las personas/aplicaciones que autorices puedan acceder a tus datos.
- Servicios de monitoreo: las verificaciones de salud, el registro y la sincronización ocurren sin parar detrás de escena.
Dadas las demandas de escala, puedes hacerte la vida más fácil simplemente no haciendo cosas.
- No necesitas usar el stack de tendencia. Imagina si abandonaran todo para reescribir su aplicación en Angular. Luego React. Luego Svelte. Luego NextJS. Luego HTMX. Todos esos llegaron después de que se lanzara Google Calendar. GCal eligió JS, se cambió al carril derecho y ha estado navegando a 64MPH durante décadas. A nadie le importa.
- No necesitas publicar en todas las plataformas. Abre la app de escritorio de Google Calendar ahora mismo. Esperaré.
- No necesitas seguir las tendencias de estilo. Bootstrap. Bulma. styled-components. Tailwind. Nombres de clases CSS.
- No necesitas tener la mejor UX. Modo oscuro. Formularios que conservan espacio. Modo claro #FFFFFF. Formularios de página completa.
- No necesitas tener el mejor rendimiento. Su puntuación de Lighthouse en Rendimiento es 31/100.
Al igual que en la vida, vale la pena conocerte a ti mismo al lanzar un producto.
Google Calendar no intenta ser la aplicación moderna que los asistentes ejecutivos usan para programar 40 reuniones al día (Para eso está Vimcal).
Google Calendar pretende ser una aplicación simple que cualquiera de sus 2 mil millones de usuarios pueda operar sin ayuda. Obtiene una puntuación de 88/100 en accesibilidad. La interfaz de usuario no cambia. No se cae, y tiene soporte sin conexión si lo hace.
Simplemente funciona.
Eso es suficiente.
Para recibir estos análisis profundos en tu bandeja de entrada, suscríbete a mi newsletter, Fullstack Engineer.
\