1. It Takes Patience and Coordination to Change a Number of Major Things at Once

The public Elisa corporate customer site and the online store were built with AngularJS several years ago. When development took a course toward self service at OmaElisa for companies, we began to build it with React, as it had become the go-to tool.

Unbeknownst to us, we had started to put ourselves in a bit of a pickle. As the self service side of the site needed a lot of development, React code started to stack up, and there was a lot of pertinent data in the React library. The transition to React was inevitable, so we decided to implement it in phases.

At the same time the main site was still wholly Angular-based. In addition to that, the runtime environment was updated to Kubernetes simultaneously with the backend being revised.

All of this led to glitches in navigation and other strange symptoms, which weren’t necessarily detrimental to the user experience, but they put us developers in a really difficult spot.

2. Good User Experience Takes Wits to Build

Switching to React was quite an organic process, as different teams at Elisa had implemented it in their work without each others’ knowledge. Gradually React became the preferred solution for all teams. This was also due to AngularJS libraries ending their support. The teams involved were all business-led, but everyone worked around the same code base.

A design process where the functionality and the visual design of components was planned out by several designers in a centralised manner, and with design components converted to React components, came with several benefits. The look and feel of the components is consistent, it brings cohesion to the process, and in addition, the possibility to use preset components.

For users, this shows as a more pleasant experience with an astoundingly fast site loading time. React enables server-side rendering with dynamic components updated in advance, and even data-heavy elements are loaded swiftly, with a minimal waiting time.

3. Big Bang May Sound Scary, but it May Just Be Worth It

One of the main lessons we learned during the site overhaul was that maintaining two separate UI frameworks on a same site leads to complications and user experiences that are sub-optimal, to put it politely.

In hindsight, we would have made everything easier for ourselves if we had just let the backend be and developed the front first, instead of having a constantly moving target.

As it is possible to run the old code in production and a new one internally with beta users testing the site at the same time, you should definitely consider that. When the team is confident that the site is functional, the switch to a wholly new site can then be done – a big bang.

4. Kubernetes Is a Really Nice Thing to Have

Our goal was to run our service both on-premises and in public clouds, so a common denominator was needed. We were looking for a solution to carry out the transition in a smart way and without the need to train the developers a bunch of new skills just for this one thing.

Kubernetes to the rescue! We very quickly realised that Kubernetes is a great tool for mapping out the environment so that it runs both in our own data centre and in a public cloud simultaneously. We no longer live in a world where one would order a server and wait for it to be installed, so these kinds of tools are absolutely necessary for an operation as big as ours.

One of the many upsides of Kubernetes is that it is based on infrastructure as code thinking. Kubernetes enables to define the runtime environment and build it mechanically in such a way that runtime components, web parts, and services are mapped out in the same location, they are easy to manage, and they share version control with the application itself.

As we replaced the backend integration, migrated the database, and transferred the runtime environment from virtual servers to Kubernetes and yet another Kubernetes, we were certain that we had found the right solution.

5. Even When the Solution Is Ideal, Technical Debt Can Remain to Be Paid

API interfaces enable abstract solutions – frontend and backend can be modified independently, and that is definitely a recommended option to use.

That can however lead to overly complicated solutions that have to be fixed further down the line. We learned that the hard way, when React-based user interface was revised at the same time with the backend and the main database.

Coordinating all of the three variables and keeping the site functional in unison introduced us with some surprising problems. It was definitely possible to live with both Angular and React powering the site, but when we started ditching Angular and got to a more pure React environment, the overlap began to show in some peculiar ways, as was mentioned before.

Fortunately, there was a valuable lesson in here also. Selecting the right sub-libraries (and dismissing the wrong ones), finding the fastest ways to run unit testing, and overall taking the long view to the revision process are priceless procedures. When they are left aside, you will come upon them later on anyway, and precious development time and resources are wasted.

In the end, the business goals were realised, and that is of course the most important thing. The process took a few years, but now the whole site is running in a single UI framework, and due to server-side rendering, the response times have become lightning-fast, which also boosts our SEO ranking considerably.

Would we do it in a similar manner again? Hell no! But did we learn a lot in the process? Definitely.