For AI agents: the complete documentation index is available at https://a3s-lab.github.io/Boot/en/llms.txt, the full documentation bundle is available at https://a3s-lab.github.io/Boot/en/llms-full.txt, and this page is available as Markdown at https://a3s-lab.github.io/Boot/en/reference/architecture-and-roadmap.md.
A3S Boot
  • English
  • v0.2.0

      • Architecture, production boundaries, and roadmap

      Boot aims to make application structure familiar while keeping Rust types, errors, scopes, and protocol adapters visible.

      Runtime layers

      modules + typed providers
          |
controllers / gateways / message patterns
          |
protocol-neutral and protocol-specific pipelines
          |
BootRequest / WebSocketMessage / TransportMessage
          |
HTTP adapter / WebSocket adapter / MessageTransport

      An upper layer does not depend on a concrete Axum request or broker client. An adapter converts wire input into Boot types and converts Boot replies back to the wire.

      Source responsibilities

      Directory or fileResponsibility
      app/Factories, builders, application shells, contexts, lifecycle, lazy modules
      module/The module trait and DynamicModule
      provider/Tokens, definitions, scopes, resolution, and ModuleRef
      routing/Controllers, routes, matching, handlers, and responses
      pipeline/Middleware, guards, interceptors, pipes, filters, and contexts
      http/Adapter-neutral requests, responses, extraction, cookies, SSE, and files
      websocket/Gateways, connections, subscriptions, rooms, and WebSocket pipeline
      transport/Message patterns, clients, and network transports
      Feature-gated filesAuth, cache, config, events, queue, schedule, security, and other technique modules
      macros/Separate proc-macro crate that generates explicit core definitions

      Public HttpAdapter, MessageTransport, and backend traits are the primary extension points. New implementations should preserve Send + Sync, async cleanup, contextual errors, and the real semantics of the protocol.

      When the graph freezes

      Module imports, provider visibility, routes, gateways, message patterns, and application enhancers resolve during construction. DiscoveryService and ApplicationGraph expose the final snapshot.

      A lazy module fits an isolated provider capability and must not change an already compiled global pipeline. Collect dynamic requirements during the builder stage, then construct the application once.

      Production responsibility matrix

      ConcernBoot mechanismDeployment responsibility
      HTTPAxum adapter, requests, responses, routingTLS, proxy, timeouts, connection limits
      WebSocketUpgrade, gateways, rooms, pipelineCross-instance fanout, backpressure, drain
      MessagesTransport contract and implementationsBroker durability, topology, credentials, capacity
      DIScopes, cycles, lifecycleClear module boundaries and resource closure
      SecurityAuth, CORS, CSRF, headers, rate limitingIdentity source, key rotation, shared backends
      DataFacade and PostgreSQL queue backendSchema ownership, backup, migration, idempotency
      ObservationStructured records and health indicatorsSink, trace correlation, sampling, alerts

      Current compatibility direction

      Implemented Nest-style surfaces include parameter extraction, OpenAPI metadata, validation, module encapsulation, dynamic modules, provider scopes, application enhancers, middleware, WebSocket gateways, microservice transports, and the major technique modules.

      Boot does not attempt to reproduce a JavaScript runtime item by item. Attributes generate static Rust definitions, ModuleRef follows types and visibility, and protocol errors and delivery semantics stay explicit.

      GraphQL is explicitly outside the current roadmap. The focus is HTTP, SSE, WebSocket, message transports, modules, and controller experience. If GraphQL is needed later, it should be evaluated as a separate companion crate instead of being inserted into the core.

      Version compatibility

      This site currently provides v0.2.0 and v0.1.4.

      • The public Boot source capabilities are the same in both releases.
      • The queue-postgres feature in v0.2.0 depends on A3S ORM 0.3.0.
      • The queue-postgres feature in v0.1.4 depends on A3S ORM 0.2.0.
      • Validate Cargo features, the database queue schema, worker recovery, and the lockfile together during upgrade.

      Release tags, crate versions, and the site version switcher use the same number. Application API versioning is independent from documentation versions.

      Change checklist

      When a framework capability is completed:

      1. Add unit or integration coverage for its behavior.
      2. Update crate-root exports and feature gating.
      3. Update the README, roadmap, and corresponding Chinese and English pages.
      4. Verify default-feature, focused-feature, and all-feature builds.
      5. Check Rustdoc, OpenAPI examples, and production-boundary guidance.

      See the repository ROADMAP.md for the detailed implementation plan and GitHub Releases for release history.