A little over a year ago I shelved two projects that were going to be part of the 10Cv4 platform; Tasks and Notes. Tasks is a ToDo list that can consist of multiple groupings, with some groupings able to be shared with people you choose. Notes is exactly what it sounds like and was a first attempt to build something that might actually encourage me to stop writing so much stuff on paper every day. The reason these two tools were never released was because I ran into some problems with the structure of the v4 database that wouldn't quite allow me the flexibility I needed when structuring the data for these two items. The problem could have been worked around by creating new tables and storing things separately, but that would have broken the consistent relational model that I worked so hard to construct in the first place. Putting the code to bed for a year seemed the most logical solution while the subconscious went to work on solutions.
When I started designing the v5 database, I looked at all the things that worked with the previous versions and, more importantly, the things that didn't work. I needed to make sure that any future development was not going to be hampered by decisions based on an incomplete understanding of a problem. Some careful analysis showed areas that could be improved which would result in much better performance and a greater degree of flexibility for future enhancements to the system. The result so far has been an incredibly responsive v5 database and API that can do the Kessel Run in less than 12 parsecs with time to spare. All it took was looking at how I used to design databases and learn some new concepts1.
By examining the deficiencies in my passion projects, I get to look at how to improve them which results in a much better tool to share with the world. My code is still hardly perfect, but I'm much less embarrassed by what I see under the hood when others try to pitch in and point out areas for improvement. One of the many goals I have for 10C is to provide something that is both fast and reliable. By looking at areas that do not meet these criteria, failures can be converted into teachable moments that can result in some excellent fixes down the road.
Moving from MySQL 5.7 to MySQL 8.0 also made a rather large difference in terms of performance, as the newer database engine is far more efficient than the previous version. Using SQL Server was also a consideration as it would come with a number of advantages over MySQL, but I opted to use the "classic" web stack for the time being.