Skip to main content
XDevLabs

Technical overview

Explicit responsibilities. Extensible application groundwork.

A closer look at Application Foundation, with a clear distinction between reusable code, configuration and production implementation.

Architecture

The source uses .NET services with Clean Architecture and CQRS patterns. Public HTTP interfaces, internal gRPC and asynchronous messaging establish explicit service boundaries. This architecture does not mean every project needs a microservice deployment.

Identity uses OpenIddict for OAuth2/OpenID Connect. React operator interfaces support administration, and a Payload integration establishes a separate content-management boundary.

Gateway and client access

The gateway provides a browser-facing HTTP entry point for identity, user, storage, notification and CMS APIs. It handles route composition and shared edge concerns, including access integration, CORS, security headers and rate limiting. Frontend telemetry batches enter the observability flow through a gateway ingestion endpoint.

The gateway is an edge adapter, not the owner of business rules or cross-service workflows. Internal gRPC calls remain between services. Route configuration, retry and timeout behaviour and customer-specific policies need implementation review.

Reusable capabilities

Shared engineering includes roles and permissions, file metadata and lifecycle workflows, email templates and notification delivery state. Customer access policies, file retention, providers and actual business processes need to be configured or implemented.

Shared packages also cover persistence, caching and background jobs alongside CQRS, messaging, identity and observability. These are engineering building blocks; provider selection, persistence models, job definitions and business behaviour remain part of the implementation.

Integration and extension

The business domain, customer interfaces and connections to existing systems remain implementation work. Review API contracts, provider choices and service boundaries against the actual requirements.

Operations and release readiness

OpenTelemetry-based signals connect to local observability tooling, with Grafana dashboards, Prometheus metrics, Loki logs and Tempo traces. These assets support investigation of requests and background processing; they are not a managed production-monitoring service. Production thresholds, incident response and support responsibilities must be agreed.

The reviewed identity service targets .NET 8. A supported runtime baseline and any required upgrades must be reviewed as part of an implementation release. No current production-readiness guarantee is made here.

Evaluation and ownership

Source access, reusable foundation rights, third-party licences and project-specific deliverables are distinct. A project agreement must define these alongside hosting, support and handover responsibilities.

Based on repository source reviewed on 15 November 2026. Product runtime tests, security assurance and production deployment were outside that review.

Application architecture
  1. Your business workflow

    Designed for your users

  2. Application & administration

    Interfaces, access and content

  3. Reusable engineering

    Identity · Files · Email · Telemetry

Conceptual architecture, based on reviewed source. Customer workflows and operating requirements are scoped per implementation.
Back to the product overview

Let’s talk about it

Have a technical question or implementation in mind?

Tell us about the problem, the idea or the system you have today. We’ll work out a useful next step together.

Discuss your project