Skip to Content
Engineering11 Documentation πŸ”₯
FrontendPlatformsAngular (Web)

Angular (Web)

Nx monorepo with 26 publishable SDK libraries, ~65 custom UI components, NgRx ComponentStore state management, and a CSS design token system β€” giving you a complete Angular web application foundation.

What It Does

The Angular platform spans two repositories:

  • sdks-angular β€” The Foundation layer. An Nx-managed monorepo of 26 publishable libraries providing auth, RBAC, theming, messaging, notifications, files, search, commerce, and more.
  • Your product app β€” An Angular CLI workspace consuming Foundation SDKs. Product apps are built on top of the Foundation layer and compose its packages into domain-specific experiences.

Foundation libraries are published as @engineering11/*-web npm packages to GitHub Packages. Product apps consume them via npm install.

Key Capabilities

CapabilityDescription
Nx 18 MonorepoParallel builds, dependency graph, remote caching on GCP β€” developers build only what changed
26 SDK LibrariesPublishable @engineering11/*-web packages covering every Foundation domain
~65 UI ComponentsCustom e11- prefixed library (no Angular Material dependency) with secondary entry points for tree-shaking
CSS Design Token SystemThree-layer architecture: static theme packages β†’ runtime tenant overrides β†’ Tailwind utility mapping
NgRx ComponentStoreReactive state management across all SDK libraries with EntityAdapter for collections
Firebase Auth + RBACMulti-tenant auth, route guards, session timeout, and product Γ— role β†’ permissions mapping
Config Provider PatternAbstract BaseConfigProvider + forRoot() β€” SDKs stay encapsulated, product apps plug in their own config
Cross-Repo Dependency CascadeRelease Please β†’ publish β†’ repository_dispatch β†’ auto-update PRs in downstream repos
Cloud Build + Firebase HostingMulti-environment CI/CD with parallel builds, source-map upload, and per-branch preview URLs
Conventional CommitsCommitizen + commitlint + AI PR review driving automated changelogs and semver versioning

How It Fits Together

β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β” β”‚ sdks-angular (Foundation Layer) β”‚ β”‚ Published as @engineering11/*-web to β”‚ β”‚ GitHub Packages (npm.pkg.github.com) β”‚ β”‚ β”‚ β”‚ 26 SDK libraries: auth, access, config, β”‚ β”‚ files, messaging, notifications, search, β”‚ β”‚ commerce, community, social, and more β”‚ β”œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€ β”‚ npm install β”‚ β”œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€ β”‚ Your Product App (Product Layer) β”‚ β”‚ Consumes @engineering11/* packages β”‚ β”‚ β”‚ β”‚ Apps: your domain-specific applications β”‚ β”‚ Shared: shared-lib (domain components, β”‚ β”‚ error mappings, product services) β”‚ β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜

Architecture

Module Structure

Feature modules follow a consistent pattern with lazy-loaded routes:

modules/jobs/ β”œβ”€β”€ jobs.module.ts β”œβ”€β”€ jobs-routing.module.ts β”œβ”€β”€ views/ # Routed page components β”œβ”€β”€ components/ # Reusable feature components β”œβ”€β”€ services/ # Feature-level services └── stores/ # ComponentStore files

The codebase is primarily NgModule-based with ~60 standalone components in newer features. Migration to standalone is underway.

SDK Configuration

Every SDK uses the same forRoot() pattern β€” abstract base config, concrete provider, module import:

// SDK defines the contract export abstract class BaseAuthConfigProvider { abstract get config(): IAuthConfig } // Your product app provides its implementation export class AuthConfigProvider extends BaseAuthConfigProvider { get config(): IAuthConfig { return { authBaseURL: environment.services.auth, tenantId: this.appConfig.config.auth.tenantId, } } } // Wired via forRoot() AuthModule.forRoot({ configProvider: AuthConfigProvider })

Routing

All feature modules are lazy-loaded with multi-layered guards:

  1. Auth guards (@engineering11/auth-web) β€” superGuard, loggedInOnlyGuard
  2. Permission guards (@engineering11/access-web) β€” PermissionsGuard with route data
  3. Feature guards (@engineering11/config-web) β€” FeatureGuard checks feature flags
  4. Domain guards (product-level) β€” data pre-loading and role checks

What You Don’t Have to Build

  • 26 publishable SDK libraries covering auth, RBAC, theming, config, files, messaging, notifications, search, commerce, community, social, maps, multimedia, payment, analytics, content, events, registration, user management, and tenant bootstrap
  • ~65 UI components (forms, layout, feedback, data display, media, loaders, rich text, overlays)
  • CSS design token system with runtime white-label theming
  • Firebase Auth integration with multi-tenant support, guards, and session timeout
  • Product Γ— role permission system backed by Firestore
  • NgRx ComponentStore for every SDK domain
  • Cross-repo dependency cascade (SDK publish β†’ auto-update product apps)
  • Cloud Build CI/CD to Firebase Hosting with preview deployments
  • Conventional commit enforcement with AI PR review
  • Rollbar error monitoring with structured error handler classes
  • Nx remote caching on GCP for fast CI builds

What You Build

  • Product-specific features, views, and business logic
  • Config providers for each SDK (BaseXxxConfigProvider implementations)
  • Route definitions and guard configuration
  • Product-specific error type constants and handler mappings
  • Domain components for product-specific UI
  • Environment files (Firebase configs, API URLs, third-party keys)
  • NgRx store logic for product-level state

Next Steps

Last updated on