|As you have tried to keep the question compact, the one-liner answer to this would be to use Microservices architecture and use each individual module as a separate service; read here .NET Microservices. Architecture for Containerized .NET Applications | Microsoft Docs
I can see a microservice here.
Quote:I have a single Web API delivering data to my web site.
Another microservice here.
Quote:when a satellite API gets a request,
Another microservice here, that manages the data for the entire system—keeping the data aside and giving it some high-availability, as if this service goes down, entire cluster is down. This is the point that you need to discuss with your team again.
Quote:Important to mention is that all data is in memory, no database is behind the whole thing (otherwise it would be trivial).
Exactly the core benefit of microservice architecture, your clients would only need to know the website. Internal communication and services would be abstracted away from them.
Quote:I would like to have my satellite API ask my main API about this information.
WCF is quite old and doesn't quite fit the modern demands of the solutions. If, for instance, you would want to go to cloud hosting solutions, then microservices and their modern approach to communication is much more scalable and feasible. WCF although supports various protocols, sometimes that extra optionality is a downside. Trust me with this—or not.
Quote:I have looked into WCF services,
Since, ASP.NET Web API is based on REST, talk about REST mostly and in REST you can use services like OpenAPI (Swagger) and generate a documentation for the users that they can access.
Quote: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.
About Swagger Specification | Documentation | Swagger | Swagger
Now coming to the last part of your question,
You can decide, a single project might have more complex structure and developmental issues. Separate projects would be simpler to manage. This is for WCF and ASP.NET etc. For microservices, you should try to keep everything separate. You can even use different languages and runtimes.
Quote: 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 ?
You should consider using DNS for that. Most services are to be managed by the hosting providers, they allow you to control that. Your API definition will grant enough information to the users that they can manage it from there.
Quote: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 ?
Quote:Do I have to care about async calls here ?
Yes, if you want to have a scalable solution, then yes. A friend of mine (along with me) worked on a course that speaks about the same thing, Asynchronous Programming in .NET Core [Video]
I hope this answers your questions.
The sh*t I complain about
It's like there ain't a cloud in the sky and it's raining out - Eminem
~! Firewall !~