Skip to Content
Engineering11 Documentation 🔥
BackendOverview

Backend — Engineering11 Full-Stack Foundation

This is a documentation-centric backend reference demonstrating the structure and capabilities of the Engineering11 Full-Stack Foundation.

It illustrates a typical backend layout composed of both:

  • Engineering11-provided platform microservices, each with documentation describing its purpose and capabilities, and
  • Customer-built microservices, implemented using the Foundation’s design patterns and service structure.

This reference provides a concrete example of how provided services and your product-specific services coexist within a single system.

Repository Structure

Backend systems built on the Foundation are organized as a unified monorepo where platform and custom services live side by side:

├── engineering11-available-server-apis/  # Documentation of installable E11 server API packages
├── microservices/                 # All backend microservices (platform + custom)
│   ├── service-user/              # Engineering11 platform microservice
│   ├── service-auth/              # Engineering11 platform microservice
│   ├── service-messaging/         # Engineering11 platform microservice
│   ├── service-notifications/     # Engineering11 platform microservice
│   ├── service-files/             # Engineering11 platform microservice
│   ├── service-customer/          # Engineering11 platform microservice
│   └── ...                        # Additional platform and customer services

All backend microservices — whether provided by the Foundation or built by the customer — live in the same root directory (microservices) and follow the same structural and operational conventions. This reflects how real Foundation-based systems are organized.

Typical Backend Structure for a Foundation-Based System

Foundation-provided microservices and customer-built services live side by side, supported by shared libraries, operational tooling, and standardized workflows.

backend-repo/
├─ microservices/                 # All E11 provided and custom backend services
│                                 # Each service follows shared E11 patterns

├─ packages/
│   └─ shared/                    # Shared server-side libraries used across services
├─ static/                        # Static assets package for defining permissions, products, notifications and more
├─ rules/                         # Data access and security rules with tests
├─ ops/                           # Operational tooling (bin, env helpers, platform scripts, playbooks)
├─ queues/                        # Async task / background job queue definitions
├─ env/
│   └─ README.md                  # Environment setup and configuration notes
├─ cloudbuild.yaml                # CI build entrypoint
├─ deploy-*.sh                    # Deployment scripts
├─ docker-compose*.yaml           # Local development orchestration
├─ firebase.json                  # Platform configuration (If Firestore is used)
├─ firestore.*                    # Data store configuration and rules (If Firestore is used)
├─ nx.json                        # Task runner configuration with caching
├─ package.json                   # Yarn workspace root
├─ yarn.lock                      # Workspace lockfile (services, packages, rules, static)
└─ release-please-config.json     # Multi-package versioning and release automation

This structure mirrors how real Foundation-based systems are built and operated: a single, cohesive backend workspace where Foundation-provided services and your product-specific services evolve together using the same tooling, patterns, and operational conventions.

Modern Development Tooling

Engineering11 systems use modern tooling to improve the developer experience:

Monorepo Management:

  • Yarn workspaces for dependency management
  • Nx for build orchestration and caching
  • Release Please for automated versioning and changelogs

Quality & Testing:

  • Jest for unit and integration tests
  • Supertest for API testing
  • gts (Google TypeScript Style) for linting and formatting
  • Husky + lint-staged for pre-commit hooks
  • Commitlint for conventional commits

Development Environment:

  • Docker for containerization
  • Docker Compose for local orchestration
  • Hot reload for rapid iteration

Engineering11 Server API Packages

The engineering11-available-server-apis/ folder catalogs the Foundation’s published server API packages that are used throughout the codebase and can be installed by customers.

These packages provide:

  • Shared domain models
  • Repository patterns for data access
  • Business logic and validation
  • Type-safe interfaces for service integration

Explore Server API Packages →

Backend Architecture

Foundation backends are cloud-native, event-driven, and designed for scale:

  • Containerized microservices — independently deployable REST APIs and workers
  • Event-driven workflows — async processing via pub/sub messaging
  • Repository-pattern data access — consistent interfaces across storage providers
  • Multi-tenant by default — data partitioning and isolation built into every layer
  • Centralized observability — structured logging, monitoring, and tracing

Services follow consistent patterns to reduce cognitive load and operational complexity.

Read Backend Architecture Details →

Microservice Anatomy

Foundation microservices follow a consistent, finite set of structured parts. Each service includes only the components it needs for its domain, but those components always follow the same patterns and conventions:

  • Server APIs — published service packages that other backend services can install to access shared models, domain logic, and repository-based data access through stable, versioned interfaces.
  • IPC REST APIs — authenticated, service-to-service REST endpoints used for internal communication and inter-process coordination between backend services.
  • REST APIs — externally exposed, client-facing endpoints consumed by frontend applications and integrated third-party systems.
  • Background jobs — asynchronous and long-running processes executed outside of request/response flows.
  • Task handlers — discrete asynchronous handlers responsible for processing queued tasks and workflow steps.
  • Shared full-stack libraries — reusable models, utilities, and primitives shared across backend services and frontend applications to ensure consistency.
  • Migrations — controlled change sets used to evolve databases and related system state in a predictable and repeatable way.

This structure makes services predictable to work in, review, and operate over time.

See Microservice Implementation Guide →

Available Platform Microservices

The Foundation provides 20+ production-ready microservices covering core platform domains:

Identity & Access

Customer & Organization

Product & Monetization

Communication

Content & Files

Data & Integration

Operations

Browse All Microservices →

What You Build On Top

The Foundation provides the design patterns and building blocks — your team uses them to build the features that differentiate your product.

With the platform in place, your team owns and implements:

  • Product-specific business logic and domain workflows
  • Custom API endpoints, contracts, and data models
  • Event consumers and producers tailored to your use cases
  • AI services, enrichment pipelines, and decision logic
  • Integration logic with external systems and partners

The Foundation accelerates development by standardizing infrastructure and patterns, without hiding the architecture — your engineers retain full visibility, control, and ownership of the system.

Operational Philosophy

The backend should be boring to operate.

Predictable deployments, strong observability, and safe scaling mean your team spends time building features — not firefighting infrastructure.

Next Steps

Last updated on
Getting StartedArchitecture