3

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.

  • Advantage: Low coupling. As long as the API call structure doesn't change, the systems can evolve on their own.
  • Disadvantage: Very slow. An HTTP request is deathly slow when compared to a database query. This could severely affect the speed of our public calls.

Reference repository projects between solutions

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

  • Advantage: Very fast. Retrieving the relevant data will be extremely fast as it would simply be a database query.
  • Disadvantage: Highly coupling. A rebuild and release on system A would likely mean the same for system B as they will share common code.

Neither of these solutions seem ideal.

Is this a job for WCF?

Dave New
  • 38,496
  • 59
  • 215
  • 394

2 Answers2

3

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.

jgauffin
  • 99,844
  • 45
  • 235
  • 372
3

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

Jimmy
  • 3,224
  • 5
  • 29
  • 47