LocalStack and local cloud dependencies

Model a cloud API without provisioning its cloud service

A stub returns a response supplied by your test. An emulator is a running service that implements selected API behavior and maintains its own state. LocalStack provides local endpoints for supported AWS APIs. It is useful for application integration, but support varies by service, version, and edition. Passing locally does not prove real AWS authorization, quotas, availability, billing, or every API edge case.

MicroBank needs messaging as well as HTTP services. SNS publishes messages to subscribers; SQS holds messages for consumers to receive and acknowledge. In the guided local target, Accounts publishes an event, a topic/subscription sends it to a queue, and Ledger consumes it. Creating a queue alone establishes none of those other connections.

Read the flow before running the emulator

The inspected upstream initializer creates SNS/SQS resources and an S3 practice bucket. Read infra/localstack/init.sh at the pinned MicroBank revision and list the topic, queue, subscription, policy, and Region it declares. Distinguish the identifier of a resource from the endpoint address used to reach the emulator.

Use this design checklist as a reasoning exercise now:

Complete the Docker module before starting LocalStack. That module teaches images, ports, networks, Compose, and health checks. This page introduces the dependency model now; the implementation guide provides the actual startup profile later.

Select a version deliberately

Upstream references localstack/localstack:3.0, an older project choice, not a current recommendation. Check the current setup, licensing, authentication, service coverage, and architecture requirements before choosing a compatible image for your profile. Record the chosen version and test the needed APIs; replacing a tag does not prove compatibility.

On the 16 GB host, stop other deployment tracks before the guided profile. An emulator health endpoint proves less than initialized resources. Initializer logs prove less than a message arriving and being consumed. Each observation answers a different question.

Inspect only the local endpoint when it is ready

After the later guided profile has deliberately started a working emulator on loopback port 4566, use AWS CLI v2 from the Mac:

(
  unset AWS_PROFILE AWS_SESSION_TOKEN AWS_WEB_IDENTITY_TOKEN_FILE AWS_ROLE_ARN
  export AWS_ACCESS_KEY_ID=test
  export AWS_SECRET_ACCESS_KEY=test
  export AWS_EC2_METADATA_DISABLED=true
  aws --endpoint-url=http://127.0.0.1:4566 --region ca-central-1 sns list-topics
  aws --endpoint-url=http://127.0.0.1:4566 --region ca-central-1 sqs list-queues
)

The subshell confines the dummy local credentials to these commands. Both requests explicitly target loopback. ca-central-1 matches the inspected initializer; a different Region can show a different local resource view. These reads do not create anything if initialization is missing.

Compare returned names with the initializer, then inspect the matching subscription and queue attributes through the same endpoint. An empty response may indicate the wrong Region, absent initialization, or genuinely no resources. Diagnose before inventing replacements.

Checkpoint

Would a successful list prove a deposit reached Ledger? No; it verifies resource visibility, not message content or processing. Would local IAM behavior prove a production policy works? No; validate actual AWS policy behavior separately when the cloud track begins.

Keep a short endpoint/version/Region/resource note. Cleanup later uses the named Compose project and its explicit data-retention choice. After foundations, follow MicroBank setup before provisioning its local dependencies.

References: LocalStack setup↗, SNS support↗, SQS support↗, and MicroBank initializer↗.