Food Store
E-commerce de productos alimenticios hecho en equipo: catálogo, carrito y pedidos con máquina de estados, panel admin de stock y auth con JWT y roles.
El problema
El trabajo práctico grupal de Programación 4 pedía construir un backend real con autenticación, roles y un dominio de negocio no trivial — no un CRUD simple, sino algo con reglas propias: control de stock, costeo de productos según sus insumos, y un flujo de pedidos con estados.
Qué construimos
Un backend en FastAPI + SQLModel sobre PostgreSQL con autenticación JWT (access y refresh token en cookies HttpOnly) y 4 roles con permisos distintos por endpoint (admin, stock, pedidos, cliente). El catálogo maneja categorías, ingredientes y productos, donde el costo de cada producto se recalcula automáticamente en base al precio de sus insumos. Los pedidos siguen una máquina de estados (pendiente → confirmado → en preparación → en camino → entregado / cancelado). El frontend en React + TypeScript usa Zustand para estado global y TanStack Query para el catálogo y los pedidos.
Nuestro rol
Trabajamos 5 personas dividiendo el proyecto en módulos (usuarios, catálogo, pedidos). Además del código, participamos del diseño del patrón repository / unit-of-work genérico que usa todo el backend, para no repetir el mismo código de acceso a datos en cada módulo.
Desafíos técnicos
-
Costeo dinámico: el costo estimado de un producto no se guarda
fijo, se calcula en cada lectura sumando
cantidad × precio_por_unidadde cada ingrediente — así si sube el precio de un insumo, el costo del producto se actualiza solo, sin tener que recorrer y actualizar productos manualmente. - RBAC por endpoint: cada ruta define qué roles pueden acceder, en vez de un único chequeo de "está logueado" — el rol stock puede actualizar inventario pero no aprobar pedidos, por ejemplo.
- Repository / Unit of Work genérico: una capa base reutilizable para que cada módulo (productos, ingredientes, pedidos) no reimplemente su propio CRUD contra la base.
Qué haríamos distinto
El README del proyecto ya identifica los próximos pasos: sumar websockets para que el cliente vea el avance de su pedido en tiempo real (hoy hay que refrescar la página), y agregar Mercado Pago como forma de pago real en vez de solo efectivo y transferencia.