search

Azure / azure-functions-dapr-extension

Extension for interacting with Dapr APIs from an Azure Function
MIT License
100 stars 34 forks source link

Requesting Feedback about DAPR extension for Functions #88

Open rabollin opened 1 year ago

rabollin commented 1 year ago

Hello everyone - We have been working on adding few more abilities to this DAPR extension for functions and release the next version of it in a month time. We would like to seek your feedback on the extension about immediate features you would like to see, also any major challenges or issues with you have been facing with the extension if it was already tried by you. If you have any inputs that you would like to share, please post it as an issue in this repo.

san-chang commented 1 year ago

This extension is a great solution for event driven system that already integration with dapr.

Dose your team has a plan to move it from preview to a release version?

rabollin commented 1 year ago

Hi @san-chang - Yes, the next release of extension thar we are targeting to be production ready version.

KaiWalter commented 1 year ago

@rabollin @cgillum - sorry for being for late to the show. I could see some value for us in using Dapr Actors from within various Functions flows. Is this anywhere on the roadmap?

rabollin commented 1 year ago

@KaiWalter - The new extension that is getting released do not have support for Actors yet. It is great to know that you have business cases for using DAPR Actors with Function workloads. Would you be able to share the usecases or the scenarios that needs actors to help to evaluate Actors need in Functions further.

KaiWalter commented 1 year ago

@rabollin it goes like this:

  1. integration platform gets request from customer portal (sales order, technical service request, update software license, process payment, ...); customer portal adds callback address for that particular request to be notified on success or failure
  2. integration platform stores and converts request and sends it to 1..n relevant backends; integration platform waits for backends to respond
  3. when all sub-requests are reported back to integration platform, notify customer portal with success or failure
  4. when one of the backends does not respond or do not acknowledge receiving request within a certain threshold (e.g. 1h), logic should be executed to (depending on case) notify customer portal and other involved backends to rollback their process and/or notify agents/action groups to handle the problem

Currently we create No 2. in Azure Storage or CosmosDB and also collect 3.+4. in that store. Apart from having no guarantee that arbitrarily incoming responses from backends for one item do not overwrite each other's state (which we solve by funneling updates down into a single queue to have those in sequence at least), I was wondering whether Dapr Actor's reminder feature could help us to to improve No 4. by handing off the tracking process for each item (service request, order, ...) to such a reminder and get a Function triggered to work on such a reminder.

We are aware that you can achieve that with all sorts of non-Functions, non-Dapr ways, but again we want to extend our simplified programming model based on Functions, that we utilize in that team, from stateless to also such stateful cases which involve much more coding currently.

Phiph commented 1 year ago

So far the work that's already gone into the package with the current set of input output bindings are good enough for a v1.

I'd like to see more complete examples of how to set up components in the Azure Function Runtime, as that doesn't seem 100% clear to me just yet. Do I have to add it in the file system when I publish, or is it a component like I register it in ACA. Things like that yanno - minor refinements which I'm sure will come with time :)

ASHIQUEMD commented 1 year ago

@Phiph, thank you for the input, we have Microsoft public documentation coming in, which should have all these steps on setting up Dapr components along with how to deploy functions in ACA with Dapr.

We have added a sample bicep templates to deploy Azure Functions with Dapr extension on ACA, I would really appreciate your input on this.

Do I have to add it in the file system when I publish, or is it a component like I register it in ACA.

It will be Dapr components registered in ACA.

Cheers!

Phiph commented 1 year ago

ohhh right that makes sense! Thanks for the samples!

So the function runtime needs to know which ACE (managedenvironmentId) it targets to then get the component's registered to that given environment, so it doesn't need a Service Plan, as it uses the preview Azure Functions in ACE?

I'll have a review and a go at the bicep samples shortly - thanks!

ASHIQUEMD commented 1 year ago

So the function runtime needs to know which ACE (managedenvironmentId) it targets to then get the component's registered to that given environment, so it doesn't need a Service Plan, as it uses the preview Azure Functions in ACE?

That is correct.