Reactive core architecture for React-based web and mobile application

Recently when one of our client requested us to develop an exhibition cum e-commerce experience on both mobile and web platforms with a lot of shared functionality. So, since a lot of the functionality was very similar for both the application.

We were looking for a solution where the amount of code can be reduced. While researching the idea we came across this wonderful solution provided by Carolina Angular on a medium called Reactive Core architecture for React Native and React applications which was a really interesting read.

In brief, The architecture allowed both the react and react-native applications to business logic such as share store and actions using a git submodule. In essence, the architecture allowed us to share all the common functionalities/code. Following is the diagram that purely depicts the architecture.

Well in this article, we are not going to talk about the architecture in detail per se. Because it is explained very well in the above article. What we are gonna talk about though is about feasibility, what sort of application this architecture is fit for, and what we learned from our experience with the architecture.

Overview of the Stack

For this purpose the Redux framework, in conjunction with Git submodules, are used to structure a common core codebase. React Native is used for the mobile application and React is used for the web application.

Redux “is a predictable state container for JavaScript apps”, which means the whole state of the application is stored in an object tree. The only way to change the state tree is by emitting what is called in the Redux world as an action, which is an object describing what happened. The other important concept in Redux is called reducers, which are functions that specify how the actions change the state of the app.

Then we have the powerful git submodules tool, which gives you the ability to add a git project inside another git project. The child repository doesn’t know anything about its parent repository, but the parent can access the child and keep track of the version of the child.

React Native is one of the best options to build a mobile app using JavaScript and still have the performance and look and feel of a native app. This is because it uses Webkit’s Javascript VM JavaScriptCore and platform-specific UI components for each platform (Android and iOS).

React is a JavaScript library for building web User Interfaces. It uses a virtual DOM, an abstraction of the HTML DOM. The efficiency of React resides in its ability to only update and re-render what was changed instead of rendering the whole page again.

What's good about the architecture?

This architecture allows structuring a project for both a multi-platform mobile application and a web application, keeping the business logic of the application in a single, self-contained, reusable, and maintainable submodule. I think that's the biggest advantage as it reduces a lot of work.

Nuances of the architecture

After using this architecture we found that there are some nuances and challenges you face as you work on the application.

Non shared actions

As the architecture allows you to share a submodule, there are some actions that are not common between both the application and very application-specific in that case the local reducers and actions have to be maintained. Of course, this only applies if you strictly adhere to the separation of concerns.

Git submodules can be handy, but also can be a nightmare

Submodules effectively separate repositories within the directory tree of their parent repository. The only linkage between the parent and the submodule is the recorded value of the submodule’s checked-out SHA which is stored in the parent’s commits, and changes in that recorded SHA are not automatically reflected in the submodules.

This means that if someone else updates the recorded version of a submodule and you pull their latest changes in the parent repository, your submodule repository will still be pointing to the old version of the submodule. (To update it, you’d need to run git submodule update.)

Of course, if you forget to update your submodule to the new version, it’s then quite easy to commit the old submodule version in your next parent repository commit – thus effectively reverting the submodule bump by the other developer. Given that submodule changes only show up as 2 commit lines in a diff, it’s not hard for such a change to slip by (especially if you’re a developer that tends to use git add . or git commit -a most of the time).

Also, with all this comes merging nightmare when git suddenly goes into conflict resolution mode.

Final thoughts

These are some of the advantages and nuances of the reactive core architecture but I guess there are more advantages than nuances.

While this architecture focuses on business logic reuse, there still are other elements of an application that could be reused and shared among applications. In particular, for some projects, you may find that the containers could be candidates to live in the core module but that depends on the applications, definitely something nice to try out.