[Azure Functions] - Storage Queue vs Event Grid trigger

[meanin]

Cześć,
ogarniam sobie rozwiązanie z Azure Samples i mam taką zagwostkę: Czy są jakieś za lub przeciw usunięcia z tej architektury storage queue? Po usunięciu tego klocka można by reagować w AF na Event Grid trigger (np. Microsoft.Storage.BlobCreated). Oczywiście Blob trigger jest tutaj pominięty ze względów na problemy z reliability.
https://github.com/Azure-Samples/iotedge-logging-and-monitoring-solution

[smereczynski]

Heh, a to jest w ogóle ciekawe... strzelałbym, że to jest nawet niemożłiwe. Azure Functions trigger wymaga chyba zakodowania message'a w Base64, a Event Grid nie jest w stanie zakodować tego co wysyła do queue?

The reason is that when you use an Azure Queue storage trigger, Azure Functions expect a base64 encoded string, but Event Grid sends messages to a storage queue in a plain text format. Currently, it's not possible to configure the queue trigger for Azure Functions to accept plain text.```

https://docs.microsoft.com/en-us/azure/event-grid/custom-event-to-queue-storage?WT.mc_id=AZ-MVP-5001618

[MichalJankowskii]

Trochę zależy jak chcemy to zrobić... Jeśli wykorzystując Event Grid jako trigger - to może być tak jak @smereczynski napisał.

Ale jest też druga opcja - AF z HTTP triggerem i wtedy na EventGrid subskrybujesze się używając WebHooka. Powinno zadziałać.

No i można jeszcze rozszerzyć AF, ale to już była by sztuka dla sztuki.

[meanin]

Jest dedykowany trigger pod EventGrid, do debugging purpose używa się webhooka z ngrokiem przed lokalną instancją.

Dzięki, czyli SQ do śmieci bo i tak może w ogóle to nie zadziałać.

[pmartynski]

Jedyny powód jaki przychodzi mi do głowy, to TTL na EG wynosi max 24h, natomiast SQ do 7 dni, niemniej na EG można jeszcze ustawić dead letter policy. Wydaje mi się, że SQ jest tu bez sensu.