POP Forums roadmap

posted by Jeff | Friday, August 12, 2016, 4:00 PM | comments: 0

The volatility over ASP.NET Core made me pause (twice) since last fall when it came to porting POP Forums to the new platform. Every new release broke things to the point of frustration, and the RC2 reboot was hard. With SignalR falling a bit behind, it made things worse. But alas, that seems to be mostly behind us, and I've started committing stuff to a branch again, a little at a time, to run on the new ASP.NET. It's not at all usable, and every change seems to invite more changes, but I'm starting to see the potential and love for ASP.NET Core.

With the experimentation behind me, and a reasonable amount of stability, I'll start populating the issue log with tasks to do. I wanted to explicitly create a roadmap so I can stay focused. I do not have a timeline in mind, which is probably fine because I don't think people are flocking just yet to the new framework. The truth is that porting is not straight forward, and a lot of stuff can break. With that in mind, here's the plan...

POP Forums v14:

  • A straight port to ASP.NET Core, no new feature work. Right now I'm developing against .NET v4.6, but the goal is to go all Core. The two dependencies I'm using from the "old" framework are for image manipulation (the WPF stuff), and calling an SMTP server. Fortunately, it looks like ImageProcessorCore and MailKit will, respectively solve those problems and allow me to go all Core and cross-platformy. I may even try writing code on a Mac with JetBrains' Project Rider, if I'm feeling sassy.
  • Get out of the single-node problem. The app today depends on in-process caching to be fast, which doesn't work if you have to spin up to additional nodes. This requires some changes:
    • Use external caching, probably Redis. I've done a little testing, and it's super easy. It's also an easy to use service in Azure, where my stuff lives anyway.
    • Revisit background processing. A number of "services" run in the background in the context of the web app (sessions, emailer, search indexer, point/award calculation). These can probably run multi-node, or maybe as an option run stand-alone, but at the very least needs some queueing mechanisms or something. You don't want two instances trying to send the same email at the same time. Solvable problem, just need to think it out.
    • Need to figure out configuration for SignalR backplanes. Knowing there is a new post before you hit "reply" is important, and to this day my favorite feature.
  • Developer friendly. The documentation has not been well kept, and as long as I could figure out how to get it working in my sites, good enough. I don't want to be that guy anymore.
  • Secondary objective: See if the app itself can be packaged in a way that you can hitch it on to an existing ASP.NET Core solution.
  • Secondary objective: Refactor as time allows. There is still stuff written in the WebForms days that lingers, like 2002 linger, and it's not my best work.

That's it. It sounds simple enough, but it's a ton of work. I've ported much of the base library and UI stuff, but I'm still sorting through views and the conversion of things like HtmlHelpers to TagHelpers and using view components where it makes sense. Adapting slowly to claims based auth and middleware, but still not going to take any dependencies on Identity or EF. I've yet to port unit tests, but part of that is because I'm trying to really break stuff out into places that make sense. Part of that was getting MVC and SignalR stuff out of the base library, for example.

POP Forums v15:

  • Modernize the UI. I'm not sure what this means yet, but you can do things in a web app that were not possible before, due to the rich world of open source software. I don't think it means going to a full on single-page application (SPA) model, because of the effects around indexability and SEO, but there is potential for new things. The classic "UBB" style has some long-standing conventions that work, so the idea is not to get radical, but keep text at the center of the world.
  • Optimize for performance. Come up with arbitrary targets for page render times. Look for database tweaking opportunities (probably not much there, after 15 years of tweaking). Make a real effort to load test.

Going to Core makes this the fourth platform in the 16-ish years I've been at this silly thing. It started on old ASP, then ASP.NET WebForms, then ASP.NET MVC and now we move on to ASP.NET Core. It still forms the basis of CoasterBuzz. It runs in six languages. I hope to continue to maintain it for a long time to come, and welcome this next iteration.


Comments

No comments yet.


Post your comment: