The state of the internet in 2018, as with most things in life, is heavy on presentation. With the proliferation of web builders available around the internet, it can sometimes feel that web developers has seemingly taken a major backseat compared to web designers, and in a majority of cases, it’s probably true but if you’re running an international music streaming service with 157 million unique users, of which 86 million were active subscribers, i.e. Spotify, then it stands to reason that you would probably need to build your web app from the ground up as your needs are very much quite unlike most businesses.
Before we dive into the nuts and bolts, I would like to explain first about what a web app means. I’m guessing you’re already familiar with what a website is. Well, a web app is at its most basic definition a dynamic website; in that what it contains differ from user to user and from interaction with said user. The easiest example is a mail client you access from a website. You and your friend would be visiting the same domain, i.e. mail.google.com but once the sign-in process is completed, what each of you find would most likely be different. Now, with the state of the internet as it is today, a purely static website, one that is completely devoid of interaction and functionality, is pretty much extinct but take a look at this page for the firm of the notable Japanese architect, Kengo Kuma. There is still a search box and other small functionalities built into it, but for the most part, the page itself is static.
At this point, I’m sure you can already imagine the difference in complexity when it comes to dealing with a website and a web app, or given the dearth of a purely static website, between a simple and a complex web app. The complexities of a web app could range from simple ones like the Kengo Kuma example above or something as complex like Amazon or YouTube. For web apps such as those, front end development has typically grown to eclipse the back end and involves quite a number of considerations, including but not limited to:
- Front end dependencies management such as JS and CSS
- The interaction between HTML fragments
- Measurement of users’ activities
- Ensuring the same experience and interactivity across different devices e.g. web browsers, mobile devices, smart TVs, set-top boxes etc
It’s that final point that gives web developers a headache. Ensuring that for example, Spotify works consistently across a different number of devices is one thing, but do you know that you can control your devices by using the Spotify mobile app from your phone as a remote? Oh, and if you have Alexa, you can also control Spotify using only your voice. If that doesn’t sound complicated enough, the rate at which software development moves (ask yourself how many times Windows 10 get a major update in the past 12 months, and that’s just for a single platform) means that once a web developer is done with ensuring compatibility with an update, it doesn’t take long before the next one rolls out and they’re back to crunching codes once again and not to mention that even one simple change to your web app could leave one platform unscathed while completely breaking another.
In the past, a one-size fits all approach, the monolithic architecture, works just fine but as the front end grew bigger and bigger and more functionality is added, this approach would eventually grow unwieldy so for web developers that deals with a relatively large front end app, there already is a way of breaking that approach into smaller modules that still retains connectivity with each other but is able to operate independently for the most part. While there is no properly defined term for this method, it is commonly called micro frontends.
Think of how the government works. You’ve got one Minister for Health, one for Finance, and one for Foreign Affairs. There are liaisons for each that handles business between ministries but they work independent of each other for the most part while being overseen by the Prime Minister. That’s micro frontends in a nutshell. Without getting bogged down on the technical details, working with this approach brings with it a number of benefits;
- Quick development and deployment. A change in one department would only need an okay from the department head and the general manager, no need to ask for permission from other departments.
- Isolated and independent development. By the same token, a change in one department wouldn’t affect other departments as ideally; their jurisdiction would be theirs and theirs only.
- Easier management. This modular approach encourages proper specializations as a department doesn’t have to deal with things they aren’t properly suited for.
Of course, as with everything in life, this approach is quid pro quo, you’re going to have to exchange something for another or put in more resources to make up for what you lost.
- Potentially inconsistent experience. Ever been disappointed with one facet of the government but delighted when dealing with another? It’s completely up to the general manager to ensure consistency and a united language, so to speak, which can be a rather complicated task for one person.
- Redundancy as a waste of resource. As each department works with their own resources, in this case usually libraries, there will be some cases where two different departments use double of the same resource instead of simply sharing one.
As you can see, while this modular approach brings in some notable benefits, it’s not an approach that works for everyone. The government analogy for example works because it handles the business of running an entire nation but what if we’re talking about a student union? Given the size and the scope, a monolithic approach could probably work, or at least, the division of specialization wouldn’t be as fragmented as a national government. The same thing with web apps, I’ve emphasized before that the micro frontend approach grew out of necessity from increasingly large web apps, but if you see no need to adopt this approach, even for the foreseeable future, then you should trust your own judgment. It is up to web developers to determine which approach is better suited for their needs and when to switch when circumstances demand it.