CODEWITHSUNDEEP
c#.netwcfasp.net-web-apiwcf-web-api
Dave New
Dave New

Reputation: 40042

Communicating between multiple decoupled systems

We have multiple, decoupled systems. These systems provide public APIs which are consumed by mobile apps and other client applications.

We now need these systems to internally communicate with each other during some calls (for whatever reason). I am torn between the possible solutions.

Create secure API calls

Hosting an internal ASP.NET Web API for each system so that they can expose data and functionality to each other.

Reference repository projects between solutions

Sharing and include the Repository (data access) codebase between multiple projects.

Neither of these solutions seem ideal.

Is this a job for WCF?

Upvotes: 3

Views: 362

Answers (2)

Jimmy
Jimmy

Reputation: 3264

We are using WCF for this purpose. Typically that is the way to handle the scenario you mentioned, I think, unless you have very specific requirements.

If you use a messaging broker in between, a (WCF)services solution can scale very well.

Weigh your priorities with the differences between WCF and Web API. See this

Upvotes: 3

jgauffin
jgauffin

Reputation: 101150

Very slow. An HTTP request is deathly slow when compared to a database query. This could severely affect the speed of our public calls

Well. no. For instance the RavenDb client API is built using HTTP. All db queries in it are executed over HTTP. You should also know that most database engines communicate with the client over the network (using sockets or named pipes).

What I'm saying is that the overhead that HTTP introduces is marginal.

The bright side with HTTP is that it enables you to cache queries at any time with little effort as there are dozens of ready-to-use caching solutions for HTTP. Same thing goes for load balancing when your user base grows.

Hence I would use HTTP for this.

Upvotes: 3

Related Questions