API Development

Flexible development environment configurations

Mesh Dynamics supports several common development setups to provide developers full flexibility in how they debug microservices APIs. Run the service being developed in your IDE, while other services are either mocked or live in a dev cluster. Use full capabilities of your IDE to develop and debug your code, and get API observability of egress requests from your service. However, should you need to run your service in the dev cluster, Mesh Dynamics supports that as well. 

Service in IDE with egress requests served from dev cluster

Services-in-dev-cluster.png

This configuration uses dev clusters for upstream services. Developers debug the APIs in their IDE. The egress requests are routed from the IDE to the API Studio, which then forwards the request to the dev cluster. Mesh Dynamics automatically generates mocks as egress requests are served by the dev cluster. The auto-generated mocks can be utilized when the dev cluster is unavailable. 

Service running in IDE with all egress requests mocked

Mocks-in-cloud.png

Mesh Dynamics enables developers debug their APIs in their IDE while mocking all upstream services. This is useful when upstream services are changing, or the dev cluster is unstable. During development, you can use either the learned mocks, or mocks created manually.


A rich set of mocks can be learned if Mesh Dynamics listeners are deployed in an environment such as the CI environment where Mesh Dynamics can observe reliable API request-response data to automatically learn the API mocks.

Service in dev cluster along with all other services

all-Services-in-dev-cluster.png

All services are running in dev cluster. Out of the box, you can view responses from the target service only. Mesh Dynamics listeners must be deployed in the dev cluster to observe the egress requests from the service being modified.

Developer features and benefits

Diagnose API failures with observability and trace-based analysis

website-egress-trace.png
  • For any request in IDE, see egress requests and responses.

  • Analyze full request execution traces from CI locally using data from failed requests in CI.

  • Diagnose problems by analyzing the trace.

  • Identify changes across CI runs.

Eliminate dependency on having the right upstream services with continuously learned mocks

mesh-config-diag-1.png

How often have you been surprised by an unexpected version of an upstream service in the dev cluster? Stop being blocked by the availability of the right services in the dev cluster. Mesh Dynamics enables completely parallel development with up-to-date mocks based on continuous learning.

  • Mocks automatically learned, both requests and responses, for requests run from Dev Studio.

  • Observed service interactions for CI test cases are learned if Mesh Dynamics listeners are deployed in CI pipeline

  • Create/update mock in Dev Studio before a service is available.

  • Stable mocks throughout the development cycle -- no surprises.

Seamlessly switch between mocks and live services without altering your workflow

egress-request-routing.png
  • Switch between using mocks or a dev cluster with a simple configuration change.

  • Switch between the two environments without altering your workflow.

Review change in functionality fast using GitHub code comparison style interface

dev-refactor-4.png

Easily identify changes to:

  • response from API being developed

  • egress requests to other services

  • responses from external services

  • API behavior across time 

Shift-Left: Reduce CI failures by testing before code submit

Avoid discovering bugs late after the new code hits the CI stage. Mesh Dynamics enables developers to simulate CI tests for their service locally before submitting code reducing CI failures.