0

Can Azure Event Grid run a logic before it returns a response back to its callers?

Looking for something similar to the delegator in the web.api pipeline.

For example, we have a flag somewhere (in app.config or keyvault), and then Event Grid looks at the flag and send its response back based on the flag. The flag might be 'on' or 'Audit mode' or 'turned off' when the flag is on, Event grid returns 200 ok, When 'audit mode' return a different http status code Or when 'turned off' returns 404

My question is not about the status code but if Event grid can run a logic before it returns a response back to the caller synchronously.

Thank you so much

Investigated Azure documentation but couldn't find a solution.

Toby Yoo
  • 5
  • 3
  • What type of “caller” are we talking about? Sounds like an APIM function to me. – Skin Jun 01 '23 at 09:00
  • The caller is just web.api. web.api sends a message to the event grid. And we would like the event grid to send a response based on the flag. – Toby Yoo Jun 01 '23 at 11:38
  • Event grid is an event routing service. If you want a response, you’d need to call an API and then route from there through event grid. – Skin Jun 01 '23 at 12:58
  • So I gather there is no way event grid itself can do this on its own? – Toby Yoo Jun 02 '23 at 22:47
  • I don’t believe so, that’s not the purpose of the service. It’s an event routing service, plain and simple. – Skin Jun 03 '23 at 00:03
  • Azure Event Grid is a distributed eventing based on the Pub/Sub model, where the events are reliable distributed to the destination endpoint(s) in the **decoupled** Fire&Forget manner using the FAN-IN and FAN-OUT output patterns. For your scenario you should consider an Azure Durable Function https://learn.microsoft.com/en-us/azure/azure-functions/durable/durable-functions-overview?tabs=csharp-inproc for handling a caller processing states – Roman Kiss Jun 03 '23 at 13:20

1 Answers1

0

As @Skin and @Roman Kiss mentioned in the comments, Event Grid does not provide such a functionality. You should instead set up an API that can perform your custom logic and then forward the event to Event Grid as required.

You have a couple of options here since your logic is simple

1. Use APIM Polices
This would be the simplest, especially if you already are using APIM somewhere, and if your custom logic doesn't get any more complex than that, this should do.

2. Use an Azure Function
This would simply serve as a proxy of sorts that runs your custom logic before forwarding the request to Event Grid.

3. Include in your Web API
If possible, you could simply just add this right into your Web API and have all callers just call your own endpoint instead of Event Grid directly.

PramodValavala
  • 6,026
  • 1
  • 11
  • 30
  • Thank you so much everyone for your inputs. I have thought about Azure function or API as a proxy sitting in front of Event Grid. I could be completely wrong but I feel it doesn't seem right :). Because architecturally is it ok? I can't explain why I don't feel right about this either though haha. Is Event grid more reliable or more resilient or more availability guaranteed then Azure function? Even if the event grid subscribers are wrong and not pick messages from event grid, the requests are still there. However if the proxy functions go wrong, we loose everything. Am I thinking logically – Toby Yoo Jun 17 '23 at 05:48
  • We also need to route to different event grid to apply different throttle based on request types. The requests will come with priority flag. So the clients will call one proxy function endpoint and the proxy will route them to different event grids (topics). So the callers don't need to worry about the routing either so locally the proxy makes sense too :). But again every requests will go through the one Azure function proxy. This means one failure point. Therefore this proxy function needs to be highly available and scalable. Is this proxy architecture ok based on this? – Toby Yoo Jun 17 '23 at 05:53
  • One type of requests could stay in Event grid for 3 days. So if event grid long running subscriber is not functional, we could fix the subscriber issues, redeploy. Then the subscriber can pick the requests still sitting in event grid and process them. Another type of requests is short lived. So the topic time to live for this type of request will be 2-5mins, they will fall out. So my concern is if the proxy function is not available (or down), we are loosing those requests which can live for 3 days, they would have had a benefit from being processed by the long running subscriber function. – Toby Yoo Jun 17 '23 at 06:04
  • Yes. The availability of the Azure Function is on you. :) But that is the case for anything, architecturally speaking, and needs to be worked around off. You could for example have the same Azure Function deployed across regions and use [Azure Front Door](https://learn.microsoft.com/azure/frontdoor/front-door-overview), use [slots](https://learn.microsoft.com/azure/azure-functions/functions-deployment-slots) to quickly revert accidental changes, implement retry in your client applications, etc. Read [this](https://learn.microsoft.com/azure/architecture/guide/multitenant/service/app-service). – PramodValavala Jun 28 '23 at 15:58
  • For your second comment, the Azure Function route would be perfect since you could include your own logic and keep that out of client applications. And for your last comment, that is indeed a possibility and where engineering comes into play to ensure that your service is up. Client retries are a major thing as well to ensure requests are not lost (even when sent to Event Grid directly) and you can implement good practices to ensure faulty code changes are not pushed without testing, use slots to be able to revert back quickly, etc. – PramodValavala Jun 28 '23 at 16:00
  • UPDATE: We have decided to use an Azure Function before Event Grid. – Toby Yoo Jul 24 '23 at 05:43