A microapp is no different from regular apps except that it is more focused on what it does. It generally does one thing very well - following the KISS and UNIX philosophy of DOTADIW ("Do One Thing And Do It Well."). Micro apps drastically reduce app complexity by breaking down a complex task into simplified idiomatic workflows, supporting a single step in a user's workflow. As a result, app fatigue is less prominent, as there is reduced cognitive load for the user.
Micro apps empower the modern workforce, providing a platform that enriches the employee experience and bolster employees’ productivity. They are fundamentally changing how workers interact with digital systems. However, there is confusion about what they are, where they come from, and how they work and communicate. This post will provide a deep dive into their inner workings and benefits, providing you with the information on integrating them into your systems. We'll cover the following RESTful API topics:
Benefits for Developers
Bring Your Device (BYOD)
Technical Challenges
Microservices vs. Monoliths
Micro apps and Microservices similarities
Micro apps and RESTful APIs
Even though you may have only heard of micro-apps recently, we have been using micro apps for some time, i.e., the flight search box or weather window in Google, calendar alerts on desktop, WeChat, and many more. Google started the vogue and now uses AI processes to deliver interactive cards in response to specific search queries. A mobile search for "weather" provides the micro app presented through a card in a web browser, as seen below.
In general, writing and deploying an application requires a ton of tedious boilerplate code and actions such as authentication, metadata, logging, monitoring, infrastructure, UI work, and testing - violating the DRY principle over and over again. However, with a microapp architecture, it just has to be done once. By Standardizing the application interface, the user interacts with application functionality, which runs inside the parent application container. A user can then receive notifications, respond to messages, and handle workflow steps at will without realizing there is an abstraction in place. The application container has all of the prerequisite plumbing done; it is then possible to add new micro apps, inserting them within the container utilizing this homogenous setup, speeding up the release cycle in the process. Moreover, this approach allows developers to do incremental rollouts, deploying bite-size features gradually. Micro-apps’ decoupled nature results in virtually no total system failures during a deployment; the rollback process is instant.
Remote working has grown significantly since the onset of COVID-19, and the implementation of BYOD efficiently and securely has become paramount for business survival. BYOD refers to employees utilizing personal devices to connect to their organizational networks and access work-related systems. Provisioning hardware is challenging and costly and not always possible for independent contractors, which is more commonplace in the gig economy. BYOD solves both the provisioning and convenience issues, leading to a record number of employees relying on personal devices for business functions.
However, the problem remains, how to do this efficiently and securely? Micro apps solve this issue by providing a layer of abstraction; the app does one thing very well. Meaning has a finite amount of edge cases without too much cognitive load, meaning it is easy to secure. And from an employee’s point of view, they don't need to navigate a monolithic behemoth, getting lost in the maze of functions. It is intuitive.
The flexibility provided by micro apps results in multiple wins for an organization:
In the past, companies have focused on developing applications that offer a wide range of capabilities; they aimed to cast the biggest net possible to catch a broad audience. Unfortunately, this led to:
Furthermore, resulting in colossal memory footprints and adversely affecting the host devices’ battery and performance. Fortunately, the simplicity of micro-apps has mitigated this. In general, it is much easier to monitor, tune, and update on the fly to obtain optimal performance.
So what is a microservice exactly? According to Martin Fowler, "the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies."
Microservices are essentially the opposite of monoliths, which operate as a single, autonomous unit. Every change to a monolith requires building and deploying the whole unit each time. Builds and rollbacks take a substantial amount of time.
A microservice is a small independent unit that does one thing well. Independent services communicate with each other and work in unison to compose a more extensive emergent system. A monolith is one massive behemoth that does everything. Smaller parts can’t distinguish it. Think of how an oil tanker navigates vs. a swarm of small speed boats working in unison.
This concept has several benefits compared to monolithic architecture - easier to test, maintain, and deploy each microservice separately, leading to more regular and smooth releases.
Decoupled nature ensures fault tolerance. When an independent service fails, only that service needs to be fixed and redeployed without significant disruptions to the entire application.
Microservices refer to back-end services. Generally, a front-end application communicates with each microservice directly or via proxy API (gateway). However, front-end applications inherit many of a monolith's characteristics and have become increasingly massive and complicated. One could argue that NPM registries cater for the publication of custom independent modules. But it is still not possible to deploy a single module at a time; the whole thing requires redeployment -this is where micro apps emerge. They utilize the microservices approach and apply it to a front-end application context. The front-end monolith splits into many different apps, running in a separate process and communicating via RESTful APIs; the swarm composes a more extensive emergent system.
In contrast to microservices, micro apps contain User Interfaces, and an external user can interact and achieve a task by using them. A microapp may utilize multiple microservices under the hood operating in unison to perform this task - it is abstracted from the user. Generally, a single microservice does not mean anything to an external user. They cannot use it or interact with it.
RESTful APIs are the glue that holds micro apps together. How can a swarm of services operate if they cannot communicate? However, manually coding RESTful APIs is incredibly arduous and resource-intensive - wasting developers' time on a task in pointless in the age of automation; their time and attention span are precious. You can bypass this development time with a modern service like DreamFactory. DreamFactory includes an automatic API generation feature that helps convert any database into REST API in just a few minutes. DreamFactory also allows you to instantly transform a SOAP Web Service into REST API – which applies REST endpoints to your SOAP APIs, making them easier to utilize.