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.
- Highly focused on performing one task
- Independently usable application
- Easily replaceable by another implementation
- Can easily be integrated into a collection of applications or a website
- Provides a User Interface (frontend)
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.
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.
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.
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.
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.
Advantages of using the Micro App concept
- Fast and easy to create
- A single or small set of features to be handled in each app reduces each app's complexity
- When using a preexisting backend the frontend can be easily replaced
- Even when bundling frontend and backend new frameworks can be tested
- The effort to build, deploy and test a single Micro App should be way less than within a monolithic app
- Making and deploying changes is quite fast (development speed)
- You can split apps and responsibilities between (smaller) teams
- Apps can be glued together by another Micro App frontend
- Better scalability
- Single team responsibility
- Easier and faster testing
- smaller codebase per app
Disadvantages of using the Micro App concept
- More different repositories and applications to maintain
- In many cases more boilerplate code
- When having many common dependencies between features the dependencies have to be shared which further increases the number of packages to maintain
- The effort for less complex applications or small teams can be quite high
- Without a set of well maintained Continuous Deployment services you will run into a lot of issues and waste time
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 - www.freepik.com