These days I don't write code for a job (unless you call email and Slack "writing code"), and though I do get my hands a little dirty with architecture, I get the itch periodically to exercise those coding skills. Fortunately I have those sites that have been with me for about two decades, plus POP Forums, which even had a couple of pull requests in the last year. I feel like niche community sites have some potential for a minor comeback, with all of the distaste for "big social" (I just made that up).
Here's the thing, the forum app does everything I need it to do today, so there's no huge incentive to mess with it. It's super SEO friendly, works mostly well on mobile and can scale to hundreds of requests per second if it had to. Just by cloud scaling the app (up, not out), I could quite easily get it to 500 rps with no code changes at all and it would still be reasonably responsive. I totally don't need that personally, because real traffic tends to burst to maybe 10 rps on a normal day. I've not even tried scaling out. Still, being as old as the app is, it needs to catch up in some ways. It took me almost three years to bring it to .Net Core, as I started from the early betas and it changed so much that it was a pain to get it there. But at least from a back end standpoint, it's reasonably modern. I have a wish list...
- Adopt a new front end framework where practical. Forums are 98% static pages of text in terms of usage, so there is no good reason to make it a single-page application (SPA), and in fact with Google's evolving algorithms, that's risky anyway and might harm SEO. But there are areas where you can create silos of SPA-like functionality. The admin side is one area, which isn't indexed anyway. Some of the auto-updating and the user stuff could benefit from it as well. Today there's some fairly lean jQuery in there. I could never make a business case for these changes, but for just learning something new, I can. I'm leaning toward Vue.js, because it's well suited to these silos.
- Finish the Azure Kit pieces. I already added some stuff to accommodate the use of Redis for caching and Azure Search, but didn't go as far as making a box to put the background services in Azure Functions and use proper queues. This isn't hard to do at all, which is why it's appealing. This would further help with the scaling that I don't need by moving that work to a different kind of compute resource, and enable multi-instance capability by getting it out of the web process.
- Get back the unit testing on the web project. When I ported to ASP.NET Core, I ended up ditching most of the unit tests at the controller level. It doesn't make sense to do any of that until I figure out the previously mentioned front end bits, and I also don't care much for where the lines are between business logic and the controllers. Some of the decision making is in the controllers where I don't like it, which is an artifact of being code that's a decade old.
- Make the web app all package installs. I'm part of the way there. You can package all of your views now into a NuGet package, so it's way easier to build a bigger app around it, like CoasterBuzz. Even now, I publish the latest build to a private NuGet feed as part of the CI process, so getting the latest bits into CB is easy. You can override any individual view as necessary with a local file. I need to go the rest of the way with the front end dependencies though to shore this up. Minimizing should also be part of the process.
- Update Bootstrap. There has been a major new version of Bootstrap since I last approached style. It's different enough that there's some work to do there. I've never embraced any of the LESS/SASS for this project because there isn't much incentive to as an open source project. I set no colors or other variables. The CSS there is makes up for around 200 lines. I'm pretty happy that it mostly uses the conventions there.
- Configuration cleanup. I'm pretty sure that config is done wrong, because that evolved during Core's many changes as well. I don't think localization is done right either, though it definitely works (six languages!).
- Get the data plumbing cleaned up. Among the weird remnants of 2004 is the fact that you can't instantiate some domain objects without passing an ID into the constructor. This is a throwback to the days when I put CRUD logic in with domain objects. In my defense, that's the way we did it back in the day, when we didn't have ORM's and DDD wasn't widely practiced. I also have a series of little extension methods to streamline all of the SQL connection and command stuff. As much as I'm not crazy about taking dependencies on frameworks, I'm thinking about adopting Dapper to handle all of that.
That all will keep me busy for a long time, I suspect. Walt and I have vague and poorly defined desires to update PointBuzz, which is still running on the "old" ASP.NET MVC. Part of that might be exploring some traditional social media-like features, in which case having a solid base is important. I enjoy working on this stuff, but it's not the easiest thing to do as a hobby because it still requires you to be really plugged in and focused. That's not always easy when you just want to have a glass of wine and passively hang out after work.
I still, casually, wonder if I should work the app into a hosted, multi-tenant solution. That's a surprisingly uncrowded market. The persistence layer is so well isolated that it wouldn't be hard to get there. It would be worth it even for a few hundred bucks a month of slush money.