dapr

dapr copied to clipboard

In what area(s)?

/area runtime

Ask your question here

I've been using Dapr for a company project with great success so far. It really has simplified many things that we used to do ourselves "by hand".

We have developed/deployed a couple of micro-services (.NET) in a self-hosted environment, using actors, workflows and also integrated with Zipkin and other tools. Everything working fine so far.

At the other hand, we have an SPA UI (Angular) that consumes these micro-services through an API Gateway. We've chosen KrakenD as our API Gateway and it has worked great.

The thing is that now that we want to scale our micro-services and run more instances (App + Dapr Sidecar), I'm wondering what are the "best practices" in terms of API Gateway / Dapr interactions.

In the case of service-to-service calls (https://docs.dapr.io/developing-applications/building-blocks/service-invocation/service-invocation-overview/) there are a lot of features provided by Dapr out-of-the-box that I would like to keep when working with the API Gateway (for example, tracing, observability, resiliency, etc.). So the question is: should I call my services through the Dapr sidecar or directly?

As of now, we've been calling our services this way (with no tracing unless the service being called, internally calls another service using the sidecar):

Angular App <=> KrakenD <=> My Single Microservice Instance

But I'm wondering if I should call my services this way:

Angular App <=> KrakenD <=> Dapr Sidecar <=> My Microservice Instances

The later approach gains me the out-of-the-box features that I mentioned earlier, but I'm not sure if this is a good practice or not. Can someone point me in the right direction?

Thank you,

Andy

Anyone? :)

This issue has been automatically marked as stale because it has not had activity in the last 60 days. It will be closed in the next 7 days unless it is tagged (pinned, good first issue, help wanted or triaged/resolved) or other activity occurs. Thank you for your contributions.

I have the same question, what are the ways to do this ? Should there be any best practices, please suggest any of them or propose an optimal solution for this scenario

This issue has been automatically marked as stale because it has not had activity in the last 60 days. It will be closed in the next 7 days unless it is tagged (pinned, good first issue, help wanted or triaged/resolved) or other activity occurs. Thank you for your contributions.

This issue has been automatically closed because it has not had activity in the last 67 days. If this issue is still valid, please ping a maintainer and ask them to label it as pinned, good first issue, help wanted or triaged/resolved. Thank you for your contributions.

Wow, thought I'd come across the perfect github posting and I was going to get my question answered right away... but then no responses.

I'm about to rewrite three projects using kubernetes scaling techniques. After writing up an architecture document and realizing I'll be writing a kind of reusable architecture for creating apis, did some searching to see if I might be reinventing the wheel. Dapr looks like it's doing everything I planned plus a little more. Considering dapr. Looking into requirements. Meets my requirements for home projects at work though an api gateway is required... guess I'll keep searching for the answer of example dapr integration with common api gateways.

@lknite - since service to service communication goes to the dapr sidecar, it should be as simple as doing service invocation through its own sidecar.

This issue has been automatically marked as stale because it has not had activity in the last 60 days. It will be closed in the next 7 days unless it is tagged (pinned, good first issue, help wanted or triaged/resolved) or other activity occurs. Thank you for your contributions.

This issue has been automatically closed because it has not had activity in the last 67 days. If this issue is still valid, please ping a maintainer and ask them to label it as pinned, good first issue, help wanted or triaged/resolved. Thank you for your contributions.