Big build time ...
It’s been quite a while since the last set of changes were released, February 2020 in fact. I wanted to give some background as to why it’s been so long.
You may notice some significance with that date. The world locked down and remote working increased.
I too started working remotely and with a two hour commute out of the way came the opportunity to reflect on where toepoke was, and where it should go.
History
toepoke started life as a spreadsheet to try an organise 10 people meeting at the same place, same time, every week for a game of football. A task that’s always struck me as much harder than it should be!
A few years into changing roles it became apparent that spreadsheet should be a website.
The Perils of Prototyping
My approach was to build a Minimum Viable Product to quickly see if it was feasible to organise a group of people, just using e-mail. After all there’s little point investigating huge amounts of time to find it doesn’t work.
Even with this minimal approach it was still 3 years of [spare time] working to create that first beta version.
The theory of creating a prototype is you establish the thing works by focusing on completion rather than quality. Once you’ve proved the concept you throw the prototype away and start again. This time focussing on the quality (you can see where this is going 😉)!
Cut to 13 years later and it’s still running on that original code base, albeit with lots of stuff added over those years!
Moving to the Cloud
It’s been a long term goal to move the website to the cloud and it quickly became apparent the current architecture wasn’t going to cut it.
30 seconds to load the dashboard anyone? 😲
Clearly not feasible. In addition the codebase was becoming increasingly challenging to work with. It was time to pay off the last decade of technical debt.
Starting again …
A rewrite is rarely the answer but the reasons to do so were stacking up:
- Increasingly difficult to change. Even simple changes took a disproportionate amount of time.
- Lack of automated testing.
- High coupling bringing high risks of one change impacting the site elsewhere.
- Key components coming towards end of life.
- Newer tools and technologies we couldn’t take advantage of.
New architecture
Not entirely sure architecture is the right word, but for the geeks amongst you, here’s how it’s now organised:
- CQRS approach throughout.
- Every request has its own handler.
- Every response has its own handler.
- In total, there’s 97 of them, which gives you an idea how much is going on under the hood!
- Views for reads.
- Stored procedures for writes.
CQRS enables simpler unit testing, and whilst a little old school, views and stored procs allow much better isolation of functionality allowing us to do appropriate work nearer the database (i.e. less chattiness).
If there was one improvement I wanted to bring, it was improving the test coverage:
- 3,641 unit tests
- 1,001 integration tests
- 1,032 database tests
- 55 PowerShell tests
Does this mean the end of bugs? Not at all, but it does decrease the risk of introducing regressions and encourages more a rounded implementation of features.
As well as test coverage I also wanted to improve the data access. The existing approach was very chatty and, prevented any chance of a move.
Very happy with how that has turned out 🙂.
Closing
So what does all this mean for us organising our games of football? In short, not much, the same marmite design remains, all of the above changes are behind the scenes.
One thing you may notice (ironically given what I’ve said above!) are bugs! It’s very difficult to change everything without issues slipping through. If you see something you don’t think looks right, please let us know.