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 pipx
      • 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
      • Fixtures
      • Public Folder
    • 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 Create Contexts
      • How to Create Scenarios
        • Creating from the UI
        • Creating from the CLI
      • How to Create Requests
      • How to Customize Recordings
        • Customizing with Lifecycle Hooks
    • How to Update Requests
      • Editing from the UI
      • Editing with Snapshots
      • How to Update Scenarios
        • Updating with Overwrite
        • Updating with Replay
      • Updating with Replay
        • Replaying from the UI
        • Replaying from the CLI
        • How to Customize Replays
          • Customizing with Lifecycle Hooks
      • Updating with Open API
    • How to Mock APIs
      • How to Enable Mocking
        • Enabling from the UI
        • Enabling from the CLI
      • How to Snapshot Requests
        • Deleting Snapshots
        • Sharing Snapshots
      • How to Use Fixtures
      • How to Customize Mocking
        • Customizing with Lifecycle Hooks
        • Customizing with Request Headers
      • Troubleshooting
    • How to Replay Requests
      • Replay with the UI
      • Replay with the CLI
    • How to Integrate E2E Testing
      • How to Scaffold an App
        • Scaffolding a Service
        • Customizing a Workflow
          • Customizing Container Services
          • Customizing Lifecycle Hooks
          • Customizing Init Scripts
          • Customizing Configure Scripts
          • Customizing Makefile
        • Troubleshooting
      • How to Run a Workflow
        • Running with CLI command
        • Running with Make
        • Troubleshooting
          • Validating
      • How to Stop a Workflow
        • Stopping with CLI command
        • Stopping with Make
      • How to Update a Scaffold
        • Deleting a Service
      • FAQ
  • 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

PreviousScaffoldNextValidation

Last updated 1 month ago

Was this helpful?

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 .

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

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

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:

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:

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

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

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

To learn more about the purpose of each file, see

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

Lifecycle Hooks
Fixtures
Public Folder
snapshot apply command
Scaffolding a Service
Service containers and files they depend on
Core services outlined in orange
here
here