Geoffrey Vandiest Blog

What is the best UI technology: Angular or Blazor ? 

(When you build enterprise business apps using DotNet)

Introduction

This post compares and explains in detail the pros and cons of the 2 most used SPA frameworks by .net developers, Angular and Blazor.

My customers are enterprises that use .Net for building their line of business applications. I compared these 2 UI technologies, to find which one is the best fit for them and when they should use them instead of traditional ASP.NET MVC.

This study is primarily based on my many years of experience in architecting and developing solutions based on Angular and .NET. It is based on research over the internet and the feedback of other architects and IT consultants. Because I had no formal experience with Blazor I invested time in studying the Blazor framework and in building some small applications with Blazor. I also interviewed other developers that had experience with Blazor and integrated their feedback into this study.

Single Page Applications

There are two general approaches to building web applications today: traditional web applications also called Multi Page Applications (MPA’s) because they are made of multiple pages. These perform most of the application logic on the server. On the other hand, you have single-page applications (SPAs) that perform most of the user interface logic in a web browser, communicating with the web server primarily using web APIs. A hybrid approach is also possible, the simplest being to host one or more rich SPA-like sub-applications within a larger traditional web application.

MPA reloads the entire page and displays the new one when a user interacts with the web app. 

A SPA is more like a traditional application because it’s initially loaded and then it refreshes part of the page without reloading it. When a user interacts with the application, it displays content without the need to be fully updated since different pieces of content are downloaded automatically as per request. It is possible thanks to AJAX technology. In single-page applications, there is only one HTML page, and this one page downloads a bunch of assets, CSS, and images but typically also a lot of JavaScript. Speaking of the latter, the code will then listen to clicks on links and then re-render parts of the DOM in the loaded page whenever a user needs something. 

Although SPA applications are extremely popular because they usually account for a better user experience it does not mean that every web application should be built with a SPA architecture. Let’s take, for instance, a news portal like CNN. It is a good example of a multi-page application. How can we see it? Just click any link and watch the reload icon on the top of your browser. You see that reloading has started because a browser is now reaching out to our public server and fetching that page and all the resources needed. The interesting thing about multi-page applications is that every new page is downloaded. Every request we send to the server, like whenever we type a new URL or click on a link, leads to a new page being sent back from the server. Notable examples of multiple-page applications are giants like Amazon or eBay. Using them, you always get a new file for every request.

ASP. Net Core MVC is an excellent choice for websites that are better developed as MPAs (see later). But as explained here above SPAs usually supplies a better user experience when our application is more like an interactive application.   

Angular

Angular still is by far the most used SPA framework by .NET developers. This is because it has a lot of similarities with the .Net ecosystem.

• TypeScript: Angular use TypeScript by default. This means that all documentation, articles, and source code are provided in TypeScript. TypeScript is a superset of JavaScript that compiles JavaScript. C# and Typescript are both designed by Anders Hejlsberg, and in many ways, TypeScript feels like the result of adding parts of C# to JavaScript. They share similar features and syntax, and both use the compiler to check for type safety. So, it's more straightforward to learn TypeScript for a C# dev as JavaScript.
• MVVM: Angular uses the MVVM pattern. This Pattern was invented for WPF & Silverlight (.NET). So many developers coming from .NET that wanted to do Web development have turned to Angular because it used the same pattern.
• All in the box: Unlike other Js frameworks like Vue or React, Angular is a complete framework that tends to supply everything you need, libs, and tooling and spare you of the dependency hell so that you can focus on your application. Just like the .NET framework. 

 Most of the other Js frameworks are exactly the opposite. They only focus on one aspect but leave you with a lot of choices. Although focusing on one thing results in frameworks that are simpler to learn, .NET enterprise developers are annoyed when they must make a lot of choices. They prefer opinionated frameworks that help them in getting productive faster with better supportability.

Angular is a part of the JavaScript ecosystem and one of the most popular SPA frameworks today. AngularJs the preceding version, was introduced by Google in 2009 and was largely adopted by the development community.

In September 2016, Google released Angular 2. It was a complete rewrite of the framework by the same team. The recent version of the framework uses TypeScript as a programming language. TypeScript is a typed superset of JavaScript which has been built and maintained by Microsoft. The presence of types makes the code written in TypeScript less prone to run-time errors. As explained here above, TypeScript is the primary reason Angular is so popular in the .NET community.

The difference between the old Angular and the second version is so radical that you can’t update from AngularJs (the older version). Migrating the applications to Angular requires too many modifications due to different syntax and architecture. This means that upgrading our existing AngularJs apps to the new Angular framework will lead to a complete rewrite. 

TypeScript compiles JavaScript and integrates perfectly with the JavaScript ecosystem. So Angular is part of the JavaScript ecosystem and uses npm to manage dependencies. It can count on the largest community and number of libraries today. With Angular, you use the largest open-source ecosystem where you can find everything that you need. 

But the vast number of packages and their fast-changing rate is also a challenge in the enterprise. Making these packages available is the biggest challenge. Take a new Angular application as a sample. An empty new Angular application has the following direct dependencies:

• @angular
• @angular/cli
• @ngrx
• rxjs
• typescript
• tslint
• codelyzer
• zone.js
• core-js

And now let’s install all the dependencies by typing:

npm i
... one eternity later ...
added 1174 packages in 116.846s

A new regular Angular application without any add-on uses already 1200 packages! 

When your ecosystem has this number of dependencies, you can’t inspect them all yourself. You can’t hope they’re all secure. You can’t assume they’ve all got permissive licenses. You can’t maintain your registry by hand. You can’t formally approve packages by comity, and you can’t maintain this as many packages you’re using will get an update every single hour. You must move from manual, discrete processes to automated, continuous processes. 

Angular comes with great tools, supported by a large community. Angular has been around for over a decade, while Blazor has been in the market for only a few years. Angular is a production-ready framework with full support for MVVM applications and it is being used by many large companies. Blazor, while being used by some large brands, is early in its lifecycle. Angular and other popular Js frameworks like Razor or View come with much more content in the form of courses, books, blogs, videos, and other materials. Angular has dedicated tech events held worldwide, a huge community, and it supplies a broad choice of third-party integrations.

To illustrate the difference in adoption, consider the graphic here that compares the number of jobs offered by frontend technology. Angular comes second when Blazor is somewhere between the others:

As illustrated here above, despite being one of the oldest and one of the most mature SPA frameworks Angular is not the most used or loved framework in the JavaScript community. This is primarily due to his complexity. Even for seasoned JavaScript developers, Angular is difficult to master. His strength of being an opinionated framework using TypeScript comes at the expense of a steep learning curve. 

This is even more challenging for most .NET developers who usually have only a marginal knowledge of JavaScript. They not only have to learn a new language they also must learn an entirely new ecosystem and framework. In my own experience, this is the greatest challenge for organizations using .NET. This can be solved by recruiting Angular specialists that focus on the frontend part. Having a frontend specialist usually improves the user experience but it comes at the expense of having to segregate your devs in frontend (Angular) and backend devs (.NET). 

Mixing two technologies coming from different worlds diminishes the flexibility of resource allocation. People must specialize and the potential number of tasks they can work on diminishes. It also increases development time as you need to put more effort into integrating both technologies.

My own experience with working with .net developers having to learn Angular confirms that the learning curve is very steep for them. In the past, to cope with this problem, we recruited Angular specialists to coach our .Net teams. We also had to invest in our CI/CD pipeline to support our new technology stack. As a .Net shop that desired to adopt Angular, we had to make a considerable investment in recruiting the right profiles, supplying the right guidance, and investing in building and adapting our package management process and tools to the high velocity and number of packages that are typical for the Javascript ecosystem. Also recruiting the right skills was a challenge for the reasons explained here above and because Angular is somewhat losing traction in the Js community.

When to choose Angular over ASP.NET MVC?

If the team is unfamiliar with JavaScript or TypeScript but is familiar with pure server-side MVC development, then they will probably be able to deliver a traditional MVC App more quickly than an Angular app. Unless the team has already learned Angular or unless the user experience afforded by Angular is needed, the traditional MVC is the more productive choice. 

Blazor

Blazor is a relatively new Microsoft ASP.NET Core web framework that allows developers to write code for browsers in C#. Blazor is based on existing web technologies like HTML and CSS but then allows the developer to use C# and Razor syntax instead of JavaScript. Razor is the template markup syntax used by ASP.NET MVC and MVC developers can reuse most of their skills to build apps with Blazor. 

Blazor is very promising for .NET developers as it enables them to create SPA applications using C#, without the need for significant JavaScript skills. 

An advantage of Blazor is that it uses the latest web standards and does not need added plugins or add-ons to run in different deployment models. It can run in the browser using WebAssembly and offers a server-side ASP.NET Core option.  

Learning Blazor for .NET developers is nothing compared to Angular or other Js frameworks. First, they don’t need to master JavaScript and TypeScript but also, but they can use the enterprise-friendly .NET ecosystem they already know. For a .NET dev already accustomed to web development through MVC, we can say that developers can be productive in a matter of days/weeks compared to months/years with Angular.

But the biggest advantage of Blazor is its productivity. It allows .NET developers to build entire applications with only C#. It feels more like building desktop apps than web apps. When using the server-side version developers don’t have to think about data transfer between client and server. Also, with the client-side version, it’s a lot easier than with Angular as it’s all integrated within one .NET solution. 

Blazor seems even more productive than traditional MVC as it doesn’t require the developer to cope with server page refreshes and can use client rendering and events. It feels like what was developing with Silverlight or WPF but using Razor, Html, and CSS instead of Xaml. This was also confirmed by our discussion with a consultant at Gartner. They confirmed that based on experiences with several customers, Blazor was the most productive technology for building UIs inside the .NET ecosystem, even compared to MVC.

The adoption of Blazor outside the .NET community will probably remain low. Blazor is hard to sell to the current web developer because it means leaving behind many of the libraries and technologies that have been up for over a decade of modern JavaScript development. This means that Blazor will probably stay a niche technology. Blazor is and will be used by teams that know .NET for building internal business applications but will probably not be adopted outside this community. That means that the community and tools will mostly be supported by Microsoft. The tool and libraries support from the open-source community and vendors will remain less compared to Angular or other mainstream Js frameworks. 

One of the impediments to Blazor adoption by the .NET community is that Blazor will be the next Silverlight. They fear that it will be around only for a brief period. More than 10 years after the final Microsoft Silverlight release, some developers still fear being 'Silverlighted,' or seeing a development product in which they have invested heavily abandoned by Microsoft. This is because both technologies are similar, both are developed by Microsoft and allow us to use the .NET platform to create web applications. They both share the same core idea: Instead of using JavaScript, we can use C# as the programming language to create web applications. 

Inside the enterprise, this risk is largely mitigated by the fact that Microsoft has always supplied relatively long support periods. Even for Silverlight Microsoft continued to support it for nearly 10 years before retiring it. This risk has also a lot less impact as Blazor is not dependent on a browser plugin. Microsoft learned a lot from this story. First, ASP.NET and later ASP.NET Core do not require any browser plugins to run. Also, Microsoft decided to only use open web standards for Blazor. As long as the browsers support those open web standards, they will also support Blazor.

Client Side (Wasm) vs. Server Side Blazor

Blazor has a separation between how it calculates UI changes (app/component model) and how those changes are applied (renderer). This decouples the renderer from the platform and allows to have the same programming model for different platforms. 

Currently, Microsoft supports only 2 renderers, Blazor client (WebAssembly Renderer) and Blazor Sever (Remote Renderer). The implementation code is the same but what differs is the configuration of the hosting middleware. A good practice is to isolate your code from changes to the hosting model by using a class library where you put all the rendering code. This will ease the job if you later must migrate to another hosting model or when you need to support another supplementary model.

Blazor Server

With Blazor Server you use a classic ASP.NET Core website like ASP.NET MVC but the UI refreshes are handled over a SignalR connection.  

As for a SPA, one page is displayed on the browser and then parts of it are refreshed. On the server at the first request, the Html is generated from the Razor pages. When UI updates are triggered by user interaction and app events a UI diff is calculated and sent to the client over a SignalR connection. Then, the client-side Js library used by Blazor server applies the changes in the browser.  

Using Blazor Server behind load balancers or proxy servers requires special attention. As described in the article here, forwarded headers should be enabled (default configuration in IIS) and the load balancers should support sticky sessions. You can also use Redis to create a backplane as described here. 

Blazor Client (WebAssembly)

Here .Net code is running inside the browsers. The application code is compiled in WebAssembly (a sort of Assembly language for the web) and sent together with the .Net runtime to the browser. The Blazor WebAssembly runtime uses JavaScript interop to handle DOM manipulation and browser API calls.

WebAssembly is an open web standard and is supported by all modern web browsers. Blazor is not the only technology using WebAssembly, most of the other big vendors develop tools and platforms that make use of WebAssembly.

Blazor Server vs. client recommendation

For traditional enterprise business applications, Blazor Server seems usually the best option but for certain scenarios, Blazor Wasm has clear advantages :

-       When the responsiveness of your app must be optimal, the low latency of Blazor server will optimize the responsiveness.

-       You need offline support.

-       You expect many users (>100). Blazor Server is a less scalable solution as many users require server resources to handle multiple client connections and client states.

When to choose Blazor over ASP.NET MVC ?

As developing or maintaining apps using Blazor is more productive than ASP.NET MVC and easy to learn, Blazor is usually the best choice except when:

-       Your application has simple, possibly read-only requirements.

Many web applications are primarily consumed in a read-only fashion by most of their users. Read-only (or read-mostly) applications tend to be much simpler than those applications that maintain and manipulate a great deal of state. For example, our intranet or public websites where anonymous users can easily make requests, and there is little need for client-side logic. This type of public-facing web site usually consists mainly of content with little client-side behavior. Such applications are easily built as traditional ASP.NET MVC web applications, which perform logic on the web server and render HTML to be displayed in the browser. The fact that each unique page of the site has its own URL that can be bookmarked and indexed by search engines (by default, without having to add this functionality as a separate feature of the application) is also a clear benefit in such scenarios.

-       Your application ecosystem is based on MVC and is too small or too simple to invest in Blazor.

When your applications consist mainly of server-side processes and your UI is quite simple (e.g., Dashboard, back-office CRUD apps, …) and you’ve already made a strong investment in MVC then adding Blazor could not be worth the investment.

Angular vs. Blazor Score Card

Here we selected several criteria and attributed weight to the function of the specific needs and environment of Enterprises using .Net as their main technology stack. But, each organization is unique and adapt the scoring based on its specific needs.   

The weight ranges from 1 to 5. 5 indicates an especially important criterion, starting from 1 as minor importance to 5 as the top priority.

The score for each criterion ranges from 0 to 10. 10 shows an exceptionally high-quality attribute, 1 is the minimum.

We also take account of Risks at the bottom of the scorecard. Here the weight indicates the risk potential impact and the score the probability. Staring from 0 as 0% probability to -10 indicates a risk that will occur with 100% probability.

• Learning curve: the amount time a developer, on average, needs to invest to become productive with the technology.
• Productivity: how productive the developers are with the given platform once it has mastered the technology.
• Supportability: how well can we efficiently support the platform?
• Community: how valuable, responsive and broad is the developer's community? When a platform has a strong community the organization, its developers and its users all benefit.
• Maturity: is the platform used for long enough that most of its first faults and inherent problems have been removed or reduced?
• Full Stack efficiency: how efficient is it for the project to work and to cope with the separation of the frontend and the backend? Does the adoption of this technology diminish the efficiency of the project teams and the organization because they must deal with different skill sets for backend and frontend?
• Finding resources: how easy is it to recruit developers on the market?
• Libraries choices: a good library well suited for the needs and well maintained improves productivity while minimizing the TCO. A large choice of libraries increases the probability of finding a library that satisfies the needs.
• Opinionated: a platform that believes a certain way of approaching a problem is inherently better and enables the developer to spend less time finding the right way of solving a problem.
• Performance: which platform has the fastest render time, load time, and refresh time, and consumes a minimal number of resources?

There are two general approaches to building web applications today: traditional web applications also called Multi Page Applications (MPA’s) because they are made of multiple pages. These perform most of the application logic on the server.  On the other hand, you have single-page applications (SPAs) that perform most of the user interface logic in a web browser, communicating with the web server primarily using web APIs. A hybrid approach is also possible, the simplest being to host one or more rich SPA-like sub applications within a larger traditional web application.

MPA reloads the entire page and displays the new one when a user interacts with the web app. 

A SPA is more like a traditional application because it’s initially loaded and then it refreshes part of the page without reloading it. When a user interacts with the application, it displays content without the need to be fully updated since different pieces of content are downloaded automatically as per request. It is possible thanks to AJAX technology. In single-page applications, there is only one HTML page, and this one page downloads a bunch of assets, CSS, images but typically also a lot of JavaScript. Speaking of the latter, the code will then listen to clicks on links and then re-render parts of the DOM in the loaded page whenever a user need something.

Although SPA applications are extremely popular because they usually account for a better user experience it does not mean that every web application should be built with a SPA architecture. Let’s take, for instance, a news site like CNN. It is a good example of a multi-page application. How can we see it? Just click any link and watch the reload icon on the top of your browser. You see that reloading has started because a browser is now reaching out to our public server and fetching that page and all the resources needed. The interesting thing about multi-page applications is that every new page is downloaded. Every request we send to the server, like whenever we type a new URL or click on a link, leads to a new page being sent back from the server. Notable examples of multiple page applications are giants like Amazon or eBay. Using them, you always get a new file for every request.

MPA is an excellent choice for websites that provides mostly read-only content. SPAs usually supplies a better user experience when our application is more like an interactive application.

On my github repo you’ll find a demo app based on auth0 SPA Angular quickstart. It is integrated with a .Net Core 3.1 backend. The purpose is to demonstrate how to use auth0 to secure Api calls to a NetCore31 app from an Angular 8+ SPA.

To make it work you need to:

1. Have a auth0 subscription.
2. Create an Application and a API.
3. Edit following files with your auth0 configuration info:

• \auth0-backend-demo\appsettings.config
• \auth0-angular-demo\src\app\auth.service.ts

1. In the angular app install the npm packages: cd .\auth0-angular-demo
   npm install
2. start the angular app: npm start
3. Compile and run the .NetCore Api app: cd .\auth0-backend-demo
   dotnet restore dotnet run
4. Open your browser and navigate to http://http://localhost:3000/

To better understand how to configure your app it's recommended to first complete the auth0 angular2 quickstart.

Have fun!

Feature teams is one of the ways of scaling agile over a larger organization, you divide your organization in many feature-teams.  The core idea is that the team structure is not organized by component or technical layer.  The team is long-lived, it says together but the work is cross-functional and cross-component.  The team work on a complete customer-centric feature across all components and disciplines.  Feature teams organization will diminish the need for handoffs and so waiting time what will result in faster delivery.  My personal feeling is that adopting feature teams is certainly not an easy goal to achieve certainly not for maintenance teams.  I’m also afraid that it can also lead to unmaintainable systems over time.

The first big problem I see with feature teams is the lack of accountability.  Having everyone being responsible can rapidly become indistinguishable from having no one responsible.

Another big problem is that following  Conways Law this type of organization will produce a big fat ball of mud architecture => a system without clean interfaces.  A system without clean interface is also a system you can't  redesign or change without having to deeply understand the neighboring modules. In the end it makes the system unmaintainable.

So when you want to benefit from the improved productivity of feature teams, you also need to take care of two things: discipline and design.   you need to follow the principles of weak code ownership.  Basically this is the open source model of collaboration. Everyone can participate but they need to follow the rules of a despot that owns the module.  This despot is by the way also taking responsibility of the support and will ensure that good practices as  continuous integratione and unit testing will be followed and that the code quality stays a priority.  No one can check-in code without his approval.  If you need to integrate changes inside a module you need to request a Pull-Request to the owner.  You need also a strong Architecture team responsible to define how the system is divided in modules. This team is responsible to define clear boundaries and to ensure that the feature-teams respect these boundaries. 

Databases and applications should coexist in the same deployment pipeline. They should be versioned and packaged in the same way and they should share a single development lifecycle. This will enable the team to treat DB deployment like any other software deployment.  To achieve this with SQLServer you can use DbUp, it’s a simple but very effective migration tool.  Have a look at they getting started doc: https://dbup.readthedocs.io/en/latest/

Link to my presentation about "Best practices on how to architect for faster and better delivery in the Enterprise".

Continuous Delivery in the Enterprise.pptx (3.79 mb)

Large monolitic applications are characterized by big bottlenecks that slows down the entire process.  The dependencies causes a significant overhead on your deployment throughput. Cycle times are longer because of the slower builds and automated and manual tests required to validate the entire app. This creates a lot of friction in the pipeline. Dependencies brings complexity what increases the development time. Complex code bases have more opportunities for bugs what causes many waste. The dependencies also lead to less opportunities for parallelizing the work. To be able to work in group, developers need to create branches so that developers can work in isolation but this demand also to merge more often what also demand a considerable effort. 

For me bottleneck number one is Manual Testing! Manual Testing is a tedious process when the test cycles are repeated frequently. Therefore many teams adopt test automation but before they can do test automation they first need to create test data. Only when teams have adequate test data they can run automated tests, and can create that data on demand, they see better IT performance, lower change failure rates, and lower levels of deployment pain and rework. The problem with large monolitic applications is that they also go with big databases and how bigger the database how more difficult it is to manage. When the test data is difficult to setup or reason about then it become difficult to do any meaningful test automation.

Conclusion, if your database is a monolith your delivery process we’ll suffer from bottlenecks caused by lack of test automation and also by communication/coordination overhead even if you have a service oriented or microservice architecture on top of it. 

In the classical view of software delivery, you need to make a trade-off between quality and speed. The traditional IT delivery process paradigm postulate that building quality software will demand longer to deliver. You trade quality with getting things done rapidly. Now, studies on teams that have adopted Continuous Delivery (CD) demonstrate exactly the opposite. Teams able to deploy by the push of a button not only deliver faster but they deliver better quality in a more reliable way.

Being able to push changes fast and reliably to production changes the rule of the game and transforms many aspects of the IT delivery process.  It reflects on aspects like:

Increased Availability & Manageability

Because you can push changes a lot faster you can make smaller changes with less downtime you don’t need to come in the middle of the night or weekends to deploy the system.  This means less overwork and stress for the team’s members. It also frees up a considerable amount of time as teams don’t need to participate at long lasting release planning's sessions to coordinate huge deployments.

Because you know you can push a change fast you’re also able to remediate faster and you don’t need to take account of being able to reverse a giant change. In place, you can adopt release strategies where you always advance forwards. In place of reverting a change you can be confident that you can fix any problem fast. This simplify the release process and lower the investment needed in process, infrastructure and tools to be able to revert back a giant change.

Reports also demonstrates that teams practicing CD sees their number of big incidents diminishing drastically. Apart from the better intrinsic quality that CD brings this is also due to the automation that CD demands.  The automated deployment pipeline eliminates errors that might result from manual configuration and error-prone practices. 

Increased efficiency and cycle time
Because you make smaller changes your tester and analyst can work in a constant flow of work.  They don’t need to test everything in a great batch at the end of the release but can continuously work in at constant pace together with the developers.

Because bugs are also detected sooner they are cheaper to fix.  When practicing continuous delivery automated tests are run immediately after each check-in what detects many bugs immediately.  The developer can get immediate feedback even before he starts working on another task and so he knows where to search for the bug.  It’s proved by many studies that bugs found before or immediately after the check-in are orders in magnitude cheaper to fix (sometimes more than 100 times).   *https://www.researchgate.net/publication/255965523_Integrating_Software_Assurance_into_the_Software_Development_Life_Cycle_SDLC

Improved testability

To be able to deploy small changes independently the systems needs to be decoupled.  This decoupling enables also to test the system more easily in isolation.  Most of the changes can be tested without deploying to an integration environment. This lowers the number of environment needed and allows for a more rapid feedback. 

Improved intrinsic product quality

Because the tremendous acceleration of time to market of a change, from once every 3 months to many times a day, product owners can experiment a lot faster enabling new product evolution strategies based on experimentation and continuous improvement.  The book Lean Enterprises describes in detail how modern software companies takes advantages of continuous delivery to design products based on experimentation.

Improved Customer Satisfaction

CD brings confidence to the customers and other stakeholders on the delivery of their new features.  CD enables to deliver new features at a constant and predictable pace and increase the visibility of the delivery process.  By practicing feature toggles and decoupling the deployment from the actual release of the feature it enables to deploy a part or a complete new capability to early adopters.  

Because organizations are more effective they can spend more time on value adding activities.  This creates a virtuous circle of continuous improvements that brings a decisive competitive advantage.  Continuous Delivery is becoming the norm in the enterprise. IT organization that still stick to the old delivery model will be forced to change or will simply disappear.  Following the 2015 State of DevOps practices study, the companies who their IT team’s practices continuous delivery has 50 % higher market capitalization growth over the 3 last years than the other and Gartner predicts that by 2020 50% of CIO’s that have not transformed their capabilities will be displaced.  

Continuous delivery is the ability to get changes into production safely and quickly in a sustainable way. 
It’s not only about deploying code in production but it’s about bringing all type of changes that helps to deliver value faster. This includes all types of IT infrastructure changes, software configuration changes, deploying data and schema migrations, …
It is a capability an enterprise need to develop and learn. Because it’s based on new paradigms that demands deep organizational changes, it’s not something an enterprise can acquire in a box but it need to develop it through a change journey.

It took Amazon or Facebook years to change their organization and architecture so that they could be sustainable by delivering faster. It can demand tremendous efforts and changes to the culture and architecture. 
Like any big change in an organization it’s not linear, how you will achieve the goal is largely unpredictable. Therefore like any change in the enterprise, it need to be carefully managed to ensure that current operations are not adversely affected.

When building new apps, you need both client and server-side pieces.  This article focusses on how to structure a SPA that is made out of angular for the client and dotnet core for the server.

There are numerous questions I needed to answers when mixing these technologies.

• Should I host my angular app inside an MVC View or just serve the angular app from static files.
• Should I host the angular app inside the same application that serve the Web-Api or serve it from a separate site?
• How to setup a productive development environment?
• How should I integrate angular-cli together with a ASP.NET Core app?
• Should I use Vs.Code or VisualStudio ?
• How to package and deploy the application for on prem or in the cloud?

Of course, the answer to all these questions is always the same: it depends! After experimenting with several options, I finally decided that I should go for the simplest solution that could possibly work and started with just serving static files inside a Web-Api application.  Yet, during development, what I found the most productive, is to completely separate the Angular app from the Web-Api solution. I like that my Angular and the ASP.NET Web-Api apps live separate folders beside each other. It’s only at build time that Msbuild assemble the parts by calling “ng build”.  To do that I needed to configured angular-cli to output the build in the \wwwroot folder of the ASP.NET app.

Concerning the IDE, what I found the most productivity was to develop my angular app using Vs.Code.  Thus far, for the Web-Api part I tend to prefer VisualStudio and Resharper. So, I optimized my Angular app for working with Vs.Code and my Web-Api project for VisualStudio.  During development I usually run the backend and launch the Webpack dev server through an “npm start” command.  At publish everything is nicely packaged together inside a ASP.NET app, so deploying to Azure can simply be done by using the VisualStudio publish wizard.  

On my github project core-angular-example, you can download the solution template I use for making SPA’s with Angular-cli and DotNet Core.

Here I explain the steps you need to follow to setup the basis of such an app:

0) First you need to install:

• Code
• Donetcore
• js
• Angular-cli

1) From a powershell console:

mkdir angular-dotnetcore
cd angular-dotnetcore
mkdir web-api
cd web-api
dotnet new webapi
cd ..
ng new angular-app

2) Open VisualStudio code and open the angular-dotnetcore folder

3) Disable TypeScript compilation
Since we will eventually have TypeScript files in our project, we should also disable any TypeScript compilation errors. Open the web-api.csproj file and modify the top PropertyGroup:

  <PropertyGroup>

    <TargetFramework>netcoreapp2.0</TargetFramework>

    <TypeScriptCompileBlocked>true</TypeScriptCompileBlocked>

    <TypeScriptToolsVersion>Latest</TypeScriptToolsVersion>

    <IsPackable>false</IsPackable>

  </PropertyGroup>

4) Configure Startup.cs
As our web-api app will also serve the static files we need to configure the Stratup.cs file as follow:

public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
    if (env.IsDevelopment())
    {
        app.UseDeveloperExceptionPage();
    }

    app.UseDefaultFiles();
    app.UseStaticFiles();

    app.Use(async (context, next) => {
        await next();
        if (context.Response.StatusCode == 404 &&
            !Path.HasExtension(context.Request.Path.Value) &&
            !context.Request.Path.Value.StartsWith("/api/")) {
                context.Request.Path = "/index.html";
                await next();
            }
    });

    // Configure application for usage as API
    // with deafult route '/api/[Controller]'
    app.UseMvcWithDefaultRoute();

    // Serve static files
    app.UseStaticFiles();
}

5) Configure angular-cli to output the build inside the wwroot of the web-api app =>
edit the .angular-cli.json file and change the OutDir parameter:

"apps": [
    {
      "root": "src",
      "outDir": "../web-api/wwwroot",

Now when running ng build inside the angular-app angular-cli should output the result inside the wwroot folder of the web-api app.

6) Modify the angular app to consume data from your web-api
Edit the following files under /angular-app/src/app file=>

App.module.ts:

import { BrowserModule } from '@angular/platform-browser';
import { NgModule } from '@angular/core';

import { AppComponent } from './app.component';
import { HttpModule } from '@angular/http';

@NgModule({
  declarations: [
    AppComponent
  ],
  imports: [
    BrowserModule,
    HttpModule
  ],
  providers: [],
  bootstrap: [AppComponent]
})
export class AppModule { }

Modify app.component.ts:

import { Component, OnInit } from '@angular/core';
import { Http } from '@angular/http'
@Component({
   selector: 'app-root',
   templateUrl: './app.component.html',
   styleUrls: ['./app.component.css']
})
export class AppComponent implements OnInit {
   constructor(private _httpService: Http) { }
   title = "DotNet Core Angular Example";
   apiValues: string[] = [];
   ngOnInit() {
      this._httpService.get('/api/values').subscribe(values => {
         this.apiValues = values.json() as string[];
      });
   }
}

Edit app.component.html and add this as last lines of the html file:

  <li>
    <h2>Values from ValuesController</h2>
    <p *ngFor="let value of apiValues">{{value}}</p>
  </li>
</ul>

7) Redirect api calls to your DotNet core app

To be able to redirect api calls from your angular app when running  in the webpack dev server you should create a proxy.conf.json file on the root of your angular app.  Here my dotnet webapi runs on port 5000:

{
    "/api": {
      "target": "http://localhost:5000/",
      "secure": false
    }
}

You can already test your app:

• launch the web-api app with

dotnet run

• Launch the angular app and pass the proxy configuration:

ng serve --proxy-config proxy.conf.json

• Launch Chrome and open http://localhost:4200/

8) To be able to use npm script commands edit the package.json of the angular-app and edit the script section:

"scripts": {
    "ng": "ng",
    "start": "ng serve --proxy-config proxy.conf.json",
    "build": "ng build",
    "build-prd": "ng build --prod --env=prod",

9) To be able to invoke these commands from you web-api, add a package.json inside the root of the web-api app containing.  Here we declare the same commands but first cd to the angular-app:

{
    "name": "core-angular-example",
    "version": "0.0.0",
    "license": "MIT",
    "scripts": {
        "install": "cd ../angular-app & npm install",
        "start": "cd ../angular-app & npm start",
        "build": "cd ../angular-app & npm run-script build",
        "build-prd": "cd ../angular-app & npm run-script build-prd"
    }
}

10) Finally, we configure our web-api MsBuild script to invoke the ng build script when running a release build. Therefore, we add the following targets to it:

<Target Name="EnsureNode">
  <Exec Command="node --version" ContinueOnError="true">
    <Output TaskParameter="ExitCode" PropertyName="ErrorCode" />
  </Exec>
  <Error Condition="'$(ErrorCode)' != '0'" Text="Node.js is required to build and run this project. To continue, please install Node.js from https://nodejs.org/, and then restart your command prompt or IDE." />
</Target>

<Target Name="ReleaseRunNgBuild" BeforeTargets="Build" Condition=" '$(Configuration)' == 'Release' ">
  <CallTarget Targets="EnsureNode" />
  <Message Importance="high" Text="Install packages..." />
  <Exec Command="npm install" />
  <Message Importance="high" Text="Performing ng build for prd build..." />
  <Exec Command="npm run-script build-prd" />
</Target>

Now when you launch a Release build everything will be build together. 

You can get a package containing all your app by using the publish command.

If you want to publish your site to azure simply use the VisualStudio publish wizard or the Azure Powershell Publish commands.