CMAP Engineering and where we're going next
Where we are now:
Here at CMAP HQ we’re currently working on version 2 of the CMAP app and over the past 4 or 5 years this has evolved massively. During that time we’ve added a ton of new features and functionality to enable our clients to manage their projects more efficiently. Whilst adding all this magical code we’ve had over 17k commits to our GitHub repo and we’re currently closing in on our 1500th release. Throughout, as an engineering team we’ve made a concerted effort to keep the code as clean as possible but due to the sheer pace we’ve been developing at (see commit and release numbers above) there are still plenty of places for improvement which has led us to start thinking about starting V3!
So why V3?
Over the past few years as a development team we’ve learnt a hell of a lot, not only about the technology that we use but also about the way our clients use our app and what does and doesn’t work for them. We’ve also learnt which parts of the app will suffer going forward as our customer base increases. We all know there are parts of the system that if we were to write them again today we’d do it differently. Some parts of the system have already gone through a number of iterations in design and functionality (CMAP Resourcing) and have now matured into a solid parts of the app but there are still remnants of the earlier versions remaining that we’d all like to tidy up. As CMAP has grown, the load on parts of the app has grown beyond initial expectation and this has lead to the odd bottleneck in performance. Where we’ve been able to we’ve fine-tuned the code to cope with the added load but we know that were we to be writing it again today we’d be doing it differently. Captain Hindsight to the rescue!
What we’re going to do:
CMAP’s data is currently stored in an Azure SQL database, going forward this won’t change, we have looked into moving to Cosmos DB but given the amount of data and the structure of that data the cost implications of moving just wouldn’t be worth it (we’ll probably end up using Comos DB for some new features we have planned though), plus we know we can get the performance we need from SQL with a little bit of work.
How we get the data out of our database is going to change though. We are currently using LinqToSql to retrieve most of our data and although this has worked well for us, it does have it’s limitations and it’s these limitations that have contributed to some of our performance issues. These were highlighted more than ever when we began writing CMAP BI. For our Report Builder we needed to be able to get a lot of data from the db and get it fast in order for us to produce the complex reports our customers require. To solve this we turned to Dapper and since then we’ve not looked back. In V3 we’re planning on replacing all our LinqToSql code and using Dapper for all data access. So that takes care of the backend, what about the rest you ask? Well the single biggest change we’re going to be making is moving to .Net Core. Even though you could argue that .net core and .net standard are still in their infancy the performance improvements alone are enough encouragement for us to move and not only that the cross-platform support is also a plus for our development team.
When are we going to do it?
Work has already began on the basic CMAP V3 framework and already we’re seeing benefits from the new version of .net. We’re not just porting the code over to the new version and leaving it at that either, we have some super new things that we want to add into CMAP, we’ll be writing about some of these in the coming months.
You can keep up with our progress by following the Features & Updates area of our blog.
This post originally appeared on medium.com