A Arma Secreta de Engenharia do Google Calendar: Contenção

A sua API primitiva permite agendamentos para a internet, e o seu cliente é uma obra-prima de contenção.

Como funciona o Google Calendar e o que podemos aprender com ele enquanto engenheiros.

Arquitetura

Framework Frontend: Nenhum (!). Apenas algumas bibliotecas internas para coisas como autenticação e utilitários partilhados.

Estilização Frontend: Nomes de classes CSS, invocados por JS.

Armazenamento Frontend: Cache Storage, IndexedDB (modo offline), CDN (imagens e fontes).

Armazenamento API: Spanner DB.

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

Serviços: heartbeat, eventing, notificações.

Outro: Um compilador interno que faz o JS descarregar e executar mais rápido.

Problemas Interessantes

Claro, um calendário é uma grande aplicação CRUD. Mas não se deixe enganar — houve muitos problemas técnicos exigentes que tiveram de ser resolvidos.

API de Calendário

• REST+JSON desde 2011 (originalmente feed estilo REST+RSS)
• Modelo de dados baseia-se fortemente em strings de recorrência iCalendar RFC 5545 (Microsoft e Apple usam objetos proprietários)
• Os clientes podem observar/subscrever para receber uma notificação webhook quando os eventos mudam
• Suporta sincronizações incrementais para velocidade…mas também requer que trate expirações e re-sincronizações por conta própria
• Usa quotas e limites de taxa para reduzir problemas de desempenho
• Poderosa mas primitiva. Dar-lhe-ão o suficiente para fazer o que precisar, mas não vão descobrir isso por si.

Layout HTML

Sim, estruturar HTML pode ser realmente interessante! Como as visualizações do calendário são ricas em conteúdo, grandes problemas de desempenho ocorrem se os elementos não estiverem isolados.

Aqui estão as camadas HTML mais importantes:

• A grade: linha de dia inteiro, colunas de dia, eventos programados, contentor
• O evento de pré-visualização, que não pode ser bloqueado numa linha/coluna
• A camada de arrastar. Isto permite-lhe arrastar e largar tarefas para a grade
• Formulários: flutuantes junto a eventos na grade e expandidos num diálogo de ecrã completo
• Toasts: Para mensagens de confirmação

Algoritmos Frontend

Cada cliente de calendário tem alguns algoritmos interessantes

• Posição do evento: o comprimento, altura e coordenadas (X, Y) de cada div de evento. Para calcular isto, precisa de ter em conta a duração do evento e a escala de visualização.
• Comprimentos de eventos de dia inteiro: A largura e coordenadas Y, que precisam de ser ajustadas com base nos eventos circundantes.
• Eventos sobrepostos: como ajustar eventos quando partilham horários. A implementação do Gcal é mais sofisticada em comparação com a do Outlook (que divide cada evento ao meio). Pseudo-código abaixo.

// lógica de eventos sobrepostos 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() //eventos mais longos vão atrás de eventos mais curtos if start or end of targetEvent != start or end of any(events): if targetEvent overlaps multiple events: targetEventGoesInFrontOfEvents() else: orderEventsByStart() //eventos que começam mais cedo vão atrás

\

Veja o repositório Compass para a nossa implementação completa destes algoritmos.

Serviços

Estes são os cavalos de trabalho externos que permitem que o código do cliente permaneça simples e confiável

• Serviço Heartbeat — Permite que o GCal seja confiável e volte para o modo offline graciosamente
• Serviço Eventing — eventos estilo pub/sub que alimentam os webhooks para clientes. Isto permite que outras aplicações construam sobre a API do GCal.
• Serviço de Notificações — coordenar o timing das suas notificações pré-evento. O cliente poderia fazer isto sozinho em teoria, mas seria menos confiável.

[

\

Conclusões

Construir uma aplicação CRUD de escala global pode parecer direto a partir do diagrama de arquitetura, mas essa simplicidade ainda exige um alto nível de execução.

• Fiabilidade da API: Como tantas aplicações dependem da sincronização bidirecional com o GCal de um utilizador, a API precisa de ser simples, extensível e confiável. Se eles cometerem um erro, quebram um exército de outras aplicações a jusante.
• Segurança de dados: Os dados do calendário são extremamente sensíveis. Eles dependem fortemente de funções baseadas em âmbito para garantir que apenas as pessoas/aplicações que autoriza podem aceder aos seus dados.
• Monitorização de serviços: Verificações de saúde, registo e sincronização estão a acontecer sem parar nos bastidores.

Dadas as exigências de escala, pode facilitar a sua vida simplesmente não fazendo coisas.

• Não precisa de usar a stack em tendência. Imagine se eles largassem tudo para reescrever a sua aplicação em Angular. Depois React. Depois Svelte. Depois NextJS. Depois HTMX. Todos esses vieram depois do lançamento do Google Calendar. O GCal escolheu JS, mudou para a faixa da direita e tem navegado a 64MPH há décadas. Ninguém se importa.
• Não precisa de publicar em todas as plataformas. Abra a aplicação de desktop do Google Calendar agora. Vou esperar.
• Não precisa de acompanhar as tendências de estilização. Bootstrap. Bulma. styled-components. Tailwind. Nomes de classes CSS.
• Não precisa de ter a melhor UX. Modo escuro. Formulários que conservam espaço. Modo claro #FFFFFF. Formulários de página completa.
• Não precisa de ter o melhor desempenho. A sua pontuação lighthouse em Desempenho é 31/100.

Tal como na vida, compensa conhecer-se a si próprio ao lançar produtos.

O Google Calendar não está a tentar ser a aplicação moderna que assistentes executivos usam para agendar 40 reuniões por dia (É para isso que serve o Vimcal).

O Google Calendar pretende ser uma aplicação simples que qualquer um dos seus 2 mil milhões de utilizadores pode operar sem orientação. Tem uma pontuação de 88/100 em acessibilidade. A interface não muda. Não fica offline, e tem suporte offline se isso acontecer.

Simplesmente funciona.

Isso é suficiente.

Para receber estes mergulhos profundos na sua caixa de entrada, subscreva a minha newsletter, Fullstack Engineer.

\