O problema
O Ristorante Gina, um restaurante de frutos do mar, funcionava no papel: os garçons anotavam os pedidos à mão, a cozinha e o bar liam as mesmas comandas e a conta era somada no caixa. Os donos queriam um único sistema para o salão, a cozinha e o gerente, pensado para depois atender mais de um restaurante.
O que eu construí
Desenvolvi o RistoFlow, um aplicativo web de gestão de restaurantes, e o configurei com o Gina como primeiro restaurante.
- Mapa do salão — mesas agrupadas por ambiente, com estados em tempo real (livre, ocupada, pedidos em andamento, pedidos prontos) e o número de lugares definido ao abrir a mesa.
- Pedidos pelo celular — os garçons montam o pedido por categoria, com observações por prato. Ao enviar, ele é dividido automaticamente entre cozinha e bar, e cada setor vê só o próprio trabalho.
- Tela da cozinha — uma tela que se atualiza a cada 5 segundos, leva cada pedido de enviado a em preparo, pronto e servido, destaca os atrasos e imprime uma comanda de 72 mm, automaticamente se necessário.
- Contas — total da mesa com couvert, pré-conta para impressão e fechamento. Desde a versão 1.5.0 os preços ficam visíveis apenas para o gerente, que fecha a conta, e não para garçons ou equipe da cozinha.
- Editor de cardápio e relatórios — categorias, preços (também por 100 g), pratos marcados como esgotados na hora, além de faturamento diário, número de clientes e pratos mais vendidos.
- Quatro perfis, vários restaurantes — administrador da plataforma, gerente, garçom e cozinha. Cada restaurante tem seus próprios usuários e dados, mantidos separados.
- Pacote para servidor local — um instalador que coloca o aplicativo, com o cardápio e as mesas reais do Gina, em um PC dentro do restaurante, com um script de backup diário.
Com o que foi feito
PHP 8 e MySQL com PDO, JavaScript puro, sem bibliotecas externas. Um único endpoint de API atende todas as chamadas. Sessões com tokens CSRF e senhas com hash. O cardápio e a carta de vinhos do Gina foram carregados em 9 categorias.
Por que foi feito assim
Mantive o aplicativo sem dependências e usei polling simples em vez de websockets, para que ele rode em uma hospedagem compartilhada comum. A mesma escolha facilitou levá-lo para um servidor local: pedidos e contas continuam funcionando pelo Wi-Fi do restaurante mesmo quando a internet cai.
