Author: Kiril Kalchev

We live in the exciting times of microservices and single page apps, cloud solutions and performant concurrent engines, agile programming and continuous delivery frameworks that spit out green glowing charts for every successful release. And yet, in most organisations there is a dark, shameful corner somewhere on a server, hosting a legacy part of the system that is still used for those 3 things that the company cannot survive without. In our case, that legacy part is called WHMCS. This is the story of how we migrated this monolithic beast onto our Kubernetes clusters and the lessons we learned from it.

The HTML spec has always been incomplete and leaves to the browsers to decide a lot of critical details on how particular elements should be rendered or function. In the not-so-distant past, this experimental nature led to a lot of developers having headaches and panic attacks when they needed to provide a similar user experience on different browsers. It also left a blazing trail of hacky code snippets, sprinkled with comments like “No idea why, but IE needs this”. But then the main browsers settled their wars, W3C improved the specs and bit by bit the state of web UX development became less of a nightmare. It’s 2020 now and surely browsers are working consistently with the main HTML elements, right?

Angular provides several well-documented patterns for communication between components. But what can you do on the off-chance that none of those match your particular case? Time to get creative and reach for one of those tempting solutions with DANGER on the label.