artreeus/invoicer_pro

1. Overall shape

- This is a monorepo for an invoicing product with three major parts:

- a React/Vite frontend in src/

- a Node/Express-style backend in server/ plus api/ entrypoint for deployment

- a Supabase database layer defined by SQL migrations in supabase/migrations/

2. Two distinct user-facing surfaces

- The app is split between:

- a public marketing/content site: landing page, blog, contact, privacy/terms, templates gallery, and a public invoice generator

- a protected authenticated app: dashboard, invoices, clients, companies, reports, settings, and item library

- This boundary is enforced in the frontend with auth wrappers like RequireAuth and separate public/private layouts.

3. Frontend shell and routing

- src/main.tsx, src/App.tsx, and the page components in src/pages/ define the app composition.

- Layout components in src/components/layout/ and src/components/public/ provide the chrome for the authenticated area versus public pages.

- The structure suggests the frontend is the primary application shell, with most business interactions happening client-side.

4. State management by domain

- src/store/ contains dedicated stores for the core business entities:

- authStore

- clientStore

- companyStore

- invoiceStore

- itemLibraryStore

- themeStore

- These stores likely coordinate API calls, local UI state, and cross-page data persistence for each domain.

5. Core business domains

- The app revolves around four main data entities:

- companies

- clients

- invoices

- invoice items / item library

- Pages like CompaniesPage, ClientsPage, InvoicesPage, InvoiceFormPage, and ItemLibraryPage map directly to these domains.

- InvoicePreviewPage and exportUtils indicate a render/export workflow for invoice output.

6. Invoice template engine

- src/templates/ contains a large set of invoice themes such as Classic, Modern, Corporate, Minimal, Terminal, and others.

- src/templates/index.ts and shared.tsx imply a template registry and common rendering contract.

- This is a key architectural boundary: invoice data is separated from presentation, and different templates can render the same invoice model.

7. Backend responsibilities

- server/app.js, server/index.js, server/auth.js, server/db.js, and server/cloudinary.js suggest a lightweight backend focused on:

- authentication/session handling

- database access

- file/image upload integration

- serving API routes

- api/index.js likely provides the deployment entrypoint for serverless hosting on Vercel, matching the presence of vercel.json.

8. Database and access control

- The schema lives in Supabase migrations for companies, clients, invoices, invoice_items, and item_library.

- Later migrations explicitly mention RLS policy tightening and insert-policy adjustments, so row-level security is a meaningful part of the architecture.

- This means the backend/frontend likely rely on Supabase for persistence, with database access constrained by per-user policies.

9. External services

- src/lib/cloudinary.ts and server/cloudinary.js show Cloudinary is used for image storage or uploads.

- src/lib/adsense.ts plus src/components/ads/ indicate Google AdSense is integrated into the public content side.

- src/lib/useSeo.ts and public article/content components suggest SEO is handled carefully for the marketing/blog surface.

10. Public content and SEO

- src/content/articles.ts and src/pages/public/Blog* suggest the blog is content-driven and likely static or semi-static.

- Public pages such as About, Contact, Privacy, Terms, and Templates are separated from the logged-in app to support discovery, trust, and SEO.

11. UI and reusable building blocks

- src/components/ui/ provides shared primitives such as Modal, Badge, EmptyState, ThemeToggle, and image upload components.

- AuthShell and PublicLayout are higher-level composition layers that keep auth flows and public pages visually distinct.

- This indicates a componentized frontend with reusable design-system-like building blocks.

12. Platform and deployment signals

- The app is built with Vite, React, TypeScript, and Tailwind/PostCSS.

- vercel.json, api/, and api/index.js suggest deployment on Vercel, with the frontend and backend co-located but separated by runtime boundary.

- Supabase migrations imply the database is managed outside the app runtime and versioned alongside the code.

13. Likely end-to-end data flow

- User interacts with the React UI.

- Frontend stores coordinate domain state and call the API layer.

- Backend authenticates requests and communicates with Supabase and Cloudinary.

- Supabase persists the invoicing entities under RLS.

- The UI renders invoice previews/templates and may export or download final invoice artifacts.

14. What to show in an architecture diagram

- Draw three main zones:

- Public frontend

- Authenticated app frontend

- Backend/API + Supabase/Cloudinary services

- Emphasize the domain data path around clients/companies/invoices/items, and the separate content/SEO/ads path for public pages.