We are using Azure as our PaaS to host multiple .NET Core API projects which communicate with each other through HTTP. When we started it was just a few endpoints, but as today and in the future we need to do more of these communications between our projects.
In todays solution we use HttpClient to perform these communications. As we want a more independent API projects we would like to use a bus with webhooks. Altho we know what we need, we have a lot to choose from and it feels a bit overwhelming in Azure.
Our requirements are basic, its to send a request with a minimal payload to a specific endpoint e.g user with id xx created.
We are a bit confused and need to be pointed in the right direction WITHIN Azure Platform. Feel free to ask if you need more info to help us!
Regards
It seems like you are moving towards microservices architecture which is great. I personally don't see any issues with using HttpClient. This is exactly how communication is done in our Azure Service Fabric application. We implemented a base HttpClient library with retry strategy in case if we receive transient error from the API and it all works as expected. You just need to make sure your services are not too "chatty" - it's a common microservices issue. To do so, services have to be well designed and responsibilities separated in a logical and most efficient way.
There are other ways of communication that you could implement in Azure cloud, the ones I used:
They all work good for specific scenarios. For instance if you expect your services or some 3rd party services to go down, you might want to consider accumulating messages in EventHub until service is up and running again and ready to process them.
So it's all depends on a particular scenario that you want to implement, for many(most) scenarios Http communication should be working just fine - great benefit of it is simplicity and ease of implementation. For some scenarios you'd need "dequeuing" strategy. Sometimes you can just use shared database and poll-every-N-interval.