The recording from the second live stream is here:
Few days ago, I have done a live coding session - in the first part, I was building the core of event registration system.
I really enjoyed it, so here is the date for the next session: Tuesday, December 19 at 6:30 PM (Central Europe Time).
This time, I will be building the core of the admin portal in DotVVM that will allow to manage individual events and reservations.
The live coding session starts on Tuesday, 12 December at 6 PM
(Central Europe Time) on my new Twitch channel.
Recently, I have seen Jeff Fritz doing live coding sessions and it looks like a great idea. I was thinking about something similar months ago, because I’d love to create as much content about DotVVM as possible, and so I decided to try it too.
In November, we are preparing a conference called UPDATE. It will happen in Prague, Czech Republic, and there will be more than 20 foreign speakers - Microsoft employees, RDs and MVPs talking about .NET, cloud and security related topics.
We were looking for some event registration system recently, but because of many reasons (such as Czech legislation requirements), we have decided to build our own one. Since this is not the only conference we are doint, the system will allow to host multiple events, offer tickets with different prices and use various cancellation policies. We’d like to open source the core of the project, and it will be also a nice sample app for DotVVM.
The first live stream will start on Tuesday, 12 December at 6 PM (Central Europe Time). Follow my Twitter @hercegtomas - I will announce the URL of the stream there.
The plan is to build the database, then a REST API exposing the core functionality, and finally the DotVVM application which will allow the attendees to register and which will allows the organization team to see and manage the orders.
I don’t know how many things I will manage to do in 2 hours, so there may be other live streams where I will continue.
Parts of the series
.NET Framework has always been very popular and widely used in enterprise environment. There are tons of business-oriented applications written in .NET.
From its first version, .NET enabled the developers to build both desktop and web applications, and especially at the beginning, it was really easy to use. Amateur developers, students or even kids were able to create a simple Win Forms app and Microsoft tried to make web development as simple as Win Forms or VB6. That’s how ASP.NET Web Forms was born.
Despite the fact Microsoft has moved their attention to ASP.NET MVC years ago, ASP.NET Web Forms is still very popular and there are many web apps using it. They needs to be maintained and extended with new features.
Microsoft has been working on .NET Core lately, but there are not plans to bring Web Forms onto this new platform. Of course, Web Forms is supported as long as .NET Framework is supported, so there is no need to panic, but still…
Everyone knows that it’s time to move on. But where to?
Imagine you are a Web Forms developer taking care of a 15 years old web app. The app probably doesn’t work perfectly in modern browsers, imposes a possible security risk as it uses outdated libraries, and the users complain every other day about the UX because the app needs to reload the entire page on every click. And “Hey, there was no JavaScript in 2002!" is not a really good explanation.
You suggest that the app should be rewritten on every meeting during last five years, but nobody listens or the answer is always the same - there is no time or money for that. You know that there is a huge technology debt, however the application must survive next 5 years and there is a backlog full of new features and screens to be delivered – and they need them yesterday.
If the application is 10 years old, there is no reasonable chance it could be rewritten in less than half of that time. And of course, no company can stop evolving its business critical app for 5 years while it is being rewritten.
Starting to build a new version in parallel with maintaining the old one can be a way to go, but it is very expensive. The development team needs to be doubled, and it requires a massive communication between both teams as there is typically a huge amount of know-how to be transferred. A lot of time is spent with studying how (or even why) the old code works because its original author now works somewhere else.
That’s why many companies are trying to modernize their solutions. In the ASP.NET Web Forms, there are some ways how to slowly migrate to a more modern stack – screen by screen, module by module. The path is long and sometimes painful, but it allows to keep introducing new features and extend the lifetime of the application, at least for couple of years.
There are several things you can do to modernize your old ASP.NET Web Forms applications. I will try to address these topics and decisions in the next parts of this series, but here is a quick overview:
You can use modern front-end framework for new modules of the application. The choice of the UI framework depends on the type of the application and also on the skills of the team. The new parts of the application can use a completely different UI stack, but if they use the same CSS, the users won’t notice. In the meantime, the old screens may be rewritten to the new technology one by one.
There are many improvements for the business layer that can be done. Of course, monolithic applications cannot be converted to microservices easily, however some parts of the business layer can often be extracted and maybe containerized. The business layer class libraries can be converted to .NET Standard, which will allow them to be consumed from .NET Core.
Moreover, SQL might not be the right store for everything. Most of the ASP.NET web applications store all their data in a SQL database. Sometimes, it is a good idea and the relational approach is necessary, however using another type of storage in some parts of the application might remove a lot of complexity. In addition, there are new laws and regulations concerning data privacy (GDPR for example). You should review which personal data you have and who can access them.
And remember that modernization is an opportunity for refactoring, cleanup and introducing new concepts. If you are not using dependency injection or automated tests, you should seriously think about starting with them now, at least for the new parts of the application.
Also, you should think about the overall architecture of the application. Maybe some parts can be moved in the cloud, replaced by something else and so on. If there is something that doesn’t scale, it should be the first thing to think about. Create a list of priorities and try to address the ambitious plans for next years in the design.
Next part: Modernizing ASP.NET Web Forms Applications (Part 2)
This weekend, I have been talking about DotVVM at Get.NET in Gdansk, Poland. The conference was awesome, if you live nearby, definitely visit it next year!
Demo:
https://github.com/riganti/dotvvm-samples-order-management
Slides:
We have organized a small conference called The Future of ASP.NET last Friday.
Me and Michal Valasek have been playing with the idea to do it for quite a long time, because since the day Microsoft announced that ASP.NET Web Forms is not going to be supported on ASP.NET Core, we have got thousands of questions from many people and companies. There are many ways to build a web application and it is not easy to choose the right technology. Especially when you are a developer with strong .NET skills but little knowledge of JavaScript.
We had more than 100 attendees at the conference and 5 sessions in total. We started with an introduction to ASP.NET Core, MVC Core and Razor Pages. Then we had sessions about Angular and React, and I had the last session about DotVVM - an open source framework which I have started 3 years ago and which simplifies building line of business web apps.
Most of the attendees still have some web applications written in ASP.NET Web Forms. Many of these applications are more than 10 years old and it is almost impossible to rewrite them from scratch - the companies and businesses rely on them and rewriting these applications would take years.
We have got a lot of positive feedback about the conference, but I have also seen a lot of sad faces. I have talked with several attendees and the sessions made them realize how difficult it is to rewrite the application and possibly switch to Angular or React.
Not only that the dev team needs to learn a lot of new things - new languages and concepts (Typescript, how modules work, REST API), libraries and tools (Nodejs, npm, webpack) and things like how to deploy these applications. It often means a change of the architecture of the application (building a REST API which exposes the business logic) or a complete change of the mindset (especially when you are switching to React which is functional).
There are also a lot of stakeholders (customers, managers) that need to be convinced that rewrite is worth the effort (and actually, sometimes it is not true). Rewriting the entire application with 10 years of history cannot be done in a significantly shorter timeframe. And finally, it is difficult to deliver new features while the team rewrites the solution.
Of course there are also some benefits: getting rid of the technological debt, introducing micro service architecture or CI/CD which can lead to a better quality and faster release cycles, the ability to make fundamental changes in the data model to reflect changes in the business processes and so on. The company will become more attractive to the developers because of modern approaches and technologies. But it is really a challenge and there are a lot of risks to take care of.
That’s why I decided to make a demo of integrating DotVVM with an old Web Forms application. A lot of people found this combination very interesting and it might be the right way that allows to slowly upgrade and modernize their old applications while keeping the old parts running and maintainable.
I have took the source code of DotNetPortal, a largest Czech website about .NET development I have created with my friend Tomas Jecha years ago. The app is written in ASP.NET Web Forms, uses Forms Authentication, hosts some WCF services and things like that.
I have replaced the Forms Authentication with OWIN Security libraries, which was the most difficult part actually, and I’ll publish a blog post soon about how to make this happen. Then I just installed DotVVM NuGet package in the project, added the DotvvmStartup class, and implemented a simple admin section. I have created a master page in DotVVM, copied all the contents from the Web Forms one and made only few changes to have the same looking master page in DotVVM part of the app. Because of the OWIN Security, I have a single sign on both parts of the website - the old one and the new one, and because of the same CSS files and same structure of the master page, the user won’t notice that there are multiple frameworks involved. And I can easily integrate with the old business layer without the need to expose it as a REST API, which would include a lot of work and refactoring and changes in the deployment process of the application.
In case of a real business application, this approach allows to build new parts of the application in DotVVM while keeping the rest of the application untouched. New parts of the application can be implemented in DotVVM which is more comfortable than writing them in Web Forms. The legacy parts can be maintained or rewritten one by one. Some of them may become obsolete over time and can be removed completely. The team can also work on refactoring and decoupling the business logic, and eventually, all the old parts may be replaced and the application can be ported to .NET Core and possibly containerized.
Of course, even this process can take years and includes a lot of challenges too, but it can be much safer way to adapt to the new platform.