The Technical History of the CartonCloud Application

CartonCloud was started in 2012 and by many metrics would no longer be considered a start-up, however inside, despite its 6 years old, it certainly has the feeling of an energetic startup due to the rapid evolution of the technology we’re using.

Taking you back to where it began, the project was originally a system built to manage a small transport and warehousing business in Sydney, or which I was a half-owner. (The full history of the product is available here).

Initially, when the project kicked off, it was myself and one other developer, plus my business partner and great friend, Nic Comrie acting as Product Manager. At that time neither of us had ever heard of a Product Manager (let alone knowing what they do), as far as we were concerned Nic was just the guy who had the ideas on how the system should work, and the two of us were the guys coding those ideas into an application.

I was 24 at the time. I’d completed a degree in Science and Technology, majoring in electronics and instrumentation (similar in content to an electronic engineering degree but without any prestige). I’d then worked for a little over 2 years inside a small business in Sydney, Halytech writing C code for an embedded device which ran on a 16-bit MSP430 processor. The work there was fun and really challenging - my first project was to build a web-server capable of handling 5 concurrent connections that ran off 2kB of RAM (yes, 2,000 bytes). On the side I ran a business that sold party products online, the website was written in PHP using OsCommerce as the back-end. In 2010 when I first got introduced to coding in PHP, OsCommerce was already an ancient platform. It was pretty much written by a single guy, came out in the early 2000s, got widespread adoption, but lacked any kind of structure (no MVC, no real objects). So, that was my only exposure to PHP.

When we kicked off building the “Roving Management System”, I did research for a couple of days around the various PHP frameworks that were popular at the time (mid-2012), and settled on CakePHP due to it having seemingly the most extensive documentation, active development, and very strict naming convention which suited me because I had absolutely no idea how to name things.

The next 3 years (2012-2015) was largely the two of us coding away every day, and at night, and on the weekends - building out the system feature-by-feature that our logistics company could use. Surprisingly, given that neither of us had any prior experience in building a system from scratch (or even MVC), we managed to build an application which suited our business needs perfectly. A big application written entirely inside the CakePHP 2 framework with no modification to the framework itself.

For those who have used CakePHP 2, you’ll probably have very strong (most likely negative) feelings around the ORM, and the way in which it returns records from the database as arrays and not objects. I’ll admit, when I started this project I didn’t understand exactly how that differed from Symfony with the Doctrine ORM returning objects, however in late 2015 when a new team member joined us - he was disheartened to find such heavy use of arrays, the limitations it would impose, and the overhead associated with requesting the same data multiple times from the database to perform an action.

For this reason, he designed and built a custom Repository / Entity based ORM over the top of Cakes own ORM. This way, we could get records out of the database as Objects, and perform actions directly upon them, rather than needing to pass arrays everywhere. This was a smart choice, as most code written from this point onward would be written using the Entity/Repository method which made code structure far nicer, and allowed us to begin grouping logic by services.

The application carried on in this way until late 2017 when our (now) CTO, Kenji Kimura proposed a very radical shift. As we were beginning to see some architectural constrains of the design I had built, he proposed replacing some of the core functionality with Java (Spring Boot 2) micro-services.

This would allow us to begin shifting our application, in pieces, from the single monolithic PHP application into an entirely new micro services architecture. Allowing us to simultaneously address both architectural issues, as well as ensuring our platform is utilising leading edge technology. On the front end, rather than using embedded php/javascript/html view pages, React was selected as a layer sitting on top of our API - providing even greater segregation between components and allowing us to build new screens directly on top of the Java micro-services.

We’re in the middle of this transition at present, with our new Transport Charging micro-service due to come online within the next 2 months. This has allowed us enormous flexibility in the way in which we can calculate rates within CartonCloud, while greatly simplifying the underlying logic used to calculate the charges.

Over the next 12 months, we expect to quadruple the Java team, allowing us to build more services in parallel, greatly improving the flexibility of the product as we migrate components one-by-one. In addition we’re looking for multiple front end developers, iOS and Android Devs, and, of course, talented PHP developers (especially those who are interested in expanding their skills into React/Java).

If you’re interested in joining our team and being a part of this exciting journey, please reach out to us by sending your CV and Cover Letter to: jobs@cartoncloud.com.au