Static Micro Frontends in Unity with Reactor2D 🚀
The Frontends Revolution in Unity
And the time has come when frontends want their independence and fight for modularisation and autonomy they were looking for.
Now Being Serious
While the Micro Frontends technique emerged in 2016 under ThoughtWorks Technology Radar, it has recently begun to gain popularity. Similar to micro services, it is used to separate monolithic applications into completely independent modules in charge of a particular business that accompany a larger business.
An architectural style where independently deliverable frontend applications are composed into a greater whole
- Cam Jackson (Martin Fowler Blog)
Monolithic Application (Monarchy)
A team responsible for a whole.
Micro Frontends Teams
Teams specialised in something particular of the business.
The Revolution!
I found the idea of micro frontends very interesting, especially after reading Micro Frontends, so I wanted to experience the technique but, in a field that the term has not yet been heard, Unity.
I decided to develop an application like Instagram, to practice, experiment and find problems to solve. In this post my intention is to show how I will independently separate parts of an application.
Expected result
Revolution planning
From the beginning I already knew that because of how we developed in Unity (compiled Android & iOS) I was not going to be able to deploy my micro frontends just like it can be done on web apps. But my term to deploy from now on will be “publish a version in the dependency manager” so that the container app can pull it.
My second problem, unlike Web, Unity does not have any framework such as React, Angular or Vue that fulfill the role of a platform where frontends stand over. Then I started to create one, which at the moment I called it Reactor2D, this small system gives my frontends creation, navigation and communication between them without the need to know each other.
The Home Frontend
I started evaluating what basic things Instagram has on it’s Home that I could quickly replicate. I started to generate what Reactor knows as Application (module with an exclusive task). Reactor provides me with a class called ReactorApplication from which my modules can inherit to have their own life cycle, similar to Android or iOS.
Reactor provides me with a quick and easy way to create applications. It will automatically generate the folder structure with the assets and scripts we need. (If you want to know more about Reactor you can go to this link)
After thinking carefully about the responsibilities within Home I ended up making the following separation.
While it seems that TabBarApp and FeedApp are empty, they perform very important tasks in the background. TabBarApp manages the browsers of each Tab (Home & Search). FeedApp is responsible for searching the stories that it will show later in a scroll inside of it and StoryApp shows the information of a particular story, but also knows where to navigate when they click on the user’s profile or if someone likes the picture.
In this example we will put aside the TabBarApp, since it is provided by Reactor, but with FeedApp and StoryApp we could already have two teams working in parallel focused exclusively on what each frontend has to accomplish.
In order to continue with the example I will create an in-app service (services inside the application deployed like backend service), also with Reactor, which will give me the stories of the users in memory. This service will be listening to http: //user-stories.default.
More about In-App Services in this link.
Within the domain of my FeedApp I will have a class in charge of searching the feed of a particular user and, as I have configured my module, the UserStoriesHost environment variable will be the service url http: //user-stories.default.
This class will return a list of a Feed object.
FeedApp has the responsibility of requesting a user’s feed and preparing the creation of the stories, when this application matures, surely FeedApp will have more responsibilities, such as paging the stories, displaying followers recommendations, etc.
Because we inherit ReactorApplication we can access to InstantiateAsInnerApplication, a method that allows us to create an application in a container that we want and will automatically share the life cycle with FeedApp.
StoryApp to work requires a userId and storyId. With this information it will know how to work.
When StoryApp is instantiated, the WillAppear method will be called, it will extract the userId and storyId from Props and pass it to its presenter who will look for the story data.
Charge! 🏃. I will create the boot script and press Play in the Editor.
I connected two frontends without knowing each other and that each one does a particular task. We could even take StoryApp and place it in another part of the container application and it would work the same way.
The User Page Frontend
The same will happen with the user’s page. If we follow this technique we can divide functionalities.
In this particular case when browsing from StoryApp to UserPageApp I will have to provide a userId, but the interesting thing is that UserPageApp will not use it, because having UserProfileApp and UserStoriesApp as children applications it will delegated the data it received to them so they can work.
UserInfo object has a couple more properties, and among them is the userId. UserPageApp has UserProfileApp and UserStoriesApp registered as inner applicactions.
UserProfileApp will take care of searching for the user’s profile
The same for UserStoriesApp.
Distributing the land
At Etermax, the company where I’m working, we have our own Unity dependency manager, also called UPM (in short time we will be able to use the official Unity Package Manager). Therefore, it gave me the possibility of separating my frontends and services in packages and leaving my container application with the following dependencies.
Each of my frontends are separate, versionable projects and represent a feature, a part of a business.
Demo
Shared Components
There are common cases in which we will want to share components, utilities, images and even other frontends in several of our applications. In this case you can create a package, which can be called Foundation or Shared that is just the basis of our application.
In the Instagram demo I have a dependency called @ etermax / instagram-foundation where are the fonts that my entire application is going to use and also one of the frontends that makes the product special, the StoryApp.
Personal Vision of Micro Frontends
After having developed the demo, I realized:
Advantage
- Teams may not belong to a particular product, but develop independent features. Today I can be doing Instagram Home Screen and when I finish, I can start developing the Twitter UserProfile in other team.
- Reuse of frontends. If the Twitter UserProfile could be applied to Instagram, I could simply use the dependency or, fork the module and add/remove what I need.
- New additions to the teams do not need to know the whole of an application, but only the context of the feature they develop.
- Small modules that can be developed, tested and “deployed” independently.
- Make updates/fixes/changes in a versioned way on the modules.
- Fewer problems when doing merge/rebase.
- Autonomous teams From the idea, the development and the way of delivery.
Disadvantages
- It is a fairly large paradigm shift, especially in the Unity world.
- If a package that works as a Foundation/Shared is not generated, some things may be duplicated.
- Unity does not provide anything about Micro Frontends or navigation or the concept of applications, so you have to develop a system like Reactor or use it.
Summary
Although the technique of micro frontends is not a silver bullet, much less in Unity, I believe that companies will begin to migrate little by little. New teams could be born within companies and could even generate a new business (I imagine Developers selling parts of an application in Unity Asset Store). I will continue developing Reactor2D to see if it has a future as a tool in the Unity world.
If you want to know more about Reactor2D you can read this post or follow me on Twitter or LinkedIn.
Twitter: @martin_g90
LinkedIn: https://www.linkedin.com/in/martin-gonzalez-90
Thanks for reading! Hope you enjoy it! Share it if you want! 😄 🚀
