You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I recently pushed changes to @salaboy's Pizza demo application (see salaboy/pizza#13) to demonstrate how to ease local testing of component dependencies.
Typically, the Store component relies on 2 other ones: Kitchen and Delivery that are expected to be reached via a mesh of sidecars like illustrated below:
In a local development situation, I succeeded - thanks to this PR on java-sdk - in replacing the remote dependencies with local mocks powered by Microcks:
Microcks has a Testcontainers integration, is lightweight and provides mocks + contract-testing for REST, gRPC, GraphQL, Kafka and others, it's an ideal companion for local-testing complex applications made with Dapr.
Even if the above scenario is working well for simple REST services, I'd like to be able to also test this other scenario where the local Dapr sidecar would connect to a sidecars mesh to test/validate advanced Dapr features (security, rate limiting, retries, ...):
Unfortunately, as of today, the above topology cannot be executed. As Microcks is providing simulations for many mocks, the different endpoints it manages are exposed using different subpaths (typically something like http://microcks:8080/rest/<service name>/<service version>) and I didn't find a way to provide subpath or path prefix to the DaprContainer when connecting it to the local application.
Describe the proposal
I'd like to have the ability to do something like:
// Start a sidecar and connect it to the simulation provided by// microcks on http://microcks:8080/rest/Pizza Kitchen/1.0.0kitchenContainer = newDaprContainer("daprio/daprd")
.withAppName("kitchen-service")
.withAppPort(8080)
.withAppChannelAddress("microcks")
.withAppPathPrefix("/rest/Pizza Kitchen/1.0.0")
.withNetwork(network);
// Start a sidecar and connect it to the simulation provided by// microcks on http://microcks:8080/rest/Pizza Delivery/1.0.0deliveryContainer = newDaprContainer("daprio/daprd")
.withAppName("delivery-service")
.withAppPort(8080)
.withAppChannelAddress("microcks")
.withAppPathPrefix("/rest/Pizza Delivery/1.0.0")
.withNetwork(network);
@lbroudoux thanks for writing this up, I will try to bring the Dapr community to discuss this. I believe that this also highlights the versioning aspect of service to service communications. Here with the path prefix we are pointing to the contracts of a very specific version of the Kitchen and Delivery services.
Context
I recently pushed changes to @salaboy's Pizza demo application (see salaboy/pizza#13) to demonstrate how to ease local testing of component dependencies.
Typically, the
Store
component relies on 2 other ones:Kitchen
andDelivery
that are expected to be reached via a mesh of sidecars like illustrated below:In a local development situation, I succeeded - thanks to this PR on java-sdk - in replacing the remote dependencies with local mocks powered by Microcks:
Microcks has a Testcontainers integration, is lightweight and provides mocks + contract-testing for REST, gRPC, GraphQL, Kafka and others, it's an ideal companion for local-testing complex applications made with Dapr.
Even if the above scenario is working well for simple REST services, I'd like to be able to also test this other scenario where the local Dapr sidecar would connect to a sidecars mesh to test/validate advanced Dapr features (security, rate limiting, retries, ...):
Unfortunately, as of today, the above topology cannot be executed. As Microcks is providing simulations for many mocks, the different endpoints it manages are exposed using different subpaths (typically something like
http://microcks:8080/rest/<service name>/<service version>
) and I didn't find a way to provide subpath or path prefix to theDaprContainer
when connecting it to the local application.Describe the proposal
I'd like to have the ability to do something like:
I had a quick look at https://docs.dapr.io/concepts/dapr-services/sidecar/ and it seems like this would also require creating a new flag on the sidecar to enable adding this path prefix.
What do you think of this use-case?
The text was updated successfully, but these errors were encountered: