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:
Sending a POST request to create the resource
Sending a GET request to confirm the resource was created
Sending a DELETE request to reset the system state
With Stoobly, we can record these requests into a scenario. With scenarios, we can:
Replay them to retrigger the same sequence of requests
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
description
String
title*
String
Describe a todo item
GET
http://localhost:3000/todos/:todoID
Delete a todo item
DELETE
http://localhost:3000/todos/:todoID
We can first create a scenario:
And then record requests into it:
Once we have recorded requests into a scenario, we can replay with:
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:
Record requests to a scenario
Toggle Stoobly to mock requests using the recorded scenario
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:
Decreased request latency
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.
Last updated