10. Common Uses

Updated 2 months ago by Rahul Lahiri

In this section, we will cover the common use cases using the sample app provided.

Debugging services

As outlined in the previous chapters, the API Studio can be used to send a request to the service in an IDE, observe the behavior of the API, and debug the code. The egress requests from the service in the IDE should be routed back to API Studio. In the API Studio, you have the choice of sending the egress requests either to live services in the cloud, or to the mock services provided by Mesh Dynamics.

  1. Identify changes as you make code changes: Use the diff capability to identify changes in responses as you make code changes. Save a request together with its response. Run the saved request again after making code changes, and use the diff to identify the impact of the code changes -- for both the API response as well as the egress requests.
  2. Validate API behavior: Validate API behavior for a variety of conditions and use cases. Simulate corner cases by varying the arguments, and also by creating specific mock behaviors.
  3. Identify changes from past behavior: Identify differences in API behavior across time either by pinnig and comparing any two saved requests (from the API Catalog or from your collections), or by selecting a saved trace and running the API request against a live service.
Save examples of expected API behavior: You can save a complete trace for any request to a collection using the ‘Save’ button. We recommend adding all meaningful traces for your APIs to collections so that you can use the data later for mocks.

Observability

API Studio provides full visibility into how the API under development is interacting with external APIs without any additional instrumentation. Just route the egress requests back to the API Studio, and from there to the service in the cloud or the auto-created mocks. You can see the full details of each request and response -- for both the ingress request and the egress requests. You can also compare them with prior stored examples to detect changes in API functionality.

Auto-created mocks

Use auto-created mocks when upstream services in dev cluster are buggy or unavailable. Mesh Dynamics automatically creates mocks for all requests stored in any collection, or captured from the CI pipeline (when Mesh Dynamics agents are deployed). When the upstream stream APIs in the dev cluster are under development or buggy, just switch the egress request configuration to use the mocks created automatically from the requests saved to collections. This eliminates the complete dependence on the availability of stable upstream services in the dev cluster.

Save examples of expected API behavior: We recommend adding all meaningful traces for your APIs to collections so that you can generate a rich set of data for API mocks.
Create API mocks from your history: In case you forget to add your requests to a collection when you run them, you can still leverage those requests later by retrieving the traces from your history and saving it to a collection.
Help the consumers of your API: Traces saved by you to collections can be also used as mocks by downstream consumers of your API.

API Studio provides complete flexibility over which upstream services are mocked and which are live.

Parallel development

Create mocks when upstream APIs are not yet ready. API Studio unblocks parallel development of services with API dependencies by removing the dependency on the availability of the new/updated upstream APIs. Create API mocks from stored traces based on the contract. Set the egress request configuration to use the hand-crafted mocks until the updated service is available in the dev cluster. Eliminate the dependence on the availability of new/updated upstream services in the dev cluster before validating downstream services.

How did we do?