1

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

Matt
  • 3,305
  • 11
  • 54
  • 98
  • From research ive done im going to go with all eggs in one basket (keeping client and webapis in one project) and running it on windows azure for scalability. Any advice? – Matt Jul 12 '12 at 05:06
  • What does each one do (MVC and WebAPI)? Bring example. – Aliostad Jul 12 '12 at 08:44

1 Answers1

1

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

Dean Ward
  • 4,793
  • 1
  • 29
  • 36
  • Hi Dean, Thanks for your response. Can you expand at all on how you are using request routing in your case? And the reason you dont have to worry about JSONP is because its not cross-domain, is this right? – Matt Jul 13 '12 at 01:30
  • We using request routing by having 'n' servers take the request and then forward to the appropriate hosts based upon the URL. E.g. requests to /api get proxied to the API cluster whereas requests for the website content either get served directly or proxied to the relevant content servers. Spot on with the JSONP - we've found it causes way more hassle so it makes sense to have a single logical domain serving everything. – Dean Ward Jul 13 '12 at 12:25