In the era of the Internet, we build more and more applications. We are consuming more resources, money and energy. I have a feeling that a lot has been said about making scalable APIs. There are many tutorials about choosing the right technology for scaling, designing architecture that supports scaling or setting up infrastructure to achieve it. But how does this work from the mobile perspective? How should we build scalable mobile apps? In this blog post, I’d like to take you for a ride and see how can we approach this topic.
YOLO development
In my career, I’ve witnessed a lot of mobile apps. The vast majority was made with YOLO development approach.
“YOLO (you only live once) development, is the approach when developers write code not thinking about the consequences of tomorrow.”
YOLO development is not mobile-related. It can be seen everywhere.
BDUF
On the opposite side of YOLO development, there is a big design up front (BDUF). The situation where we spend time (over) thinking about the solution. We try to design the application in a way where everything is covered and well thought out. That’s not perfect either
YOLO dev vs BDUP
The discussion of which approach is better is a never-ending story. It’s like tabs vs. spaces. To me, none of them is good. A path in between is a way to proceed. I won’t do BDUF, but I would spend some time preparing for the starting project.
Factors
To begin with, I would think about the solution under development. In the context of “Scalable mobile apps”, when should we consider this?
User Growth
In general, the more people use the app, the bigger the success.
Disclaimer: this might not be true for all apps.
Mobile apps are installed on mobile devices (no shit Sherlock), that are owned by people. If Google Play/Appstore can handle the traffic, it should be fine to have people install the app on their devices. The problem might become when they start using the app. A lot of the apps, available on the market, require some online connection.
Log in to the app, get the data, and post the data. Even though the app itself will handle user growth, it can be the backend service that might be the bottleneck. It’s good to remember about this and test the solution in advance. To do this you can do some performance, load or stress testing on the API part.
User load
Another thing is user load. Again, this is something relevant to the API but it can affect your mobile. It may happen that the traffic in the app won’t be stable. It may be constant over the week or it might be in peaks. If it’s the latest, are you ready for that? Assuming you expect to see huge traffic on a particular day during the year (eg. BlackFriday). What is your plan to support that?
Future-proofing and lifetime
How long will your app live? Is it an app for an event and you won’t need to support it in the future? Are you aiming to constantly add new features? What’s the plan?
When doing scalable mobile apps this is the biggest factor from the pure mobile perspective.
If you plan to support the app for a longer period, it needs to be done in a way that adding new features painless.
If you expect more features to come, you may expect the team to grow. The more people in the team, the more problems you may have.
If your app grows, what is your plan to tackle that problem?
New geos
Taking about future-proofing, it’s good to answer a question whether the app might support new geos in the future. I’ve witnessed an app that was not able to enter new geo because it lacked support of localization. Languages, metrics – that might be a show-stopper.
Changing logic
Another thing worth thinking of is changing logic. The mobile release cycle differs from web development. To update the app on client devices, you first need to release a new version to both Google Play & AppStore, and once the update is available users need to update the app – trust me you will be surprised how many people don’t do it.
If your features require constant changes in logic, you may not want to do it in the app. You may want to move everything to your API.
Imagine a tax calculator that would count your net salary based on your gross salary. Let’s assume it’s a simple logic (in Poland, it’s not a simple logic).
You can easily do it on the mobile side. But do you want to do it? If the law changes, you will have to release a new version of the app and the user will have to update. If you have such places in the app, it’s good to think about them in advance and move such logic to your backend.
Performance
Another thing that is closely related to the growing code base is the performance of the app. The more code you have, the bigger the app. The bigger the app, the slower it may become. The slower the app, the less satisfied users are.
Predicting such problems may save you some struggle in the future. When you are aware of potential performance problems, you may design tests in advance and run them periodically. Monitoring performance means that you can get notified when you exceed the SLO. And this might save you some money.
Think first
Running to a conclusion, I encourage everyone to think about the code they are going to write.
5 minutes of planning might save you problems in the future that may cost you much more.