edinsoncs/sistema-restaurante

1. System shape

This repository is a single Node.js/Express monolith for a restaurant CMS/POS-style system. It is not split into separate services; the browser talks to one server that serves pages, static assets, and feature-specific routes.

2. Server bootstrap

The runtime entry points are app.js and bin/www. Together they wire up the Express application and start the HTTP server. app.js is the central composition point for middleware, routes, views, and authentication.

3. Route structure

Business capabilities are separated into route modules under routes/:

- panel.js for the main dashboard

- mesas.js and copymesas.js for tables/seat management

- pedidos.js for orders

- ventas.js plus sale-report routes for sales views

- admin.js for administration

- users.js, validate.js for access and validation

- apipollos.js for a domain-specific API endpoint

- index.js as the landing/root router

4. Authentication

passport.js and models/local.js indicate Passport-based local authentication. The app likely uses local credential checking for login and session-based access control across admin and operational screens. routes/users.js and routes/validate.js are part of that access flow.

5. Server-rendered UI

The UI is rendered with Jade/Pug templates in views/. views/layout.jade provides the shared shell, while pages like panel.jade, mesas.jade, pedidos.jade, admin.jade, and the sales/report views form the main screens. This suggests a traditional server-rendered app with page-specific client enhancement.

6. Frontend behavior

The public/javascripts/ folder contains feature-focused browser code:

- mesaslist.js, deleteMesas.js, copiamesas.js for table workflows

- platos.js, stock.js for menu/inventory operations

- ventas.js, ventasefectivo.js, ventastarjetas.js, ventasmensual.js for sales and reporting

- app.js, appadmin.js, web.js as broader UI controllers

- jQuery plugins such as jquery.cookie.js and jquery.hideseek.js

7. Static asset layer

CSS, fonts, and images are served from public/. The styles are organized by feature: mesas, menu, salon, reporte, administracion, print, notify, etc. FontAwesome assets are included for iconography. This separation implies distinct screens with their own presentation concerns.

8. Build/authoring workflow

The repo keeps both source-style and compiled assets. Many .scss files sit next to generated .css files, and there are prepros.cfg files plus webpack-config.js. That points to a frontend build pipeline for compiling SCSS and bundling or managing client scripts, even though the app itself runs as a server-rendered Node project.

9. Alternative/legacy frontend area

The aplicacion/ directory looks like a parallel or older frontend bundle containing its own index.html, js/, css/, fonts, and images. Architecturally, treat this as a separate static UI workspace or a prior iteration of the front-end, not the main Express app entrypoint.

10. Primary data flow

Typical flow is: browser requests a route → Express route handler prepares data or checks auth → Jade template renders the page → feature-specific JavaScript in public/javascripts/ performs interactions and updates the UI. For operational screens like tables, orders, and sales, the client scripts appear to drive most interactivity after initial page load.

11. Functional domains

The repository centers on restaurant operations:

- table management

- orders

- menu/dishes

- stock

- sales reporting

- administrative panels

The naming of the routes and views makes these the key bounded areas for any diagram.

12. External dependencies and boundaries

No external backend services are evident in the tree. The main external-facing boundary is the browser, which consumes server-rendered pages plus static JS/CSS, while authentication is handled locally through Passport. The architecture is therefore best diagrammed as a single server with a static asset layer and multiple feature routes.