Service

A service can be a part of one or more workflows. When a workflow is run, only services that are a part of the workflow will be started.

Properties

app-dir-path

Defaults to the current working directory. Configures where the scaffolded service files are created.

detached

Configures whether the .stoobly folder in the context directory path gets mounted. If the flag is set, a separate non-persistent Stoobly context gets created. The context directory path is specified when a workflow is run. To learn more see here.

hostname

If a hostname for the service is specified, a proxy container will also be started when the service is instatiated as part of a workflow run.

priority

Configures the order which the service is run. Ranges from 0 to 10. If a service is configured with a priority of 0, then it will run before services with a greater priority value.

workflow

Configures which workflows the service belongs to, allowed values are record , mock, test. Defaults to no workflows.

Containers

To learn more about the purpose of each file, see here

When service workflow is run, the following containers are started:

Service containers and files they depend on

init

The init container is the first container that gets run when a service starts. If it fails, the configure container will not run. The first script that runs is the maintained .init script which then runs the customizable init script. Only the .initscript will be overriten when the application is re-scaffolded.

configure

The init container is the second container that gets run when a service starts. If it fails, the proxy container will not run. The first script that runs is the maintained .configure script which then runs the customizable configurescript. Only the .configurescript will be overriten when the application is re-scaffolded. The purpose of this step is to configure Stoobly proxy settings.

proxy

This container only runs if a hostname property is configured

The proxy container is the last container that gets run. It provides a lifecycle_hooks.pyscript that enables customization of requests and response at different points of their lifecycles. To learn more:

Lifecycle Hooks

For mock and test workflows, the following are also provided:

• fixtures.yml enables mapping URL's to static responses stored in files. To learn more:

Fixtures

• public folder enables defining mock request paths and responses using files stored in this folder. To learn more:

Public Folder

custom

Custom containers can be defined in the provided docker-compose.yml.

The profilesand networks properties need to be set accordingly

Core Services

Core services are services maintained by Stoobly and maintains the following start order:

Core services outlined in orange

build

Is the first service to be started and runs the snapshot apply command to build mocks.

gateway

Is responsible for routing requests from the host to the appropriate custom service.

stoobly-ui

Provides a UI on http://localhost:4200 to manage mocks and proxy configuration.

entrypoint

Is the last service to be started and has the purpose of being extended in the provided docker-compose.yml with custom functionality.

Get Started

Scaffolding a Service