asp.net mvc - Single Page Application Server Separation of Concern -


I am in the process of putting together the base framework for multi-tenant enterprise systems.

The client-side will be an asp.net mvc webpage which is talking to the database via AJAX via AJAX Web API.

My question really lives around scalability, should I separate the client from the server? That means see client-side / frontend code / in a project and webpia in another separate project server. So if a server starts to load (server A) to start all the size / server frequency (server B) than all required and all new clients will point to webapi on server B.

Or should all this be integrated as a project and the SQL Server side of things should be understood as load scaling (dynamic cloud scaling)?

Before throwing our hat in the ring, we need some advice.

In advance thank you

We have a way to separate the API and single page The application has been The reason for this is that it forces you to treat single page applications only as a customer, resulting in an API resulting in all the functionality provided to you for a full customer ...

Deployment We attach a single page application in the form of a website root with an API deployment / API application. In the base, we can then use application request routing or some content-aware routing mechanisms so that things can be excluded on different servers if necessary. In Azure, we use multiple websites for per-role mechanism (http://msdn.microsoft.com/en-us/library/windowsazure/gg433110.aspx) and measure this role based on load.

Living in a single domain makes things easy because you do not have to bother with frustration that JSONP or CORS!

Cheers, Dean

Comments

Popular posts from this blog

Python SQLAlchemy:AttributeError: Neither 'Column' object nor 'Comparator' object has an attribute 'schema' -

java - How not to audit a join table and related entities using Hibernate Envers? -

mongodb - CakePHP paginator ignoring order, but only for certain values -