Estudo de caso
Sabor em Brasas
Sistema de operação para uma espetaria: PWA para os garçons lançarem pedidos nas comandas, painel com mesas, estoque e relatórios e um QR por mesa para o cliente acompanhar o consumo. Funcional em ambiente de testes (homologação).
- Estágio
- Funcional em homologação
- Período
- 2026
- Papel
- Desenvolvimento full stack
- Tipo
- Sistema para restaurante
O problema
Em uma espetaria, o mesmo atendimento passa pelo garçom, pela churrasqueira, pela cozinha e pelo caixa. Um espeto pode ter ponto da carne, uma mesa pode ter mais de uma comanda e também há vendas sem mesa.
O sistema precisava registrar cada pedido uma única vez, mesmo quando o celular do garçom reenvia a mesma requisição por falha de rede, manter as telas de todos atualizadas e chegar ao fechamento da conta com os valores corretos.
A solução
O garçom usa um PWA no celular para abrir a mesa, lançar os itens com o ponto de cada espeto e acompanhar os pedidos. Cada item segue para o setor de preparo cadastrado no produto, e o painel imprime a via de cada setor pelo navegador.
O painel administrativo reúne mesas e QR Codes, produtos, estoque, usuários e relatórios. Pelo QR da mesa, o cliente consulta o consumo e pode pedir a conta; os pedidos continuam sendo feitos pelo garçom. Uma API em Node.js/Express com MySQL concentra as regras e avisa as telas sobre mudanças em tempo real.
Minha participação
Desenvolvi o site público, o PWA do garçom, a página do cliente acessada pelo QR, o painel administrativo e a API. Modelei o banco em MySQL, escrevi as regras de pedidos, comandas e estoque. O projeto inclui testes automatizados de regras da API com banco simulado.
Fluxos demonstráveis
Do pedido ao preparo
- 1O garçom entra no PWA com usuário e PIN, abre a mesa e lança os itens, informando o ponto de cada espeto.
- 2O pedido sai do aparelho com uma chave de idempotência. Se a resposta não chega, o PWA guarda a tentativa e o garçom confirma o reenvio com a mesma chave, sem criar pedido duplicado.
- 3Os itens são separados pelo setor de preparo cadastrado em cada produto.
- 4No painel, a via de cada setor sai sem preços, pelo diálogo de impressão do navegador, em layout para bobina de 80 ou 58 mm; os status de preparo são atualizados na aba Pedidos.
Consumo e conta pelo QR da mesa
- 1O cliente lê o QR Code da mesa e abre a página da comanda.
- 2Ele vê os itens consumidos e o total até o momento.
- 3Pode tocar em “Pedir a conta”: a mesa fica marcada e as telas da equipe são avisadas.
- 4A página do cliente não permite fazer pedidos; isso continua com o garçom.
Fechamento da mesa
- 1A comanda passa para aguardando pagamento.
- 2O administrador marca a comanda como paga no painel. A mesa só fecha com todos os pedidos entregues ou cancelados e todas as comandas pagas ou canceladas.
- 3Reabrir ou cancelar uma comanda também exige perfil de administrador.
- 4Cancelar uma comanda cancela os pedidos pendentes e devolve os itens ao estoque.
Venda sem mesa
- 1O garçom inicia um atendimento sem mesa, com o nome do cliente quando informado.
- 2Usa o mesmo cardápio e o mesmo carrinho das mesas.
- 3Nos relatórios, a venda aparece identificada como venda sem mesa.
Funcionalidades confirmadas no código
PWA do garçom
- Acesso com usuário e PIN.
- Abertura de mesas e lançamento de itens com o ponto da carne.
- Venda sem mesa com o mesmo cardápio.
Painel administrativo
- Mesas e QR Codes, com visualização e reimpressão do QR.
- Produtos com preço, custo e setor de preparo.
- Estoque com conferência diária, baixa ao criar o pedido (que é bloqueado se faltar produto) e histórico de movimentações.
- Transferência de itens entre comandas do mesmo atendimento.
- Usuários com perfis de garçom e administrador.
Relatórios
- Resumo e visões por pedido, comanda, produto e período.
- Faturamento, custo e lucro visíveis apenas para administradores.
- Pedidos cancelados ficam fora de todos os valores.
A imagem mostra apenas o site público. O PWA do garçom, o painel e a página do cliente não aparecem aqui porque capturá-los exigiria criar mesas, comandas e pedidos no ambiente de testes.
Desafios técnicos
Pedidos sem duplicidade
Se a rede falha depois que o servidor grava o pedido, o PWA pode reenviar a mesma requisição. Cada envio leva uma chave gerada no aparelho do garçom, e o servidor guarda essa chave com um hash do conteúdo: mesa, comanda, itens, quantidades e pontos. Um reenvio idêntico devolve o pedido original; a mesma chave com outro conteúdo é recusada. Preço e custo ficam fora do hash porque são sempre lidos do catálogo no servidor.
Telas atualizadas com SSE
Garçons, painel e página do cliente precisam ver a mesma situação das mesas. A cada mudança, a API envia por Server-Sent Events apenas um sinal, e cada tela refaz a consulta com a própria autorização. Para não colocar o token de acesso na URL, a conexão usa um ticket de uso único e curta duração.
Comandas e estoque consistentes
Operações que mexem na mesma comanda ou no mesmo estoque, como lançar pedido, transferir item, cancelar ou fechar a mesa, rodam em transações com bloqueio de linha no MySQL. Preço, custo e setor são gravados no item no momento do pedido, então uma mudança posterior no cardápio não altera o faturamento já registrado.
Estágio e limitações
Sistema funcional em ambiente de testes (homologação).
- O pagamento é registrado manualmente no painel; não há integração com meios de pagamento.
- A impressão passa pelo diálogo de impressão do navegador; não é automática nem usa integração direta com a impressora.
- O QR da mesa serve para consultar o consumo e pedir a conta; o cliente não faz pedidos por ele.
- Algumas abas de configurações do painel ainda são demonstrativas e não fazem parte desta descrição, e os relatórios não são exportados.
- O estoque está em uma primeira etapa: não há compras, fornecedores nem ficha técnica.
- Não há tela de cozinha separada; o preparo é acompanhado pelas vias impressas e pelo painel.