1
votes

In Azure function, you can create a function listening to a certain change of events such as message bus, blob storage, etc...

if you are using azure function, and your objectives are to process something by listening to event such as message bus, blob storage , or any other built in trigger, is there any reason why you want to put event grid in the middle layer ? ie, instead of azure function listening to blob storage change directly, you want the azure function to listen to an event grid that is listening to a blob storage change event.

Thanks

2
The Azure Event Grid is a Pub/Sub eventing model for fast and reliable delivering your event interest to the subscriber in the PUSH manner. In other words, there is no listeners. In opposite to the BlobTrigger function, where the underlying logic is based on the periodically container polling for scanning its differences. More details about the BlobTrigger limitation and its alternatives: docs.microsoft.com/en-us/azure/azure-functions/…Roman Kiss

2 Answers

1
votes

It depends on what your needs are. Taking Storage and blobs, if you only need to be notified whenever a blob is created, matching whatever path, name, extension and other filters you have configured with your BlobTrigger, then it doesn't make sense to use EventGrid.

But if you need to configure a Function to also work with multiple Storage accounts, have a need for advanced filtering not supported by the BlobTrigger, or trigger on special events (e.g. when a directory is created, deleted or renamed), then you need EventGrid.

A slightly (but not too far fetched) example could be the following:

Consider that you need a function to trigger whenever a blob is created in storage 1, 2, 3 ... n. In fact, it could be an arbitrary number of different storages, and it changes over time. Now you need to either have a function for each storage, with a BlobTrigger defined, or one, single function, with many BlobTrigger defined, and a lot of connection strings configured in your application settings. This is obviously not very convenient to maintain as you'd have to change the function every time the arbitrary number of storages you need to trigger for changes (primarily if new storages are added).

EventGrid to the rescue. You can now manage what is triggering the function with subscriptions, one for each storage, without changing the code for your function. You would of course need a different approach for communicating with the storage rather than the usual connection string; you'd probably need something like StorageManagementClient. Of course you'd lose the automated blob bindings. This could be circumvented by implementing your own extension (custom binding). I've already written an answer that covers how to do that (albeit it being for binding arrays/lists to HttpTrigger).

You could probably also automate the subscription management with EventGrid (or rather, notify some piece of code to create the subscription). Example: All the storages are collectively in a single resource group. EventGrid supports triggers for whenever something is changed in a resource group, and with an EventGrid subscription's advanced filters, you should be able to configure it to only trigger whenever a storage account is created... or deleted.

In any case, it is really a question of need. And the above example might be far fetched. But there are use cases that Functions won't support natively, where something like EventGrid can make it work.

-2
votes

Yes, it's depend upon the scenario.