Most efficient way to communicate between multiple .NET apps

Question

Currently i have a setup where my clients (web apps, iOS app etc) talks to my backend API .NET web app (Nancy) via REST calls. Nothing special.

I now have a requirement

Answer 1

To start I would recommend breaking up your monolithic REST service into multiple micro-services, each specific to a single data entity or use case. For example: Sending emails out would be a single use case, and querying results for a search page would be a single use case.

Then as you roll out each individual service, you could modify your monolithic service to be a proxy to the new micro-services. This way your existing apps could keep calling your monolithic service, and the new app updates could call the micro-services appropriately.

Basically, migrate from a monolithic service to micro-services incrementally, one at a time.

The only approach that comes to mind is simple REST-based calls. Totally fine, but latency is the main issue here.

Using the monolithic web service as a Proxy to the micro-services will add some latency, but the individual micro-services won't add any latency, and you can scale those out to as many hosted instances behind an Azure Load Balancer as needed.

If you do see query latency, then you could implement something like a Redis cache for any micro-services that exhibit performance problems with queries.

If you do see write latency that becomes a problem, then I would recommend moving those problem writes to use some kind of Messaging Queue to allow for them to be handled asynchronously if possible.

Is there anything in Azure suited to this?

You may want to look into Azure API Apps, as they may offer some nice functionality for securing / authenticating with your micro-services via Azure more easily than securing the individually.

What's the different ways i could communicate between my main API and other microservice API's?

It sounds like you need real-time communication between services. So, a message queue is out of the question, unless you have a task that can be performed in the background. You could use simple REST calls between services, or even something like SOAP if implemented with WCF. Although, it sounds like you currently are using REST, so it makes sense to keep it the same.

Also, make sure your micro-services aren't communicating with each other through a database, as that can get messy real quick. Use a simple REST endpoint for them to communicate, similar to the REST endpoints used by the client apps.

I like to follow the KISS (Keep It Simple Stupid) principle, so I would recommend you try not to over architect the solution and just keep it as simple as possible.