I have a question about what the best approach/design pattern could be to achieve communication between two or more MVC API's on the same machine.
Currently I have a single Web API delivering data to my web site. For reasons too long to explain here, we are refactoring the API to split it in multiple modules. One being the main API with the core information (think : Order database with detailed info), and the satellite API's having lists of orders, but without their details.
Of course, when a satellite API gets a request, it could just reply with the list of orders (which it knows of), but I want it to reply with the details of each orders ..
Important to mention is that all data is in memory, no database is behind the whole thing (otherwise it would be trivial).
Knowing that all API's would be on the same server, and that I obviously want to avoid ping-pong between the client site and the API's .. I would like to have my satellite API ask my main API about this information.
I have looked into WCF services, but I am not sure if that's the appropriate solution, and also about how to integrate it in my existing projects. I do already have the multiple API's running (not in prod) as normal ASP .Net MVC projects.
In an ideal world, I would simply "expose" a few methods from the main API, so that the other ones can call it. I've also looked at the other ways to do IPC, but I am unsure which would be best in my case.
Side questions about WCF Services:
- do they have to be a project of their own ? or could I say that a few methods in my API are the actual service ?
- What about the service reference that the client has to know of ? how do I specify where the service actually runs ? This is not necessarily known during dev, what if the server is hosted elsewhere ?
- Do I have to care about async calls here ?
Note: I'm obviously new to WCF, be kind
Thanks a lot