Plataforma de viagens: API, app e back-office

O contexto

Um operador de viagens precisava de uma plataforma que cobrisse toda a sua cadeia: preparar as estadias do lado da equipa, distribuí-las aos viajantes e fornecer no terreno os documentos necessários. Três públicos, três interfaces, uma única fonte de verdade.

O desafio

O ponto difícil de uma aplicação de viagens é evidente assim que se pensa nele e esquecido em nove projetos em cada dez: o viajante não tem rede exatamente quando precisa dela.

Consulta o programa dentro de um avião, procura o bilhete num átrio de estação sobrelotado, verifica uma morada no estrangeiro sem plano de dados. Uma aplicação que pressupõe ligação permanente é uma aplicação que falha precisamente no momento que conta.

Segunda restrição: o viajante não deve ter de criar conta. Um código de acesso tem de bastar — sem que um código ao acaso dê acesso aos dados de outra pessoa.

O que fizemos

• Uma API Django REST como base de negócio única, expondo as estadias, os participantes e os documentos associados.
• Uma aplicação do viajante em Flutter, totalmente utilizável offline. Os dados são serializados e guardados localmente: o programa, as informações práticas e os documentos permanecem consultáveis sem rede e voltam a sincronizar-se assim que a ligação regressa.
• Um acesso por código, sem criação de conta, com regras de segurança escritas para que a leitura de uma estadia exija o código certo — e apenas esse. O conforto de um acesso sem atrito, sem abrir a porta aos dados dos outros viajantes.
• Um back-office em Flutter para as equipas internas, com autenticação distinta da dos viajantes.
• Geração de bilhetes e documentos PDF com códigos de barras, produzidos do lado do servidor para se manterem idênticos em qualquer aparelho que os apresente ou imprima.
• Notificações push para os viajantes e implantação numa infraestrutura Apache com certificados automatizados.

O resultado

A plataforma está em serviço e continua a evoluir. A API e o back-office têm entregas regulares desde a entrada em produção.

A decisão que mais pesou foi tratar o modo offline como uma exigência de partida, não como uma melhoria posterior. É uma escolha que estrutura o armazenamento local, a sincronização e o modelo de dados — quase impossível de recuperar depois, e invisível quando está bem feita.