Workflow

A workflow groups configurations for services to perform distinct use cases. By default, Stoobly provides configurations for the record, mock and test workflows.

Background

To learn more about the role of individual services, see:

Service

To run a workflow, see:

How to Run a Workflow

To validate a workflow, see:

Validation

File Structure

To learn how each file is used, see here.

Any hidden file will be overritten when the scaffold service create command is rerun.

bin/init

First script that executes when a workflow runs. Should contain any commands needed for the service to initialize.

bin/.init

Maintained file that will be overriden on scaffold create.

bin/configure

Second script that executes when a workflow runs. Should contain configuration commands for Stoobly. See firewall rules, match rules, and rewrite rules.

bin/.configure

Maintained file that will be overriden on scaffold create.

docker-compose.yml

Custom docker-compose.yml file. Container services defined in this should should include:

• Respective <WORKFLOW-NAME> under the profiles property

• Either app.egress or app.ingress under the networks property

.docker-compose.<WORKFLOW-NAME>.yml

Maintained file that will be overriden on scaffold create.

fixtures.yml

Enables defining mock responses for specific URL patterns. To learn more see here.

lifecycle_hooks.py

Enables reading and modifying requests during specific points in their lifecycle. To learn more see here.

public

Enables defining mock request paths and responses using files stored in this folder. To learn more see here.

Core Workflows

Record

Flow diagram for recording requests

The journey of a request:

1. A request gets sent from the host e.g. browser or cURL

2. Gets sent to the gateway service

3. Gateway service routes the request based on hostname

4. Request gets intercepted by Stoobly running as a proxy

   1. Lifecycle hooks get triggered

5. Stoobly reverse proxies the request to the local or external API

6. On response, Stoobly records the request to its respective .stooblyfolder

   1. Lifecycle hooks get triggered

Mock

Flow diagram for mocking requests

The journey of a request:

1. A request gets sent from the host e.g. browser or cURL

2. Gets sent to the gateway service

3. Gateway service routes the request based on hostname

4. Request gets intercepted by Stoobly running as a proxy

   1. Lifecycle hooks get triggered

5. Stoobly mocks requests if it has been previously recorded. If the request is not found, it can conditionally reverse proxy the request to the local or external API

   1. Lifecycle hooks get triggered

Test

Flow diagram for testing an application that sends requests

The journey of a request:

1. A request gets sent from the entrypoint service

2. Gateway service routes the request based on hostname

3. Request gets intercepted by Stoobly running as a proxy

   1. Lifecycle hooks get triggered

4. Stoobly mocks requests if it has been previously recorded. If the request is not found, it can conditionally reverse proxy the request to the local or external API

   1. Lifecycle hooks get triggered