Dependencies (local, cloud or mock)
A dependency is a core that a micro calls over REST. When you launch a scenario, for each dependency you choose how to resolve it: Aseptic rewrites the URL that micro uses to call, without touching the repo’s code.
The three resolutions
Section titled “The three resolutions”| Option | What it does | When to use it |
|---|---|---|
| local | Points to the peer launched in the same scenario | Test the real communication between your micros |
| cloud | Points to your cloud environment (requires a connection to its network) | Use a core you don’t want to launch |
| mock | Points to Aseptic’s mock server | Work without a cloud connection or launching the core |
For local resolution to work, the target core has to be part of the scenario. If it isn’t, Aseptic warns you.
How it is injected
Section titled “How it is injected”Each dependency declares which configuration property to rewrite (for example
app.rest-client.pagos.url). At startup, Aseptic computes the effective URL according
to the chosen resolution and injects it as configuration, with the correct
perspective (host or container) depending on where the client runs. The micro’s repo
is not modified.
Which targets each dependency accepts
Section titled “Which targets each dependency accepts”Any declared dependency can be resolved to cloud or mock, and to local when its service is part of the scenario. There are no “fixed” dependencies: an API manager, a gateway or authentication can be mocked too.
The “requires connection” notice
Section titled “The “requires connection” notice”If any dependency is resolved against the cloud, the app warns that the scenario
requires a connection to the network where that cloud lives, and the cloud
credentials (${creds.x}) must be defined.
Changing the resolution
Section titled “Changing the resolution”In the Scenarios section, the Dependencies panel has a local/cloud/mock selector per dependency. You can change it:
- Before launching: it is saved as part of the scenario.
- With the scenario running: many resolutions are applied hot, without a restart; others restart the affected micro. The app tells you which of the two happened.
From the CLI, the equivalent is aseptic set-resolution <dep> <local|cloud|mock> (or
--resolve at startup, as a one-off override for that invocation).
Relationship with mocks
Section titled “Relationship with mocks”When a dependency is resolved as mock, Aseptic serves the responses you have defined for that service in the Mocks section. You don’t need to launch anything to edit them: the mock catalog lives on disk and is served with hot reload.