02 Aplicativo-base
Conheça o aplicativo de táxis de Nova York em execução, agora com dados carregados no ClickHouse, para entender sua estrutura antes de ampliá-lo.
Ponto de partida
Você está em build-workshop-v1 (selecionado no módulo 00) — não é necessário fazer checkout. Reserve
cerca de 5 minutos.
A pilha do workshop iniciada no módulo 00 ainda deve estar em execução.
Pré-requisitos: módulos 00 e 01 concluídos (pilha íntegra, ClickHouse com dados carregados) e
front-end acessível em http://localhost:8080/.
Por quê
Não é possível ampliar aquilo que você ainda não viu. Agora que seu data warehouse tem dados (módulo 01), dedique alguns minutos a entender a estrutura do aplicativo: para que servem os dois painéis, como front-end, back-end e bancos de dados se encaixam e onde fica o painel de chat com IA. Este é o único módulo em que não há nada para construir, e isso é intencional: aqui você se orienta; nos módulos seguintes, amplia o aplicativo com dados ao vivo, agentes e observabilidade.
Objetivo
Ser capaz de descrever, em uma frase para cada item, a finalidade do painel Ops, a finalidade do painel Historical e a origem dos dados do aplicativo (dados históricos carregados no ClickHouse Cloud no módulo 01; dados ao vivo transmitidos por CDC no módulo 03).
Etapa 1 — Abra o painel Ops
frontend/
Abra http://localhost:8080/. Este é o painel Ops: cartões, filtros e layout
para métricas operacionais ao vivo (viagens recentes, zonas ativas e agregações quase em tempo real). Ele
permanece vazio por enquanto — a visualização ao vivo só será preenchida quando você transmitir linhas em tempo real via CDC
no módulo 03. Os dados históricos carregados no módulo 01 aparecem no painel Historical,
que você verá em seguida.
A captura de tela abaixo mostra o painel Ops com o botão Use sample window aplicado, para que você possa ver o layout preenchido com os dados iniciais. Por padrão, ele abre no intervalo ao vivo (hoje), que permanece vazio até o início do CDC no módulo 03.

Etapa 2 — Abra o painel Historical
frontend/
Abra http://localhost:8080/historical. Este painel foi criado para agregações de intervalos amplos
e detalhamentos de dados históricos de viagens — e agora é renderizado, pois você
carregou um mês de viagens no ClickHouse Cloud no módulo 01. Experimente um intervalo de datas amplo dentro
desse mês e os controles de filtro; observe como as consultas retornam em muito menos de um segundo.

Etapa 3 — Encontre o painel de chat e acompanhe o fluxo de dados
backend/
Localize o painel de chat com IA na interface (você o conectará a um modelo real no módulo 08). Depois, observe como o front-end chama o back-end FastAPI e como o back-end está configurado para consultar o ClickHouse — o serviço ao qual ele aponta é seu serviço na nuvem, conectado e preenchido no módulo 01.
React front end -> FastAPI back end -> ClickHouse Cloud (connected + seeded in module 01)
-> ClickHouse-managed Postgres (operational source; created in module 03)Peça ao seu agente de programação que resuma os endpoints de análise:
Read the FastAPI backend and list each analytics endpoint, what it returns, and which table it reads from.Como verificar se você terminou
- Você abriu os dois painéis: Historical é renderizado com os dados que você carregou no módulo 01, e Ops (Live) fica vazio até o início do CDC no módulo 03 — isso é esperado.
- Você sabe dizer de onde vêm os dados do aplicativo (carga histórica no ClickHouse Cloud no módulo 01; CDC ao vivo no módulo 03).
- Você sabe onde fica o painel de chat, embora ele ainda não esteja conectado a um modelo.
Resumo
Agora você tem um modelo mental do aplicativo: dois painéis, uma API FastAPI, um Postgres gerenciado como origem e um painel de chat aguardando conexão. Cada módulo seguinte altera uma parte dessa visão.
Estado final
Você entende o aplicativo em execução. Continue em 03 CDC com Postgres gerenciado para transmitir linhas ao vivo ao painel Ops.