Web portal taking data from web service or database - architecture pattern

Question

I'm working on the project that is currently built upon the following architecture:

1) First solution

• Project that has all the database logic (DAL) based on Entity Framework 5
• WebAPI project responsible to feed data to customer Web Portal and smartphone apps

2) Second solution

• MVC4 project that serves as customer Web Portal

Customer Web Portal and WebAPI are sitting on the same server. WebAPI is directly accessing database, while Customer Web Portal is accessing it over WebAPI. Reason for choosing this architecture is to lower development time as Web Portal and smartphone apps are calling 85% of same web services. However, I'm extremely worried on how good performance architecture this is. I think that Customer Web portal should directly access database and that it would be more efficient way.

Any thoughts on this?

Answer 1

Architecture is always tricky ant it's always a compromise between different factors like speed of development, maintainability, performance, and scalability. So, you need to weigh all pros and cons.

Accessing DB via WebAPI

1 . Definitely introduces some overhead in performance. But how much? Let's say that passing your call through additional wrapper (WebAPI) will cost you approximately 2-3 extra milliseconds per call, and around 200MB of extra RAM total. I think, it's not a real issue, but you know better all the details and it's up to you.

2 . That solution can get some benefits from using the Cache. If you configure IIS to cache requests to WebAPI, then both: WebAPI clients and portal will increase the performance.

Accessing DB via DAL directly

1 . Theoretically, you're introducing two entry points to your DB you need to take care of. What if you need to add some logic, which must be used by WebAPI client and your portal, and that logic is web-specific (eg, something related to user sessions)? You shouldn't add it to DAL, instead you need to add another layer with another library, which will be used by both: WebAPI and your portal. And if your only access point is the WebAPI, then you can modify just the WebAPI to get the result.

To summarize:

Those are just some pros and cons. But if your project is not huge, if it's not planning to be on a very high load, then the only factor which I would consider is the cost of development. If it's faster to use WebAPI as a single entry point, then just go with it.