Stoobly Docs
  • Introduction
  • Use Cases
    • Generate Mock APIs
      • Empower Development
      • Scale API Testing
    • Enable E2E Testing
  • FAQ
    • Recording
    • Mocking
    • Terminology
  • Getting Started
    • Installing the Agent
      • Installation with pip
      • Installation with Docker
  • Core Concepts
    • Agent
      • Intercept Modes
        • Mocking
        • Recording
      • Lifecycle Hooks
      • Proxy Settings
        • Data Rules
        • Firewall Rules
        • Rewrite Rules
        • Match Rules
    • Context
    • Mock API
      • Request
        • Response
        • Replay History
      • Scenarios
      • Snapshots
    • Scaffold
      • Service
      • Validation
      • Workflow
  • Guides
    • How to Run the Agent
      • Run with CLI
      • Run with Docker
    • How to Configure the Agent
      • Forward Proxy
        • Enable HTTPS Traffic
      • Reverse Proxy
    • How to Record Requests
      • Recording from the UI
      • Recording from the CLI
    • How to Mock APIs
      • How to Mock Requests
        • Mocking from the UI
        • Mocking from the CLI
      • How to Create Scenarios
        • Creating from the UI
        • Creating from the CLI
      • How to Snapshot Requests
        • Deleting Snapshots
        • Sharing Snapshots
      • How to Create Lifecycle Hooks
        • Setting Credentials
        • Setting Responses
      • How to Update Requests
        • Editing from the UI
        • Editing with Snapshots
        • Replaying from the UI
        • Replaying from the CLI
        • Updating with Open API
      • How to Update Scenarios
        • Updating from the UI
        • Updating from the CLI
      • How to Create Contexts
    • How to Replay Requests
      • Replay with the UI
      • Replay with the CLI
    • How to Integrate E2E Testing
      • How to Scaffold an App
      • How to Scaffold a Service
      • How to Run a Workflow
        • Running with CLI command
        • Running with Make
      • How to Stop a Workflow
        • Stopping with CLI command
        • Stopping with Make
      • How to Customize a Workflow
        • Adding Custom Container Services
        • Adding Custom Lifecycle Hooks
        • Adding Custom Init Scripts
        • Adding Custom Configure Scripts
      • How to Validate a Workflow
      • How to Troubleshoot
  • Developer Guide
    • Installation from Source
    • Submitting Change Requests
    • Releases
  • Experimental
    • Experimental Features
      • Aliases
      • Endpoints
      • API Testing
        • Getting Started
        • Configuration
          • Assign
          • Lifecycle Hooks
          • Trace
      • Optional Components
Powered by GitBook
On this page
  • Properties
  • Containers
  • init
  • configure
  • proxy
  • custom
  • Core Services
  • build
  • gateway
  • stoobly-ui
  • entrypoint
  • Get Started

Was this helpful?

  1. Core Concepts
  2. Scaffold

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 .stooblyfolder 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.

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. Defaults to no workflows.

Containers

A service is comprised of the following containers:

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 initscript. 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:

It also provides a fixtures.yml file that enables mapping URL's to static responses stored in files.

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:

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

PreviousScaffoldNextValidation

Last updated 5 days ago

Was this helpful?

Lifecycle Hooks
How to Scaffold a Service
Service containers and files they depend on
Core services outlined in orange