Autoschematic

The address space is the first real design decision. This is where your connector will describe a hierarchy, based on file paths, of resources that it can manage.

In Python, the SDK does not require a special address trait. You can define a simple decode_addr() helper for simple patterns.

For example, the following addresses (paths) correspond to individual remote resources:

• aws/s3/us-east-1/buckets/photo-backup.ron is an AWS S3 bucket in us-east-1 named "photo-backup"
• aws/elb/us-east-1/load_balancers/backend-autoschematic-sh/listeners/backend.ron is a listener named "backend" for the AWS elastic load balancer named 'backend-autoschematic-sh' in the 'us-east-1' region...
• github/ottercorp/backend/repository.ron is a Github repository named "backend" in the "ottercorp" org ...and so on.

The Grafana connector manages two address classes:

@dataclass
class DatasourceAddress:
    name: str


@dataclass
class DashboardAddress:
    uid: str


def decode_addr(addr: str) -> DatasourceAddress | DashboardAddress | None:
    match addr.split("/"):
        case ["grafana", "datasources", name] if name.endswith(".json"):
            return DatasourceAddress(name.rstrip(".json"))
        case ["grafana", "dashboards", uid] if uid.endswith(".json"):
            return DashboardAddress(uid.rstrip(".json"))
        case _:
            return None

Good address schemes have a few properties:

• One path points to exactly one remote object
• One path points to only one remote object, and vice-versa.
• The address includes everything needed to locate the object remotely.

Reference files:

• autoschematic-sdk-python/examples/grafana.py

• autoschematic-sdk-python/autoschematic_sdk/addr.py

Next: Resource Bodies and filter()