I’ve been tracking the ASP.NET betas and release candidates over the past year or more and it’s coming along nicely. I like the separation of client side and server side in the new folder structure and the unification of the MVC and WebAPI controllers. For the past few years I’ve used jsViews, Kendo UI, Angular, Durandal, Knockout, and Aurelia for front end JavaScript development.

A while ago I was using TypeScript with these to help with intellisense and typing issues across the libraries and sites I worked on. I often find myself introducing whatever team I’m on to these technologies in one way or another. I’ve been working with the combination of ASP.NET Core, formerly ASP.NET 5, and Aurelia with TypeScript and Web Components.

I start with the yoeman generator for ASP.NET and add the pieces as I go. I use ASP.NET MVC for the API and plain old HTML and TypeScript for the UI. The client tool chain consists of the usual npm, jspm, and gulp. When the new ASP.NET bits are done I’ll make a template for all this and post it to github. In the meantime I’m considering doing a short video or slide deck walking through the setup if anyone is interested.

There are a lot of tools out there and others have posted lists that are handy. I’m going to put my list of common tools here and try to keep it updated every now and then for my own use as well as anyone else who may like to reference it. Feel free to send me more to add to the list.

Helpful Blogs
Code & Text Editors
Visual Studio Extensions
General Utilities
Web Sites

I've been poking around at a lot of JavaScript over the last year or two and have been refining this layered architecture for setting up applications. The main idea behind it is to cover all the old bases in a way that also reduces the number of requests and performs very well. The layers I am using are setup like so:

  • Web front end (static HTML)
    • UI views, scripts, and related image files
    • Localized strings as JSON files
  • Middle tier (WebAPI/SignalR)
  • Back end (database/web services)

So, to explain a little about this layout… The front end is all static. The files may be generated by a compiler or parser but upon publish they are static and require no server processing. This allows one to put these files into a CDN whether it is Azure or Amazon for massive scale and economy. Having the localization files as static JSON allows them to be packaged up with the front end and sent along with it. Depending on the configuration and build process these files could even be combined and minified further.

The middle tier is your standard WebAPI and/or SignalR server side code layer hosted on a standard ASP.NET server, usually Azure Web Sites in my case. This tier is basically an API that provides the site with any dynamic actions and information it needs.

Finally, the back end consists of a database used by the middle tier, usually a SQL server of some kind, and any external web services needed by the middle tier. You could lump the external web services into the middle tier but I prefer to think of them as something separate for the sake of organization.

There are some interesting issues you run into when implementing this pattern, including how to handle authorization and security trimming. I generally move the navigation page list into a JSON object that can be generated by the API. In this manner you avoid exposing all your pages to the client even though the templates for those pages may exist in your CDN as public files. All of the security should be enforced on the middle tier so that users cannot perform actions they are not supposed to be allowed to do.

I've found that this model is fast and performs well under load when done properly. The trick is keeping it simple while utilizing all the tooling available to generate the published result. If anyone is interested I could go into more detail about that.