How we build an architecture of our application
Since February 2020, I commit to working with my team as a Front-end engineer and Front-end DevOps to build an application about eradicating tuberculosis in Depok city. We started at zero, and we really have a good conversation at that time to talking a lot of things including software architecture.
In this article, I want to share with you how I and my team are able to build the architecture of our application. Enjoy!
Big Map
So we use three-tier architecture, which means our application separated into three parts, namely client layer, business layer, and data layer. Even though we use three-tier, we always see this architecture as two groups, namely front-end and back-end. In front-end, there are mobile and web, built with React. In the back-end, we have two servers for doing all logical tasks and manage the database. For a better picture of it, let’s see the image below!
So the main reason why we choose this architecture because we have two applications in the front-end, and it’s impossible to implement that in one-tier architecture. Furthermore, we want to have the freedom to control the logic of business in front-end, so we couldn’t have business and database into one, that’s why we choose three-tier architecture instead of two-tier architecture.
Servers
We use Git Flow in our architecture, which means there are three stages, namely development, staging, and production. So we planned to serve each stage with different servers. We use a free server to serve our back-end servers and web application. Used all servers only for staging and production. You notice that we didn’t set up servers for the development stage, because that branch is used and runs the application locally, which means all developers must use their own server to run the application in the development stage. Also, we don’t need a server for our mobile application since our mobile is compiled into APK and AAB(Play Store). To get a big picture of it, let’s see the distributions from the table below!
So in total, we are using 4 servers.
Deployment and Docker
We thought, build architecture is not enough to achieve the maintainability of the system. So we try to integrate CI/CD that includes test, build, and deployment. Because by doing this, we just increase up the operability aspect, which means it’s part of the maintainability and will increase that up too.
As I mention, CI/CD includes test, build, and deployment. But in fact, our back-end system has different stages, there is no build stage since our back-end is not built into static files or APK like mobile. Also for mobile, there is no deployment stage since the mobile output is an installable application. We built a script for CI/CD both in front-end and back-end and wrote in the same commands for staging and production but different environment variables to tell the script which server they should deploy to or API URL needs to use.
Docker helps us to set the environment for our runner to run the script, on the web we use Docker to build an image that contains node and npm. On the other hand, we also build an image for mobile that contains node, npm, npx, JDK, and AndroidSDK in order to build a mobile application into APK and AAB.
The Scale Cube Perspective
In our architecture, we also try to have a scalability factor as much as possible. We want it because our application is a sustainable type, which means it will be used and developed even though we are no longer maintainer s of this application, we will release this application around late May and at that time we will give the ownership of codes to the client. So it’s important to having scalability factors because the number of users will grow up without we know it and scaling an application will be important.
X-axis
In the back-end, we did this by having a load balancer. The load balancer will copy our API into N for 1/N user, it’s distributed in balance. So all users able to use our API at the same time and there is nothing to worry to wait for each other when using our API from mobile or web. But the problem is the server we use, we afraid the number of users will be bigger enough one day, so we can’t use a free server anymore that has a limit on that day as we have right now.
Y-axis
By having a three-tier architecture, we actually just increased up the y-axis scaling because we split up all services into three services and each of them could be independent of each other. The three services are mobile, web, and back-end (business layer + data layer), each of them can be developed without knowing what the real implementation of another service. So in our team, we also split into three groups and we communicate to each group by only knowing what they need in order to use their service and what they could give to us, so not the implementation. Personally I found it useful since we could work faster without knowing all codes.
Z-axis
Unfortunately, we are not yet thinking about this scaling factor, since we use a free server, which means we have no ability to control the distributions happens on the load balancer. But we thought it’s no a big deal for now because it only uses in Depok city, I think having 100–1000 users still reasonable number without scaling in the z-axis.
Takeaways
I hope this article gives you more insight to understand more how to build an architecture for your application. For me, I still need to learn more because there is no guarantee that our architecture is the best one we have. Thank you!
