(updated ) ~7 min (1376 words)

Are Micro Applications a thing?

Micro App segmentation of a mobile app mockup

You may have heard the term 'Micro Service'.
Shortly summarized it coins for a very small (as in features) application often providing an API that can be used by another app or service.
So, what about when you add a simple frontend to the pile?

The term Micro Application (Micro App)

Looking up the term Micro App at Wikipedia states a very light and partly narrowed explanation. To the author, turns out, it was mostly related to small mobile apps with very specific requirements.

Other sources tend to define it more closely related to Micro Services. I tend to agree here and like to lay out some key features about what would qualify a Micro Application or Micro App:

Highly focused on performing one task? Sounds familiar you might say? And you're absolutely right!

This is one of the key principles of the Unix Philosophy: Make each program do one thing well.

One thing regarding web applications that seemed open for discussion:

Should a Micro App include a backend like API as well? Or should it just use an existing API and we solely rely on having a frontend to meet the terms?

My first thought was to handle this point flexibly. On second thought and because there's another term (Micro Frontend) describing an approach where you build a micro frontend for some backend service.
Well, our app would be a Micro Frontend then.

In conclusion, a Micro App really should include some simple backend (i.e. implementing a service orchestrator) and frontend to differentiate between a Micro Service and a Micro Frontend.

Therefore, as the last point to add to the above list, I would recommend: Provides a backend used by the frontend.

Micro Application feature breakdown

Most of the Micro App features are the same as for Micro Services. Outlined in the section before, here are the details. The following graphic roughly outlines the key differences between a monolithic and a micro approach to developing applications. The comparison concentrates on having a frontend and backend as the main parts of each application, albeit these are not mutually exclusive.

micro app vs monolithic architecture

Do one thing and do it well

Technically, at least for a web service, we're doing two things here.

First, we have some kind of backend. And second, some kind of frontend.

In contrast to a Micro Service or a Micro Frontend, though, these two are supposed to be closely coupled. Following this route, we end up having a fully functional app with a UI. Importantly, only implementing one or a very basic set of features for a highly narrowed purpose.

This could be i.e. uploading an image via a web application.

Independently usable

Here, we're aiming for having an app that doesn't need another application to function.

Keeping the uploading example from above, the app can be used for the single purpose of uploading an image to some server. Most likely as part of a set of apps where another app could take care of OCRing (OCR as in Optical Character Recognition) the image.

Easily replaceable

Since, with our Micro App, we only implemented the feature of uploading an image we can easily replace this app by using another frontend framework. Maybe svelte instead of react 😁. This rewrite might only be a few hours of work then. Especially if you created detailed end-to-end tests beforehand. Additionally, it also allows testing (i.e. for performance) different implementations this way.

Easy to be integrated

Ok, this point is a bit more of a stretch. And IMHO a bit more of a loose feature.

That being said, a Micro App should allow for integration with a Single Sign-On (SSO). As well as the connection to other features creating a feature-rich application composed out of multiple Micro Applications. Like combining the abovementioned uploading, OCRing and additionally viewing and editing the OCR results. Each via separate Micro Apps.

Provides a User Interface

As described before, the app should provide an interface for the user to utilize the app.

Provides a backend

Last but not least, we need some backend functionality so the user actions lead to a result. This is mainly providing the actual business case logic.

Implementation Considerations

Basically, we have two (well, to keep it easy) options when creating an application:

Either we implement a Monolith or a bunch of smaller applications. Although, there's always something in between and there's good reasoning for most of these solutions depending on the requirements.

While you would implement a Monolith as an application orchestrated by different modules, the Micro App approach can be used to implement each module as a separate application. With the Monolith, each module handles a specific feature or a small bunch of related features. With a Micro App, each program would handle such a feature or small set of features. Obviously, when using the monolithic approach you don't have to set up a new application (including boilerplate code) each time. Also, you can reuse existing code without having to include and take care of shared dependencies. At least regarding the code, you wrote for your business logic.

On the other hand, when having Micro Apps you can (best case) just create a new greenfield application implementing a new (or old) feature without having to rely on preexisting code. Therefore, with the Micro App, you can try new tech very easily. Especially for frontend solutions where (at least in the JavaScript ecosystem) frameworks come and go very fast, this can be a good way to stay on top of the trends.

Advantages of using the Micro App concept

Disadvantages of using the Micro App concept


If you're a friend of Micro Services you probably already thought about an all micro approach to building apps. The Micro App approach has more or less the same (dis)advantages as the Micro Services. So, for bigger modularizable apps and teams it might be worth a try.

Although, if you're not careful, you might be about creating another Monolith... And here, ladies and gentlemen, we went full circle!

Last but not least: When creating an application, in my opinion, it's always good to keep in mind the Unix philosophy of making the app (or module or component) just do one thing right.

Article Image Attribution: Based on Calendar vector created by freepik -