Micro Apps in Flutter, does it make sense?
--
With the continuous growth of our digital applications, we question whether it would be possible to modularize their functionalities. This article will tell you how Bancolombia A La Mano was built for us, an application with millions of users and made by a development team in record time. How do we manage to grow the solution in parallel? Can we create modules in Flutter that are reusable in our other applications? Is it the end of monoliths in Flutter?
Before building our application, we implemented a design system library in Flutter (you can access this link where we explain how to implement a design system based on the atomic design in Flutter). By having a set of more than 230 reusable digital artifacts, we accelerate the construction of experiences by 120%.
But we still had a concern: given the growth strategy of micro frontends and keeping in mind that we have several functionalities repeated in our applications, will it be possible to build micro apps that embed complete experiences?
In this case, I will share with you some strategies that we analyzed to implement, no longer reusable elements, but complete reusable experiences.
Widgets
They are not our beloved Flutter graphic elements; in the banking world, widgets are the set of screens and functionalities associated with a unique experience, such as sending money, paying bills, consulting products, etc. (I leave you some links: 1, 2).
So, brought into the Flutter world, we created a set of widgets for each functionality defined by the business. However, these elements must be parameterizable and adaptable to the needs of each of our channels.
How to build a widget in Flutter?
In Flutter, there is the possibility to create packages that can be reused in new projects using the following command:
flutter create --template=package nameTherefore, they edited to create a package for each of the functionalities. Being solutions centralized in the business, it is very convenient to build them using clean architecture (I leave you a link with a code example).
This strategy made it possible to have a team working on the Money Transfer Widget and another on the Bill Payment Widget, and neither emerged from the construction of the other. Each element has its unit tests and integration tests against pre-production environments.
When a team wants to use an already built widget, they can choose to point directly to the repository where it is published and a specific version as follows:
Each team that uses the widgets can parameterize all the texts (titles, subtitles, paragraphs, etc.). These elements contain all the scenarios for the experience; each widget user enables only the screens he needs. To point to your backend using clean architecture, you only need to build the infrastructure layer, as the device has both the domain layer and the UI defined. In scenarios where all banks point to the same backend, the widget will come entirely out of the box, including its infrastructure capabilities.
We have over 41 fully parameterizable widgets built into Flutter at this writing. An average developer takes two weeks to make a traversal Widget, including its documentation, unit, and integration tests; however, applications that use widgets have already benefited from value delivery times.
For the Bancolombia A La Mano application, we implemented 21 Widgets. One per day was integrated, making the entire experience less than a month to build.
And can I turn these widgets into a micro app?
Of course, yes; however, I consider that it is easier for you to integrate your project into the library format. However, suppose at some point you need some capability of the application to evolve without relying on its container. In that case, you might consider deploying it as a micro-app.
WebViews
There may be scenarios where it is required to integrate web elements into your mobile solutions; you can use the plugin created by the Google team itself, which is the following: WebView flutter. An article explains the benefits of this tool; I recommend you read it (link).
As you can see, the WebViews look as if they are part of the application and do not generate a popup; this makes it look as if the site is part of the application. So should we build applications solely from WebViews?
The truth would not result in something correct since using WebView has performance implications. Its objective is to reuse some web elements, not become our primary tool. They should also be those components that do not require native capabilities.
A backend manages frontend elements.
There are many methodologies to implement this in Flutter. Still, like WebViews, they should not be seen as a strategy to build all the screens and components of your digital solution, but rather those that you consider may vary over time and even by the client ( I mean, with this, you could customize for each user of the app what is shown to the individual customer in a particular experience).
For example, the json_dynamic_wydget plugin allows, before the arrival of a JSON, to draw different elements in the application so that the backend, after a logical process, can decide what the frontend renders.
From the point of view of the code, the only thing that would be done is to enter the raw JSON to the DynamicWidgetBuilder, and this would return the screens configured in the JSON.
DynamicWidgetBuilder.build(snapshot.data ,
context, new DefaultClickListener()) as Widget)
As we can see, this would be the result; we can see it is a horizontal ListView with three images and text as the response from the backend arrives.
The Flutter Widget provides a strategy similar to this from the HTML plugin, where, given an HTML, it transpires it into a Widget.
Care must be taken because by delegating this type of signature to the backend, the complexity of the solution increases. We must keep in mind that implementing this strategy takes additional time since it must wait for the response and the interpretation of JSON to Widget.
Conclusion
We can use these strategies to modularize our applications in Flutter. However, you must be very careful in what scenario you will use it. Widgets can be for those elements that you want to have excellent performance and be part of your immediate solution. WebViews and elements managed by the backend can be used only in particular scenarios where they are helpful in our solutions.
When asked: is this the end of monoliths? We can say that the container is still a monolith, but its construction has been segmented into modules and specialist teams on each front.
If you liked the article, please press the applause icon 👏 many times, as this will help us make more articles like this. If you want to know more details about how to implement any of the strategies exposed here, leave us a comment where you tell us the element of interest, and we will make an article going into more detail.
