Empower Development

In order to empower development, we want to:

• Easily re-create application state

• Reduce environment instability

Recreating Application State

Working on a feature or fixing a bug often depends on triggering a sequence of requests to drive your application to a certain state. For example, when working on a new API to create a resource, we find ourselves:

1. Sending a POST request to create the resource

2. Sending a GET request to confirm the resource was created

3. Sending a DELETE request to reset the system state

With Stoobly, we can record these requests into a scenario. With scenarios, we can:

1. Replay them to retrigger the same sequence of requests

2. Share them with teammates so they replicate the same results

For example given the following imaginary endpoints:

Create a todo item

POST http://localhost:3000/todos

Request Body

Name	Type	Description
description	String
title*	String

200: OK

{
    description: '',
    id: 1,
    title: '',
}

Describe a todo item

GET http://localhost:3000/todos/:todoID

200: OK

{
    description: '',
    id: 1,
    title: '',
}

Delete a todo item

DELETE http://localhost:3000/todos/:todoID

200: OK

We can first create a scenario:

stoobly-agent scenario create create-todo-v1

And then record requests into it:

stoobly-agent record \
    -X POST \
    -d "description=demo&title=test" \
    --scenario-key <SCENARIO-KEY> \
    http://localhost:3000/todos

stoobly-agent record \
    --scenario-key <SCENARIO-KEY> \
    http://localhost:3000/todos/<TODO-ID>

Once we have recorded requests into a scenario, we can replay with:

stoobly-agent scenario replay <SCENARIO-KEY>

Reduce Environment Instability

Depending on a live API service maintained by another can lead to bugs, intermittent failures or latency spikes outside of your control. For example, let's say we want to create a UI form that uses the above API's to create, view, and delete a todo item. Because these features depend on the API, if the service goes down, the UI is unable to progress with work. To reduce downtime, we can use Stoobly to:

1. Record requests to a scenario

2. Toggle Stoobly to mock requests using the recorded scenario

3. Incoming requests that were previously recorded will now return mocked responses

In addition to reducing downtime, using a mock service instead of a shared service for development also imparts folowing benefits:

1. Decreased request latency

2. Consistent responses

A shared API service means other clients are modifying the application's state. The more requests sent to the service, the higher the latency. Furthermore, frequently changing application state can lead to inconsistent responses.