Reason for the change and a bit of history
ASP.NET has long been a cornerstone in web application development, but modern demands require a smoother, more interactive user experience. To this end, many interactions are shifted to the user’s browser, reducing traffic and latencies.
Working primarily in markets where bandwidth is often insufficient and unstable, the server-side rendering approach has been limiting on several occasions. It has disappointed the end user and forced us to move parts of the system to the front end, creating a hybrid that is not always manageable.
Given the necessity to offer a more interactive experience and limit round trips to the backend, choosing a more structured frontend framework capable of organizing JavaScript-based projects seemed like the winning solution.
We completely separated the backend from the frontend, which gave us the ability to evolve and optimize the backend independently of the frontend, which is not possible with ASP.NET technology.
Preparatory steps
The first step was to choose the front-end framework to adopt. The choice was not easy, having so many frameworks available, but our guiding principles were:
- A framework that could work even on older or less powerful devices (feature phones, Android 4, etc.)
- For the type of user that uses our portals, the approach of ‘either you upgrade your smartphone, or you can no longer access the site’ was not applicable, so being able to support as many devices as possible was a fundamental characteristic.
- Longevity of the framework
- A very important point to avoid is the risk of being left stranded after a few months because the project on GitHub was closed.
- Company knowledge
- Finding the right balance between modernity and the company’s technical expertise facilitates the adoption of new company tools.
- A structured framework
- Starting on the right foot with a new ‘revolutionary’ project is very important, especially if the framework enables it out of the box.
POC and field testing
Phase 1
The first POC was to understand the types of devices used by the end users. For this purpose, we used tools like Dynatrace or Google Analytics to extract technical data on the usage of various device models.
Once the data was extracted and considering the constraints listed above, the choice of framework was narrowed down to three possible options.
- Angular, developed by Google
- React, developed by Facebook
- Vuejs, developed by Evan You and the community
- Vanilla javascript, all home made
After a brief consultation, the last option was discarded, not due to the lack of technical capabilities but because our business is not focused on selling JavaScript frameworks. Instead, our focus is on solving problems for clients in a non-technical field. It did not seem convenient to write the entire front-end stack from scratch but rather to rely on those who have built businesses with these products.
Phase 2
At this point, we created many small projects to determine which framework best suited our needs. We also considered browser statistics. The task was to find the common denominator between the browser versions supported by ASP.NET, the current product, and the various frameworks.
From this premise, we embarked on several weeks of work to test the frameworks on various browser versions using emulators and physical devices to determine the compatibility matrix.
Conclusion
All things considered, the winner was Angular. It offers compatibility with a wide variety of browsers and devices which, as mentioned above, is particularly important to our product. Moreover, it fits very well into our company since we already used it for some small internal projects and we are already familiar with its basic concepts.
Business involvement
Another significant activity that contributed to the entire project’s success was involving the business side. After completing the technical activities, the POC continued with small demos for the company board and the various product owners of the different product modules. These demos showed the advantages of adopting this new technology, how to gradually migrate the entire product (which, I should remind you, is 25 years old and contains 3.5 million lines of code, thus having a certain level of complexity and criticality), and how to migrate it without causing disruptions to the business.
Involving all parts of the company allowed us to make the project a shared asset and demonstrate the competitive advantages over our competitors, preventing it from being dismissed as just another ‘technical wish list’ project.
Going forward
In the upcoming articles, we will continue the journey by describing how we created the roadmap and the deployment methods in production.