Add support for Dapr to callback into App via a different endpoint

[artursouza]

Decouple App API from Dapr callback API

Today Dapr is calling back into the same API endpoint that is used for the App's main functionality. There are different requirements, including security, for Dapr callback and the App's exposed API. Dapr should have a parameter to determine an optional callback api port that can be used instead of the app's main port.

[yaron2]

I don't understand.. what is the port here? And what's the actual proposal? Can you give a concrete example of what you mean?

[artursouza]

The main app can have APIs like /order/new, /customers/list, etc. These APIs are exposed to the frontend, for example. For callback functionality for Dapr, like in PubSub or Actors, for example, the App can choose to expose another endpoint.

[yaron2]

Ok, what you just said is the situation today. So what's the proposal?

[artursouza]

If this is possible today, then there is nothing to be changed. Let me close this.

[yaron2]

But you opened it because of an observation.. so I want to understand exactly what it is.

Do you mean the app might have two apis on two different ports?

[artursouza]

The app might have two ports: each serving a different endpoint.

[yaron2]

Oh ok, so it is indeed supported. You can tell Dapr today which port the app is listening on.

Ok to close?

[LMWF]

You can tell Dapr today which port the app is listening on.

How is this done today when there's multiple? Is there an example configuration?

[yaron2]

If the app has 2 servers with different ports, you pass the port designated for Dapr via the --app-port flag.

[artursouza]

I understood this before closing it earlier. Good to make it clear, though. Maybe we can update this issue to make this obvious in the docs.

[yaron2]

The --app-port flag is used a lot in the docs. Do you think there's a place to show case this more? if so, lets open an issue on docs. The --app-port flag is mandatory if the app needs Dapr to call into it.

[artursouza]

I am not talking about the port flag, I am talking about making it clear that this is how Dapr should be integrated: creating a new endpoint for Dapr. In the examples, the apps only have one API, so it can lead to the conclusion that Dapr is coupled with the apps' api. It is clear to me now, but someone going through the documentation might take a while to understand this.

[yaron2]

In the majority of cases users will only use one API, that's also how we observed people using Dapr until now.

We can add a How-To or sample of an app with two endpoints, each with a different port.

[artursouza]

How-To is a good idea. Once the API has authentication - which I would expect for a production scenario, it would stop working, not? Plus, by decoupling the APIs, the app can make use of grpc for Dapr while keeping this http API for the frontend. IMO, a Dapr specific endpoint should be the recommended solution for production scenarios. I guess we will learn more once customers start deploying Dapr in production.