Out With The Old And In With The Angular
Handling migration from one UI framework to another.
A few months ago, Rowe IT were asked to further develop an application that was originally created as a prototype. This prototype did what it was designed to do, show proof of concept, but moving forward we had to think long and hard about the technologies it was using and if they would be suitable down the line. It wasn’t long before we were faced with a big decision. Support for the frontend framework was about to be dropped and there was no straightforward migration process to its next version.
We were faced with a choice, rewrite large parts of the frontend to migrate to the latest version, or jump ship and go for a new framework altogether. As you may have guessed, we went for the latter.
Making The Decision
The prototype was running on an old version of Vaadin, a Java based framework that allows you to write all your UI code in, well Java. But as support was about to be dropped, we had to decide whether to migrate the current code base to the latest Vaadin version or take this opportunity to move to a new framework, in this case that meant Angular, something we were already well-versed in.
The decision was not taken lightly, moving to a new framework and rewriting the whole user interface takes time, we had to be sure it was worth it.
To help us make a more informed choice we created a few lightweight prototypes to get a feel for the different candidate technologies. One in the old version of Vaadin (for a fair comparison), one in the shiny new version and the final one in latest version of Angular.
These prototypes didn’t provide much in terms of functionality, they had a simple login page, a navigation menu and few mocked-up pages, but that was enough to show off the built-in components and style themes that were on offer. Creating the prototypes also gave us more of an insight into how the frameworks differed in terms of development.
Armed with this newfound knowledge we were ready to decide, and we chose Angular.
Why Angular?
Angular had everything we needed. Its components were just as up to date as Vaadin’s new version, and its way of handling routing was even easier and more intuitive than Vaadin’s.
It was also a more natural fit for a traditional client-server architecture with communication over a REST API, which was something we’d been asked to produce.
We are big fans of Angular, not least because of its component-based architecture being a great aid to development. Each component acts as a small piece of the user interface, which encapsulates functionality so it can be reused throughout the application. It also makes it easier to unit test and maintain as we can swap out new components for old as development progressed in an Agile manor.
Of course, the benefits came with a high price, rewrite the entire user interface but on review, we decided it was well worth it.
The Move
To make the move to Angular we broke down the prototype’s functionality into smaller features and reimplemented them piece by piece. While most of the application structure had to be created from scratch, there were a few similarities that we were able to ‘reuse’ and rewrite into Typecsript.
A lot of this ‘reusable’ code was around the classes that were used to control the display of some D3 visualizations, that were themselves written in Javascript. Changing their controller classes over to Typescript actually made the code more cohesive and with the aid of a library, the D3 visualizations were added directly to the angular components thanks to Typescript being a superset of Javascript.
While recreating the application, we needed to refer to the original version to make sure each feature was being brought across with no loss of functionality. To do this we developed the new UI alongside the old one, so with the click of a button we were able to switch between the two interfaces, both utilizing the same server. We also kept a version of the application running in a virtual machine using AWS (Amazon Web Services). This was updated at the end of each sprint and acted as a handy reference point in order to check that our current work hadn’t changed a previously converted feature.
Once we reached parity with the old interface it was finally removed. What could have been a slightly nerve-wracking experience, was actually fairly easy. Having the old version up and running and using that to test against during development had given us the confidence to know that what we had produced met the requirements, and more.
Lessons Learned
Dividing up the features into small pieces proved essential when planning sprints, but initially there were unknowns which made adding time estimates difficult. We found adding in investigation tasks into our planning really helped keep the sprints on track.
Developing alongside the existing UI is a must, being able to quickly check back to test out functionality really helped speed up the development process. We also found that having the previous version of the sprint up and running at all times allowed us to quickly identify and fix any inconsistencies that were being introduced as part of the current work.
Converting the whole UI was no small feat. It took a lot of work and testing to make sure all the features came across correctly.
It’s not something to be underestimated!
However, if you do your research and you know its right for your project, its’s well worth it. Plus, it feels great to finally remove that old interface!
By Deanna Davenport
