mrmls-dev/nhs-mono-app

1. This repository is a monorepo with two runtime apps and shared packages: a Next.js frontend in apps/web, a NestJS backend API in apps/api, and reusable UI/tooling in packages/*. The overall product appears to be a multi-tenant real-estate/agent marketing platform, based on the domain models and routes for agents, communities, counties, regions, floor plans, contacts, and branding.

2. The frontend (apps/web) is the user-facing application. It uses the Next.js App Router and is split into three major route groups: public marketing pages, authentication pages, and a protected dashboard. This separation is important for diagramming because each group has a different rendering and authorization boundary.

3. Public marketing pages render community and plan detail pages, schedule pages, and Open Graph image endpoints. These pages also rely on a mix of static assets in apps/web/public and local data files in apps/web/data, which suggests some public content is prebuilt or semi-static rather than always fetched from the API.

4. The dashboard area is the main authenticated workspace. It contains management screens for agents, communities, counties, regions, contacts, listings, members, integrations, SEO, domains, branding, and scheduling embeds. Many of these screens are composed from client-side components under app/dashboard/**/_components, indicating that the dashboard is interactive and form-heavy while still leveraging server-side route structure.

5. The web app’s data access is centralized in apps/web/lib/api/*, with one client module per backend domain area. This is the main frontend-to-backend boundary: UI components talk to these API wrappers, which in turn call the NestJS service. apps/web/lib/auth-client.ts and apps/web/proxy.ts indicate auth/session handling is wired into the frontend request path, likely to protect dashboard routes and attach session context.

6. The backend (apps/api) is a modular NestJS service. Each business area is isolated into its own module, controller, and service: agents, communities, counties, floor plans, regions, staff, marketing contacts, integrations, stats, storage, Mapbox token management, GHL, Vercel, and auth. For an architecture diagram, these modules are the core domain boxes behind a single API boundary.

7. Persistence is handled through Prisma in apps/api/prisma, with generated client code, migrations, and a seed script. The schema includes both business entities and auth/tenant entities such as Organization, Member, User, Session, Account, Invitation, and Verification, plus domain entities like Community, County, Region, FloorPlanModel, MarketingContact, and integration records. This implies the database is the system of record for both tenant identity and marketing content.

8. Authentication and authorization are first-class backend concerns. The API has dedicated auth modules, guards, decorators, and role/session support, which means request processing likely flows through session validation and role checks before domain services run. The presence of organization/member tables suggests access control is tenant-scoped rather than purely user-scoped.

9. Several backend modules represent external integrations or platform concerns rather than core CRUD. ghl and integrations point to GoHighLevel-style marketing automation integration, vercel likely manages deployment or environment linkage, mapbox handles token provisioning, and storage suggests file/media handling. These should be drawn as outbound integration points from the API, not from the frontend.

10. Shared packages separate cross-cutting concerns from app logic. packages/ui contains the design system and shadcn-style components consumed by the web app, while packages/typescript-config and packages/eslint-config standardize build and code-quality settings across the repo. This keeps UI primitives and tooling boundaries distinct from the business applications.

11. The monorepo is managed with Turbo and package-lock-based workspace tooling, so build/test boundaries are likely optimized around app/package dependency graphs. In practical terms, the architecture is not just “frontend talks to backend”; it is “Next.js app + Nest API + shared UI packages + centralized DB,” with each domain isolated into modules on the backend and route groups on the frontend.