2

Problem: I am building out a web application architecture with C#.NET MVC Client App and a WebAPI Service. Currently, I have multiple clients and a single, bloated Web API Service. All of my client apps call the service to retrieve data. However, because our application is getting much bigger, I want to break my single service into multiple services - essentially, one Web API service per database, so that the service layer is directly tied to its respective database. This will allow me to do code-first development on the database with the service layer, and decouple any other code that references other data access, so that when I make a change to the service or database, I can know for sure that it is only affecting that service or database, and I don't need to do regression testing on anything else.

The main problem I have now is that I have a bunch of client apps that have references to a bunch of different Web API services, and if I change the location of one service I need to update that change in any and all clients. To remedy this, I am creating a new "Gateway" Web Api, that is essentially just a pass-through from Client App to Web API Service, but all Client Apps call a controller on the Gateway, and the Gateway knows how to route the traffic to the correct Web API Service. So if I make a change to the Service, I simply change the reference in Gateway, and that is all - clients do not need to be modified.

So now the Architecture looks like MVC Client App -> Gateway Web API -> Service Web API -> Database.

Question: I have this working as intended, and it seems to solve the issues I had before - but my question is - is this overkill? Is there a better way to handle this without introducing the complexity of two hops over the wire?

I have tried googling to get info about software and web application architecture examples, but I can't find anything with this level of complexity. It seems all literature I can find are simply referring to multiple clients calling a single service.

Any insight that anyone may have is much appreciated.

Jesse Milan
  • 53
  • 5
  • Can you find any materials on micro services? That is going to tell you that you have chosen the correct approach and no big worries right now. – Lex Li Feb 17 '16 at 03:50
  • Wow - that is exactly what I was looking for - Thanks Lex Li! I'm actually pretty stoked I came up with the idea of Microsites based on my own business need before I even knew 'they' have already been established, but a little humbled that I couldn't find it earlier. Appreciate the help! – Jesse Milan Feb 17 '16 at 06:28

1 Answers1

0

Personally I would go for a discovery WebAPI that host my HATEOUS endpoints for resource discovery. This describes where to find the other endpoint then the client only need to know about one set of endpoint and can pragmatically discover the others. have a look at this:

https://msdn.microsoft.com/en-us/magazine/jj883957.aspx

Generating Hypermedia links in a Web API

This works very well with micro services as you can refactor/split/move them without having to change the client.

Community
  • 1
  • 1
jolySoft
  • 2,948
  • 2
  • 30
  • 34
  • I was really looking for what Lex Li mentioned - microservices. But, I have read about HATEOUS and appreciate you adding some information about it in this context. Thanks for your help! – Jesse Milan Feb 18 '16 at 16:46
  • @JesseMilan No worries. They are not mutually exclusive you can use hateous with micro services and IMO complement each other very well. The Hateous would become you're gateway or you're just creating a pass though. – jolySoft Feb 18 '16 at 17:07