In Flex Consumption, regular blob trigger functions will no longer be supported. As such, EventGrid-based blob trigger functions will be the only option. It is therefore imperative to ensure that the local development (as well as deployment) story for this scenario is as smooth and user-friendly as possible.
As it stands, post deployment, as opposed to a regular blob trigger function, the user needs to do extra configuration in Azure to hook up the blob trigger function to an EventGrid service listener, as can be specified here in documentation here.
We want to simplify and streamline this process as much as possible, so that the user has to do less of this configuration manually, and we do as much of it from the VSCode deployment story as possible. The ideal scenario is to reach such parity with the normal blob trigger deployment story that the customer won't even have to know that their blob trigger function is EventGrid-based.
In Flex Consumption, regular blob trigger functions will no longer be supported. As such, EventGrid-based blob trigger functions will be the only option. It is therefore imperative to ensure that the local development (as well as deployment) story for this scenario is as smooth and user-friendly as possible.
As it stands, post deployment, as opposed to a regular blob trigger function, the user needs to do extra configuration in Azure to hook up the blob trigger function to an EventGrid service listener, as can be specified here in documentation here.
We want to simplify and streamline this process as much as possible, so that the user has to do less of this configuration manually, and we do as much of it from the VSCode deployment story as possible. The ideal scenario is to reach such parity with the normal blob trigger deployment story that the customer won't even have to know that their blob trigger function is EventGrid-based.