Accelerated overhaul

Very early in the definition of our product, we decided to support two distinct operating modes (with and without server), and two alternative user interface frameworks. That being said, our original codebase was hardwired for standalone mode (without database server) and for a particular user interface framework. We knew that we would have to make significant changes to it when we would add our server and when we would support a second user interface framework, but we were comfortable pushing this major overhaul to a later date.

Such was our position until Wednesday, when the developer of our primary user interface framework made significant additions to their platform that we could not ignore. Without getting into too many details (which would let the cat out of the bags), these additions made it possible to create a clean abstraction layers that would hide the differences between the two operating modes (with and without server) and let us write a single codebase that could be deployed against the two user interface frameworks we want to support.

Knowing this, we spent the last two days investigating these new technologies and re-designing our architecture accordingly. The good news is that the new architecture will bring many benefits. The bad news is that it requires that we re-write very significant portions of our code. Since our codebase remains relatively small to this day and since we don’t have any customer in production yet, now is the time to bite the bullet and make the necessary course correction.

While we’re still giving ourselves a week to make a final decision, we’re starting to feel pretty good about this new architecture. It will cost us a few weeks of extra work, but it should be worth it in the end. Here are the benefits we’re expecting from it:

• Easier provisioning and billing
• Easier integration with our server
• Larger storage capacity for standalone mode (200MB vs 10MB)
• Better support for a wider range of SQL and NoSQL databases
• Better abstraction for syndicated objects (Contact, Event, Task, etc.)
• Easier support for alternative user interface frameworks
• Support for standard user interface technologies (HTML 5)
• Dramatically faster user interface

Now, because we have to re-write so much code, we’re allowing ourselves to make some improvements at the meta-model level as well. Essentially, the version that we had so far should be considered as a prototype, from which we learned a lot. Today, we’re starting to build the real product. Of course, we’re not really starting from scratch. For example, we’re reusing most of our code server, code loader, and meta-data. But many critical elements of our architecture are being re-designed from the ground up, for the better.

For example, we’ve decided to alter the granularity of our platform. In the first version of our product, we had a very fine grain architecture, whereby objects were the primary components of the platform. In this new version, we’re adopting a medium grain architecture, whereby applications made of multiple objects become the primary components. This is making everything a lot more user-friendly and dramatically easier to maintain.

So far, so good. I’m sure we’ll encounter many issues along the way, but we’re pretty upbeat about the whole thing. Over the week-end, I expect to re-implement our Data CRUD API. And next week we should have first versions of re-factored Object and Record Views.

Wish us luck!