You can reach the information about what's important from our perspective in showing what to expect from building a large-scale React-Native app within all details.

 

Table of Contents

Building a Financial Mobile App at Scale with React-Native

The Mobile App

The Choice of Technologies

Deciding on the App Architecture

Maintaining a Healthy Codebase

Conclusion

 

 

In today's post, we'll cover important information about showing the community what to expect from building a large-scale React-Native app. How do you choose the right technology, libraries, or even architecture to support growth without over-engineering your application from the start? How do you make sure React-Native is the right technology? We will explain by giving examples what are the important elements to consider to grow your React-Native application. 

 

The Mobile App

The mobile app is designed to help customers access their financial products without having to use the website. Thus, customers can check their balance, make payments, and even apply for new products directly from the app. As of today, the app is used by more than 200,000 unique customers monthly and is highly rated on both the App Store and Google Play Store. Choosing React-Native to build a mobile app often comes with the need for rapid growth with limited resources. The technology provides the option to build multiplatform applications, allow developers to reuse code with the web, and hire developers who can work in both the web and mobile applications without much of the company's learning curve.

Technology is often perceived as immature enough for large-scale applications. There are so many limitations on what can be done with it. There are also those who are concerned about security risks since the code is compiled with JavaScript. In our view, the problem is rarely the technology itself. However, expectations and limitations may need to be considered before starting.

 

The Choice of Technologies

We decided on several React-Native-related libraries and tech tools that would have the best future for building a long-lasting application. One of the first decisions we made was the adoption of TypeScript. If we go back then, the language was not yet as common as it is today. But it was taking some market share to the Flow types.

At the time we launched the app, we identified the technologies we knew were good. Like many JavaScript libraries, they get better or disappear with major changes to be replaced by other libraries. We chose Redux to store shared states across the application, including our network requests data. At the time, this decision was the right choice, but with the introduction of libraries like React-Query, Redux has become less necessary for us. You will always need to upgrade or migrate your dependencies to newer versions if you want to keep your app in good standing. With the JavaScript ecosystem, we tend to use a lot of external dependencies. Updating them is often a time-consuming process. But building everything from scratch will probably take even more time. This is something to consider when choosing React-Native. But that is the nature of all JavaScript application development.

 

Deciding on the App Architecture

As the company grew and business needs evolved, we added a few more features and more products to the mobile app. This also meant that developers had to add and change code without breaking anything. Unlike web projects that can be split into smaller applications and deployed independently, it is necessary to build everything in a single binary and distribute it to different stores.

One way to avoid bad planning issues is to structure your codebase around the concept of modules, each under its own responsibility. It can easily happen when there are not enough constraints on the overall architecture of the application when developers are free to decide on their own architecture when creating new features. You can usually understand good architecture when it takes very little effort to move a piece of functionality. In our case, we quickly made a decision to use a modular folder structure for our application, where we split our code logic into smaller, single-purpose business functions. This means that we set restrictions on what a module can do, use and provide to other parts of the application to limit the interdependencies and risks that come with connectivity features. As the application grows, we add additional modules or break existing ones into smaller modules.

Application modules are divided into the following types:

• Core
• Data
• Products
• Shared

 

With such architecture, we have one-way dependencies between features and kernel, while shared and data modules allow us to share the code we need in different parts of our application.

 

Maintaining a Healthy Codebase

Technology is at the forefront of the company. Taking aim to use innovative technologies allows us to focus on creating products with the best tools to tackle the problems we face. By choosing React-Native for our mobile app, we have become part of the fast-moving JavaScript ecosystem where perfect new libraries and tools are introduced regularly.  

 

We currently aim to regularly update our third-party dependencies. This is quite a time-consuming task, but it is a way to ensure that our codebase remains healthy and does not degrade over time by preserving legacy approaches and paradigms. Library updates often provide performance improvements and bug fixes that can make a huge difference not only to the application but also to the speed of the team. Usually, we don't update immediately when new major versions are released. We all know how problematic major releases can be. We try to be no more than 1 or 2 major releases for all of our libraries. Especially when you update React-Native itself, it can be difficult to skip too many major releases as the number of changes is often huge. 

 

Conclusion

React-Native has many great possibilities. It's a great framework that can help anyone build almost any mobile app possible, even banking apps. There is likely to be some friction from time to time. You will also need to bridge some features locally for your application. But at the end of the day, the added value of the framework makes up for the difficulties encountered. We hope that this blog post will be beneficial for you. We will continue to create useful works in order to get inspired by everyone. We are sure that we will achieve splendid things altogether. Keep on following Finage for the best and more.

 

You can start building your own Mobile Trading App with Finage free Market Data API key.

Build with us today!

Get a Free API key