eh-munna/essen-welt

1. Application shape

- EssenWelt is a React 19 single-page frontend built with Vite.

- The repository you provided is primarily the client app; it talks to a separate backend repo (essen-welt-server) for data, auth-backed actions, bookings, orders, and admin operations.

2. Top-level routing and page boundary

- The app is organized around src/Routes/Routes.jsx plus route guards in PrivateRoute.jsx and AdminRoute.jsx.

- Public pages include the marketing/home experience, menu browsing, login/signup, and informational pages.

- Protected routes split into customer dashboards and admin dashboards, which is a key architectural boundary.

3. Layout system

- src/Layouts/Layout.jsx appears to provide the shared shell for public pages.

- src/Layouts/DashboardLayout.jsx is the authenticated dashboard shell, likely containing sidebar navigation and nested dashboard content.

- This separates the app into two major UI surfaces: public site and authenticated workspace.

4. Global state and app-wide context

- The main cross-cutting providers are:

- AuthProvider for Firebase-backed authentication/session state

- CartProvider for ordering state

- TitleProvider for page/document title handling

- These providers are the main client-side state boundaries and likely wrap the app near main.jsx.

5. Authentication and authorization flow

- Authentication is client-managed through Firebase Auth (src/config/firebaseConfig.js).

- Role-based access is enforced on the frontend using route guards and hooks like useAuth, useAdmin, and useUsers.

- The app likely exchanges Firebase identity for a backend-facing JWT via secure API calls, which is why there are separate useAxiosPublic and useAxiosSecure hooks.

6. Data access layer

- Data fetching is abstracted into feature hooks under src/hooks:

- menu, tables, bookings, orders, customers, users, cart, etc.

- These hooks form the app’s server-state layer, insulating pages/components from direct API details.

- useAxiosPublic and useAxiosSecure indicate a clear API boundary between unauthenticated and authenticated requests.

7. Core business domains

- The app centers on three restaurant workflows:

- Menu browsing and item details

- Table booking / reservations

- Food ordering and payment

- Supporting admin workflows include menu/table CRUD, booking management, customer management, and order review.

- The pages in src/pages map directly to these domain areas, making the architecture domain-driven rather than purely technical.

8. Ordering and payment flow

- Cart logic lives in CartProvider plus src/utils/cartUtils.js.

- Customers browse menu items, add them to cart, then move into PlaceOrder, Cart, Payment, and PaymentSuccess.

- src/components/Payment/CheckoutForm.jsx suggests Stripe is the payment boundary, with the frontend handling checkout UI while the backend likely creates/validates payment intents.

9. Booking and reservation flow

- Reservation features are split across booking-related pages, hooks, and modal components.

- BookTable, BookingModal, TableModal, and useBookings/useTable point to a dedicated booking domain.

- Booking state is likely created from the customer UI and then managed in admin views for approval/editing or operational handling.

10. Admin vs customer dashboards

- The dashboard subtree is explicitly split into:

- customer-facing views (MyBookings, MyOrders, profile/edit flows)

- admin-facing views (Dashboard, Customers, Orders, AddMenu, ModifyMenu, AddTable, ModifyTable)

- DashboardSidebar and the dashboard home components (AdminHome, UserHome, DashboardHome) define role-specific navigation and landing content.

- This is the main functional separation in the app.

11. Reusable UI component system

- The app uses a shared component library built from:

- custom domain components (FoodCard, ReviewSlider, ConfirmDialog, etc.)

- generated/shadcn-style primitives in src/components/ui

- These primitives are the presentation layer foundation, while domain components compose them into menu cards, dialogs, drawers, forms, and modals.

12. Notifications, metadata, and UX helpers

- NotificationStack, toast options, DevelopmentBanner, and use-mobile indicate client-side UX concerns are handled centrally.

- TitleProvider/useTitle manage page metadata, which matters for a multi-page SPA with many user flows.

- App.css, index.css, and Tailwind config indicate styling is utility-first with some global overrides.

13. External service and deployment boundaries

- Key external dependencies that materially shape architecture are:

- Firebase Auth for identity

- Stripe for payments

- Express/MongoDB backend for persistence and business APIs

- Vercel for frontend deployment

- The frontend is not responsible for persistence; it is a client orchestrating authenticated calls to the backend services.

14. Overall architecture summary

- EssenWelt is a modular React client organized by routes, layouts, domain pages, shared UI primitives, and data-fetching hooks.

- The main data flow is: user interaction → contextual state/hook → API call to backend → UI update, with Firebase and route guards controlling access.

- The most important diagram boundaries are public vs authenticated UI, customer vs admin workflows, and frontend vs backend/payment/auth services.