# 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

<mark style="color:green;">`POST`</mark> `http://localhost:3000/todos`

#### Request Body

| Name                                    | Type   | Description |
| --------------------------------------- | ------ | ----------- |
| description                             | String |             |
| title<mark style="color:red;">\*</mark> | String |             |

{% tabs %}
{% tab title="200: OK " %}

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

{% endtab %}
{% endtabs %}

## Describe a todo item

<mark style="color:blue;">`GET`</mark> `http://localhost:3000/todos/:todoID`

{% tabs %}
{% tab title="200: OK " %}

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

{% endtab %}
{% endtabs %}

## Delete a todo item

<mark style="color:red;">`DELETE`</mark> `http://localhost:3000/todos/:todoID`

{% tabs %}
{% tab title="200: OK " %}

{% endtab %}
{% endtabs %}

We can first create a scenario:

```bash
stoobly-agent scenario create create-todo-v1
```

And then record requests into it:

```sh
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:

```sh
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.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.stoobly.com/use-cases/generate-mock-apis/empower-development.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.