I have an AngularJS WebAPI application that has a Javascript front-end. The front end makes calls to the back-end WebAPI for data. In the future there may well be more than one front-end making calls to the back-end.
I would like to change this application to use HTTPs and am looking into how to best architect this. The way I see it there are two ways (maybe more).
(1) Host the WebAPI C# application, index.html, Javascript, Javascript libraries and other HTML on the one (or more) web roles.
(2) Host the index.html, Javascript, Javascript libraries and other HTML on a CDN and put the WebAPI C# application on one (or more) web roles at one location.
From a performance point of view are there likely to be any issues with the split solution (2) when I am using SSL. Is there anything that I should consider that might help improve the start-up time (my goal is for this to be as fast as possible).
One more question I have. If I were to use the Azure CDN then would I still be able to address the index of my web site as www.mywebsite.com and if using HTTPS would I need a SSL certificate?
Option 2 is more preferible.
You have to think, that your application is what sits in the backend. The front end is just a suggested set of UI controls and interactions to consume that application you have. Then, if you can host them separately you have some benefits, starting by not creating UI dependency.
The approach would be like creating a thin client.
Since the application is AngularJS based, probably all the UI are static files with HTML, CSS, and Javascript. You can host them in BLOB storage, and scale it through the CDN. You can have a custom domain name pointing to Azure Blob Storage, like `www.yourdomain.com. It has many benefits, including better price and scaling than web roles. Put aside, that you pay for web roles no matter if you are getting hits or not. The only downside is that as far as I know, it would not be possible to use HTTPS, but that should not be a problem, since you are just hosting static content and templates that contains placeholders, no actual data.
On Blob storage, you can attach your own cache control headers, allowing the browser to cache those files locally. Then a user would download those files once, and be recovered from the browser cache next times. Also, you can store the content already compressed in GZIP, and then set the content encoding property to let the browser know it is compressed, therefore enabling a faster content download. Not forget you should bundle your resources. For example, you should bundle all your JS code in one JS file, all your CSS code in one CSS file, and all your AngularJS views should be bundled in the
template.jsfile (also bundled into the unique JS file).You need to host your backend application in worker/web role instances though. Here you can use HTTPS, and it would be no problem to use AJAX over HTTPS, although the page loaded on HTTP as long the SSL/TLS certificate is signed by a CA recognized by the browser (ie: a valid certificate). If you use a self-signed certificate, there will be no way for the browser to prompt the user to accept it. Keep this in mind if you plan to start with a self-signed one.
So then you would have all the things that are not user/state dependant in blob storage, that is cheap, fast and highly scalable; and all your user data interaction would happen through your worker/web roles through compact data request/response probably in JSON. Therefore you need less web/worker roles for providing the same level of service.
Now, if you have a very asymmetrical amount of massive queries and data changes request, you should consider an approach like CQRS.