Frontend Architecture

Key Takeaways

1. Both repos are Angular 18 — frontends has been upgraded from 14 to 18.2.13, matching peeq-mono. This removes the version gap as a unification barrier.
2. Massive duplication — Both repos call the same 24+ backend services, have overlapping component libraries (@vzlabs/ui vs @vzlabs/peeq-ui), and duplicate services for celebrity, content, events, and payments.
3. Different UI foundations — peeq-mono uses Tailwind/DaisyUI; frontends uses Bootstrap/Angular Material. This is the primary unification blocker.
4. Frontend dead code — 5 API gateways (broadcast, conference, stream, dwolla, logging) call backend services not deployed to production. ~17% of API calls target non-existent services.
5. 11 brand tenants themed in peeq-mono, 6 in frontends — theming is CSS-variable-based in both, but different variable naming conventions.

Migration Decision Question

Can frontends be unified into a single Angular 18 monorepo, and what does the frontend call?

Migration Verdict

Verdict: Consolidate Complexity: XL Key Constraint: Different CSS framework foundations (Tailwind/DaisyUI vs Bootstrap/Angular Material) require component-by-component migration, not a simple merge Dependencies: Backend API stability (all frontend services depend on 24+ GraphQL gateways)

Services Inventory

Frontend App Matrix

API Surface

GraphQL Gateways (24+ endpoints)

Both peeq-mono and frontends call essentially identical backend services via Apollo Client:

Cross-Check Result (Session 0 validation)

Mismatch: 5 of 30 API gateways (~17%) call backend services NOT deployed to production. This exceeds the 10% threshold set in the plan.

Resolution: All 5 mismatches are frontend dead code — API calls to services that were once deployed but have been removed from production (broadcast, conference, stream) or never deployed (dwolla, logging). The Session 0 service list is correct; the frontend simply hasn’t been cleaned up.

Dead code inventory: - BroadcastGateway / BroadcastService — broadcast never reached prod - ConferenceGateway / ConferenceService — conference/Jitsi not deployed - StreamGateway — peeq-stream replaced by other services - DwollaService (frontends only) — Dwolla SDK calls in admin-fe - LoggingService (frontends only) — no dedicated logging service in prod

REST/Non-GraphQL Endpoints

API Backward Compatibility Constraints

• All GraphQL — No REST API versioning. Changes to GraphQL schema fields would break both frontends simultaneously.
• Apollo Client config is hardcoded in both repos with identical gateway URLs. Any backend URL change requires coordinated frontend deployment.
• SSE subscription paths are shared between repos — cannot change without updating both.
• File upload multipart endpoints have specific content-type expectations.
• Keycloak token format is shared — any auth changes affect all frontends.

Data Model

No frontend-specific persistent data. All state is: - Apollo InMemoryCache — per-gateway GraphQL response cache - BehaviorSubject stores — in-memory reactive state (peeq-mono) - SessionStorage/LocalStorage — auth tokens, user preferences, tenant config - No IndexedDB or Service Worker caching observed

External Integrations

Architecture Comparison

Key Differences

1. CSS foundation — Tailwind vs Bootstrap is the biggest gap. Components can’t be shared without restyling.
2. Component library naming — @vzlabs/ui vs @vzlabs/peeq-ui are separate packages with overlapping but not identical APIs.
3. Apollo versions — Different major versions of apollo-angular (11 vs 7).
4. Date libraries — peeq-mono uses luxon 3; frontends uses date-fns + moment + luxon 1 (three libraries for the same purpose).
5. Additional tools in frontends — Monaco editor, Quill, Plaid, OpenPGP.

Multi-Brand Theming

peeq-mono: 11 Tenants

libs/ui/tenants/
├── agilenetwork/     ← Primary
├── peeq/
├── braintrust/
├── monster/
├── geoffreyzakarian/
├── peeqkitchen/
├── speedofai/
├── fanfuzenil/
├── vtnil/
├── nilgameplan/
└── sd4l/

frontends: 6 Tenants

libs/peeq-ui/assets/styles/themes/
├── agilenetwork.scss
├── braintrust.scss
├── nilgameplan.scss
├── fanfuzenil.scss
├── speedofai.scss
└── vtnil.scss

Theming Mechanism (Both Repos)

1. Theme compiled as separate CSS bundle with inject: false
2. Environment config sets themeStylesheet path
3. App initialization dynamically loads tenant CSS
4. CSS custom properties (:root variables) override component styles
5. Brand-specific assets loaded from GCS tenant buckets

Keycloak Themes

Fan theme uses realm.getName() for dynamic tenant assets (more scalable). Celeb theme uses hardcoded paths.

Testing Status

Both repos have effectively zero test coverage. This is a significant risk for any migration.

Gen 1 → Gen 2 Comparison

All Gen 1 standalone frontend repos are inactive and archivable. Gen 2 is the active codebase.

Modernization Implications

Can frontends be unified?

Technically feasible, but XL complexity. The barriers are:

1. CSS Framework Migration (L effort): Tailwind/DaisyUI ↔︎ Bootstrap/Material requires restyling every component. Cannot be automated.
2. Component Library Merge (L effort): @vzlabs/ui (249 components) and @vzlabs/peeq-ui (100+ modules) overlap significantly but have different APIs and styles.
3. Apollo Version Alignment (S effort): Upgrade frontends from apollo-angular 7 to 11, or vice versa.
4. Date Library Consolidation (S effort): Pick one — luxon 3 is the best candidate. Remove moment and date-fns.
5. Brand Theme Reconciliation (M effort): Merge 11 + 6 tenant themes into one system. CSS variable names may differ.

Recommended Unification Strategy

graph LR
    A[Current: 2 Repos] --> B{Phase 1}
    B --> C[Shared API layer<br/>Extract common services]
    C --> D{Phase 2}
    D --> E[Standardize on Tailwind<br/>Migrate frontends components]
    E --> F{Phase 3}
    F --> G[Merge into single<br/>Nx monorepo]
    G --> H[Unified: 1 Repo<br/>4 apps + 1 lib]

Phase 1: Extract common service layer (GraphQL gateways, auth) into a shared library usable by both repos. This provides immediate value without restyling.

Phase 2: Migrate frontends components from Bootstrap/Material to Tailwind/DaisyUI, or vice versa. This is the bottleneck.

Phase 3: Merge into single Nx monorepo with apps: mono-web, mobile, admin-fe, celeb-fe, org-dashboard-fe and one unified component library.

What to do with org-dashboard-fe?

Only 4 pages using Angular standalone components. This is already the most modern pattern. Consider it a pilot for the unified architecture — migrate it first.

Dead Code Cleanup

Remove these dead API integrations from both repos before any migration: - BroadcastGateway / BroadcastService - ConferenceGateway / ConferenceService - StreamGateway - DwollaService (if Dwolla is confirmed inactive in Session 5) - LoggingService

Last updated: 2026-01-30 — Session 1 Review by: 2026-07-30 Staleness risk: Medium — frontend evolves with feature development