Modules

Overview

#

{{/* < featured-cards section=“modules” limit=“3” > */}}

All Modules

#

{{/* < featured-cards section=“modules” include=“all” excludeFeatured=“true” > */}}

Layered Approach

#

The layering module being used means that code written in lambda/clie/other tool code is not aware of boto3 and all of its complexities.

Layer 0: Core primitives (dxaws-core)

• AwsSession, AssumeRoleSpec
• Context (env/account/region/correlation)
• Event emission interface and standard envelopes
• Registry/config interfaces

Layer 1: Providers (service-specific, per module)

• Route53Provider (dxaws-dns)
• AcmProvider (dxaws-cert)
• CloudFrontProvider (dxaws-edge)
• etc. (dxaws-*)

Providers take an AwsSession and do AWS calls. Nothing else.

Layer 2: Planner / desired state

• “Given inputs, what should exist?”
• Computes desired records, zones, etc.
• Produces plan/diff (no AWS)

Layer 3: Apply/runner

• Talks to providers
• Persists outputs
• Emits events

This layering provides:

• testability
• clarity
• ability to go async later

Module Layout (using declartive convergence)

#

The standard layout for dxaws-* modules looks something like this:

• config = what we want
• planner = what would change
• executor = make it so
• providers = how to talk to external systems (AWS)
• module = how dxaws runs it (CLI wiring, lifecycle, events, registry)

dxaws-<thing>/
  src/dxaws_<thing>/
    __init__.py
    config.py
    planner.py
    executor.py
    module.py
    providers/
      __init__.py
      <service>.py
  tests/
    test_<thing>.py
    ...etc...