Independently together:  better developer experience & App performance

Over the last decade, products have moved to web-based applications, typically with the help of strong JavaScript libraries. Bigger, single-page applications were born, coupled with product teams and their road maps. But this marriage added additional complexities to how we build – and how we deploy. We’re moving into a new era – one in which we change the how of building to ease these development and frontend architecture struggles.

Enter micro-applications: single-page creations that create independent applications that can be managed separately, built separately, and deployed separately – without blocking each other: They essentially move together, independently.

While developing web applications,  we have some common asks! There are lots of different requests coming from each team for their application and product & software development lifecycle. We can categorise those requests into a few groups.

I want to deploy anytime I need! I built my new feature or fixed a bug for my page, did my tests and validated it. Now I want to deploy it to production. But wait… I need to wait!

I want to have a faster pipeline. Let's talk about the pipelines. They were fast in the past, but as my app grew and got more complex, now my pipelines take hours!

I want my application loads faster. My application has lots of files and resources. I use service workers to precache. I use best practices and lots of complex tooling and build steps, but it takes time to load, and I cannot get an instant load time!

I want to have a faster local environment. I do not want to even talk about my local environment. Starting up the local gives me enough time to brew my coffee!

Monorepo: That's how we like to manage our code
Over the years, for developing applications, we got a habit of using monorepos. Since teams see lots of benefits to using them, for most organisations, it became a de facto.

Spa: We like javascript, and who wants A full page refresh?
JavaScript conquered our web application development. We like to build single-page applications to prevent full-page reloads since we just need to change a part of the page for each navigation, right?

SPoF: Multiple different aspects can take the entire app down as a single point of failure.
All these singularities tend to become a single point of failure for our application. A small JS error in the page can block the whole navigation, or if the shell is broken, you cannot even load the application.

Multiple teams working on the same app add additional complexity to the tech stack. Not to mention the tooling complexity to manage all teams and all different features, needs and expectations

Every single thing becomes dependent on each other. When we add all the above, everything becomes dependent on each other. You need to plan every move carefully to avoid breaking things.

Multiple alignments, complex tooling, longer pipelines, slow releases, different roadmaps, lots of blockers… This is a lot, usually a lot more pressure on our day-to-day work than we need.

Everything is in the same box. Let’s check what we have in this box very high level and how we can make it more manageable.