Years ago in my another blog post, I mentioned Microsoft has plans to make .NET open source and multi platform. In that time mentioning “open source” and Microsoft together was quite unusual and I was quite skeptical that the project will end up being a success. Yet the first two versions of .NET Core was so unstable to be used in a serious production project. So my early impression was the .net core project was heading towards the Microsoft scrapyard (next to webmatrix, silverlight and others)..
Well; in the end, I was wrong. Today we have .NET Core version 3.1, and it is not only mature and stable enough, it is more modular, scalable, future proof and actually much faster than the .NET framework itself. In fact Microsoft is currently planning to replace their .NET framework with .NET Core in their future release .NET 5.
And what about the new ASP.NET Core 3.1? Should we, eventually, invest time to learn it and use it in our next project? Absolutely yes, I recommend it not only for Web/Backend developers, but for whole Microsoft stack developers. It is the MS development technology of the future. Here I explain why:
A look at the future
What used to be our all time classic infrastructure model for developing enterprise applications? The quick answer is the “server-client-database” tier model. Here is an example, infrastructure of ERP product Microsoft Dynamics AX :
In this model, whole business processes of a multi company entity (ledger, sales, purchase, inventory management, production, enterprise planning etc.), plus the communication with database and client application is handled by a single, almighty Application Server (AOS). As demand from this almighty server app increases, we used to add more computing power to our server, use SSDs on DB server, setup a load balancing system, implement multi threaded programming approaches, setup replicated DB servers to serve data from near locations and so on. No one of these would give us a significant long term relief in performance because all in all we are trying to strengthen a single server application that handles all the process itself.
Since then, a lot has been changed in technology and we have much better resources to develop a better infrastructure model. Our network communication speed is much faster, and not a bottleneck in our infrastructure anymore. Also computing power is much more accessible. Having a big server stack with multiple fast servers is no more a luxury. Even the cellphones you hold in your hand has computing power enough to serve a web site in it. And there is the “Cloud” transformation… So our all time classic client-server tier infrastructure is not the optimal way of building such an application anymore.
The future generation infrastructure model is called “microservices”. Microservices are basically a combination of multiple API services performing different parts of an enterprise application, running inside separated computing units and communicating with each other. Here for example, in our ERP application, we could separate inventory, ledger, sales, purchase and production parts in different APIs, set them separate database servers and make them communicate each other through their API methods and eventing. And our client application could connect to multiple API services asynchronously in separate threads to load the data needed for its UI in a much more optimized way. Today microservices brings a lot advantages over classic server-client tier approaches (should write another blog about it) and in the near future no producer and end user will say no to these advantages. For this reason, it is essential today for every developer, no matter what platform you develop with, to learn at least one backend technology to perform microservices development.
So; how our brand new ASP.NET Core handles that backend development process?
Modularity
I am quite impressed with the effort .NET Core development community put on the new ASP.NET Core development. Many annoying, obsolete and poorly performing stuff in old ASP.NET do not exists anymore in ASP.NET Core. To give an example, you do not have the horrible web.config stuff anymore. Everything your service needs, is added inside your service’s initialization code inside your ‘Startup’ class, using individual components called “middlewares”. You have quite a lot of flexibility in setting up a service that performs only what you need from it. The code below is the example of a Startup class initialization code:
// This method gets called by the runtime. Use this method to add services to the container.
public void ConfigureServices(IServiceCollection services)
{
services.AddRazorPages();
}
// This method gets called by the runtime. Use this method to configure the HTTP request pipeline.
public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
if (env.IsDevelopment())
{
app.UseDeveloperExceptionPage();
}
else
{
app.UseExceptionHandler("/Error");
// The default HSTS value is 30 days. You may want to change this for production scenarios, see https://aka.ms/aspnetcore-hsts.
app.UseHsts();
}
app.UseHttpsRedirection();
app.UseStaticFiles();
app.UseRouting();
app.UseAuthorization();
app.UseEndpoints(endpoints =>
{
endpoints.MapRazorPages();
});
app.Run(async (context) =>
{
await context.Response.WriteAsync("Hello");
});
}
Here for example, if you would like your API service to echo “Hello” and do nothing else, you would remove the rest from the services and only leave app.Run() method. Then you have a very lightweight web application that only echoes “Hello”. Another example, if you would like to setup two servers for your web site, one with high CPU power optimized for serving server pages and one with faster network speed optimized to serve static files (pictures, videos etc.), then you would remove the “app.UseStaticFiles()” from your main server and remove all else from your static files server. This allows each server to only allocate enough resources to perform their roles. Doing such things was a pain in classic ASP.NET and no matter how small, web applications required high resource consumption because of the dependency on IIS server.
Multi platform
ASP.NET core actually does not require an IIS server to be executed at all. If you place it inside IIS, it uses it as a proxy and does not require Managed .NET framework setup in the application pool. It can also run inside its own thread without the need of any web server, which is called the “self hosting” feature. Further there is a direct support for Docker containers (most popular virtualization system for microservices and kubernetes today), Nginx server and Linux.. Well, in fact, let’s talk about the Linux part.. I have tried to run an example application that uses asp.net core with MySql inside an Ubuntu server, and whatever I did I could not get it working. There are quite a lot of prerequisites for Linux server to run ASP.NET core in it, and many are not so easy to set up. Later in a blog post I have read another developer who was able to get it running, but not quite stable, and he did not recommended using it.. So if your application requires Linux environment support, I would not choose ASP.NET Core at that moment. Hope in the future it will be more stable and we will be able to run websites on cheaper (or free) Linux servers.
Performance
New ASP.NET Core is much faster than the classic IIS dependent ASP.NET. In my quarantine break, I have converted my personal website from ASP.NET 4 Razor Pages to ASP.NET Core 3.1. In the end, I have a much faster and modern website with minimal, ‘acceptable’ glitches here and there. Remember that, ASP.NET Core uses modern server techniques to scale your page loading, supports latest VS tools for minifying your code and there are a lot of third party libraries you can use to increase your overall performance. Also the server pages can be pre-compiled into native code instead of runtime compiling of intermediates, which gives you a nice performance boost on page execution. I share the before-after GtMetrix performance reports below and let them speak for themselves:
Modern coding
ASP.NET Core is ‘out of box’ integrated with many modern coding features and full support for modern C# 8 language. Most remarkable is the new dependency injection feature. For the ones who do not know, we could shortly describe dependency injection as a new coding technique to replace old class/module sharing practices, for example creating singleton class instances to be shared in between different class modules. Usage in ASP.NET Core is very simple, you create a class which you need to share across other modules and add it as a service in ConfigureServices() method of your Startup class. Then if you reference this class as a parameter in your constructor method of another page, controller or service class, your class instance is automatically passed by the dependency injection mechanism. For more info you can visit :
https://docs.microsoft.com/en-us/aspnet/core/fundamentals/dependency-injection?view=aspnetcore-3.1
Data access
ASP.NET utilizes the new high performance EF Core for its data access. EF Core out of the box supports connectors for many popular database technologies and provides unified “code first” approach to create database objects and queries independent from the database platform. However; there are some glitches with it.. The MySql connector I have tried did not work properly for a “DB first” import of an existing MySql database and I had to use the community alternative ‘Pomelo’ connector. Also some complicated joins with Linq did not work as expected, so I have switched to alternative approaches instead of direct joins. But all of those are negligible considering the complexity of supporting different database platforms and most of the framework works flawlessly. I am quite impressed with it.
Blazor
Blazor is the future technology of web development by Microsoft, that runs .NET Core code in browser tier, as well as the server tier, using the new Web Assembly technology. In my previous blog post about web assembly I have mentioned such a technology from MS is on its way and today it is partially available and not completely published yet.
But; why would we need running .NET code in client side instead of rendering our asp.net page on server side? In ASP.NET Core we can create web pages with classic server side page rendering using the “Razor” scripting. But similar to our previously mentioned server-client tier models, the method of rendering web pages from a server application is getting obsolete. It is being replaced with intelligent web page applications that do AJAX calls to multiple web APIs to load its page data inside dynamic HTML components. New technologies like Angular and React works like that, but Blazor on the other hand runs on both server and client tiers and also supports offline execution in browser if connection to a server is not available. This is quite a game changer in today’s web application development and we will see how it will change our approaches to build a web application.
Community packages
Before the “open source” happened, the package library of ASP.NET was looking like bare empty desert compared to PHP, Node.js, Python,Ruby and so on. With ASP.NET Core, it seems the third party packages are blossoming with some really useful ones. Pleased to be able to use some of them for my own website project, like SkiaSharp high quality image resizing package. There are also some super speed JSON reader packages now, much faster than classic Newtonsoft JSON or .NET serializers.
However; compared to other platforms, there are still some essentials packages are missing, such as a package allowing you to deliver compressed content to the browser. I think it is just too early and it will sure get there in the future with the current .NET Core community support.
