For the past few months I've been heavily considering migrating this blog from a custom .NET and C# application over to a Node.js and possibly React implementation (or maybe Next.js). But I've been hesitant, because after several long years the blog code that I wrote has gotten complex and convoluted. Some of the code isn't even used anymore in fact, but it sits hidden away under many a file and folder.
I'm also currently relying on ASP.NET Web Forms in order to run the whole thing. Which is a problem. And not because Web Forms are bad. Not at all. Having used Web Forms for over a decade, I can safely say that I was and still am a big fan of the technology. But Web Forms have not aged very well and support for it is decreasing by the year, meaning that at some point I will be forced to migrate my codebase anyway.
You can read more about my thoughts on ASP.NET Web Forms right over here.
But that's actually another reason why doing the conversion now, just makes perfect sense. The fact that the codebase has consistently expanded and that it has gotten beyond my grasp, is a great opportunity to majorly refactor the entire thing.
Not to mention that 7 years is a very long time in terms of a program's age. And that's roughly when I started to code out this blog. There's a good chance that big parts of that code are severely outdated at this point, and that's an issue both in terms of security and longevity.
All that to say, that I am probably going to be converting this blog over to a Node.js application before the end of this year. And that is going to involve alot of changes, including but not limited to all of the following.
Database migrations
Because my application is built using the full .NET stack, my database is currently living under SQL Server. And that's my first hurdle, because I'm uncertain whether I should maintain that the way it is, or to migrate the database over to something like PostgreSQL.
The biggest hurdle with this is that I would have to rewrite dozens of queries that are specifically designed to run in SQL Server over to PostgreSQL, and that can leave me with any of the following issues:
- Invalid data
- Slower queries
- Removing SQL Server specific functions
- Indexing issues
- Headaches
But on the other end, it can have many benefits as well, the main one being that on average PostgreSQL hosting online tends to be more generous with the amount of size allotted to your databases. Whereas my SQL Server currently has limited space and upgrading it isn't as simple of a process on a non-cloud provider.
Fortunately, there is a Node.js driver for SQL Server currently though, meaning that I might be able to get away with leaving the database untouched, at least for now.
Server implementation
Web Forms are great for rapid development. But it doesn't do a decent job at maintaining a separation of concerns, meaning a clear distinction between client and server. Everything is essentially in the same project and each web page is split into 2 components, the client and the code-behind.
This second time around however, I would very much prefer to keep two separate projects running individually ensuring a proper distancing between the client and the server architecture.
This isn't overall a very complicated step, but it is a very time consuming step because I have essentially zero code to start things off with for a server component.
More than likely, I will be going with something like Koa for this particular part of the implementation as I am already familiar with ExpressJS, and the team behind Express is also the team behind Koa.
Koa just seems newer to me meaning a better window for maintenance moving forward. Otherwise I'm pretty impartial to whichever Node.js framework I use.
Because this part of the app isn't client facing though, my only real concern here is with performance and with security. Anything else is icing on the already complicated cake.
New front-end
The most time consuming aspect of this conversion is going to be implementing the new front-end. If you are familiar with Web Forms, you'll know that they use special server controls that are specific for .NET Development, and they don't look anything like your standard HTML controls. For example:
<asp:TextBox...
<asp:CheckBox...
These represent your typical input box and checkbox, and the compiler ensures proper conversion once it goes to the client. But I can't just simply copy and paste this code onto a JavaScript based application.
Each and every server control has to be converted over to use its standard HTML form and every binding function has to be redone as well.
But in that explanation, you can see another huge benefit of moving my codebase over to Node, and that is the fact that my code becomes more portable. It is no longer constricted to having to run on a .NET server with compilation, which typically meant that I had to hunt down cheap Windows hosting providers.
By moving over to a JavaScript based app, I can run my code on Node.js, Deno or even Bun. And the number of cloud hosting providers definitely opens up.
API implementations
It may not seem like it, because it's just a blog, but this website has a fair number of API's implemented on top of it. And all of them were implemented using C# based solutions.
As part of refactoring for this conversion, I will undoubtedly have to convert each and every one of those into a Node.js based solution, and that is going to take time. Not to mention that the clever hacks that I came up with during the past few years will have to be left behind and forgotten.
Potentially though, another solution to this that might require less overall work would be to create another service still under .NET with all of the current API calls and implementations left untouched and to absorb that solution into the new client.
Definitely not the most ideal solution as it will increase my tech stack size and long term this might be more costly in terms of development time.
Still unsure, and more than likely will save this to near last on the list.
The admin
As with many websites, this blog has a very robust admin that I built in order to manage all content. And it makes up roughly about 60% of this entire website in terms of code and maintenance.
I won't be touching this code at all as it has been very stable and unchanged for the past few years. Instead, I will probably be migrating it out into its own server (still in the .NET ecosystem).
By doing this though, I will indeed have to make sure that I keep the same SQL Server database, as the admin is tied to it directly. Luckily, like I mentioned above, there are drivers for this exact situation.
So in a sense, by converting my client / server over to Node.js, I'm adding a bit more complexity to my entire tech stack, as I will still need to maintain SQL Server and various .NET applications running concurrently on the side.
But, it's a step in the right direction. Because I do plan on running this blog for many more years to come, and as of late, it's been a challenge to say the least to have a stable ASP.NET Web Forms environment setup locally for development.
By moving over to Node.js my hope is that I can have a lighter weight, fast performing and up to date application that I can easily make changes to in the coming months and that I can run on multiple machines easily without having to setup the entire .NET ASP.NET development environment.
So stay tuned for updates on how this conversion is going and sign up to my newsletter (modal window to the right) to read up on it in real time.
Walter Guevara is a software engineer, startup founder and currently teaches programming for a coding bootcamp. He is currently building things that don't yet exist.
Stay up to date
Sign up for my FREE newsletter. Get informed of the latest happenings in the programming world.