CODEWITHSUNDEEP
sql-serverasp.net-mvcclient-serverscalabilityasp.net-web-api
Matt
Matt

Reputation: 2863

Single Page Application Server Separation of Concern

Im just in the process of putting together the base framework for a multi-tenant enterprise system.

The client-side will be a asp.net mvc webpage talking to the database through the asp.net web api through ajax.

My question really resides around scalability. Should I seperate the client from the server? i.e. Client-side/frontend code/view in one project and webapi in another seperate project server. Therefore if one server begins (server A) to peak out with load/size than all need to do is create another server instance (server B) and all new customers will point to the webapi's on server B.

Or should it be all integrated as one project and scale out the sql server side of things as load increase (dynamic cloud scaling)?

Need some advice before throwing our hats into the ring.

Thanks in advance

Upvotes: 1

Views: 385

Answers (1)

Dean Ward
Dean Ward

Reputation: 4793

We've gone with the route of separating out the API and the single page application. The reason here is that it forces you to treat the single page application as just another client, which in turn results in an API that provides all the functionality you need for a full client...

In terms of deployment we stick the single page application as the website root with a /api application containing the API deployment. In premise we can then use application request routing or some content-aware routing mechanism to throw things out to different servers if necessary. In Azure we use the multiple websites per role mechanism (http://msdn.microsoft.com/en-us/library/windowsazure/gg433110.aspx) and scale this role depending upon load.

Appearing to live in the same domain makes things easier because you don't have to bother with the ugliness that is JSONP or CORS!

Cheers, Dean

Upvotes: 1

Related Questions