Software Architecture: All you need is (mostly) just the simple one that works
It’s time to start a new project (for this article, web app project). Fresh ideas came out of your mind waiting to be transformed to side projects (that hopefully you will eventually finish), or requirements given from a client or as an assignment. I look at the details thoroughly, clarify a couple things to the owner, mapped all the flows and fancy features, and now its time to design. Yes, you’ll also need to design as in UI design. But another thing that you should design is the architecture of the product.
You looked around and search for similar products and trying to make sense of their architecture design. Read articles about fancy, cool, sophisticated ways to organize your product into fine-grained services. Alternatively, you can just simply follow as in your favorite framework’s tutorial and that’ll work just fine. Now, which way should you take?
The answer would be depends. Yours may vary based on scalability, upcoming features, etc. But on most of projects, starting simple may be the best decision for a certain period of time.
Project
On my group project we are building a tuberculosis case tracking/filing app that consists of the main backend service, web dashboard application for the admins, and mobile application for the field officers who will do the case filing/tracking on patients’ place. We ended choosing the simple monolithic for the backend, split the frontend out of the backend, making use of React and React Native for the dashboard and mobile apps respectively. In total, there are 3 services or products that we have to develop and maintain throughout the project time frame.
Why did you decide (to use) x?
That design is what is in my head along with other of my teammates’ when we discussed about the architecture, and we’re happy it worked out fine.
What we need
- Separate project and pipeline for both web dashboard and mobile app.
We will be developing both in different rate, choice of libraries, and sub-team. So we decided to split the frontend side: web and mobile; as separate projects. To provide data for these two clients, a separate backend service is needed as well. - Relatively easy and familiar mobile app development.
Only 1 out of 5 people in our team that have experience in mobile development, while all of us have used React before. So, the choice of React Native is in everyone’s favor since it’s easier to learn (just a quick transition from web React). - Simple deployments
This app is built for a non-profit NGO with no dedicated tech/engineering team. Designing a complex architecture ends up in a more complicated way of deployment. Maintenance needs to be super simple so we just need a single instance of backend and database, store and serve the web dashboard and mobile app build somewhere (static file serving that requires minimal to no maintanance), and the organization just need to deal with recurring payments over the time (errors and feature addition aside).
What we don’t need
- Extreme (high number) scalability
The system will only be used by a relatively fixed amount of people: administrators and field officers. The administrators aren’t that much, and they will register relatively few number of field officers. User data is not that much either. This project’s scope is only within Depok City. If this would be used in a nation-wide scale, different approach and design would be chosen (with a lot more features, might consider the use of microservices for the backend). - Super-native mobile app performance
That’s why we ended up fine with React Native anyways, all the app do is to submit forms, manage activity logs, and see patients’ data. Nothing needs intensive workload or super-efficient native performance, the size of the bundled app is fine as well (React Native apps’ sizes tends to be bigger than the native counterpart, native Android and iOS)
Deployment and environment
We have two environment: staging and production, iteratively work on the staging environment and gradually push finished part of the product to the production environment. When we’re done, our client only need to maintain the production environment. For the deployment, we simply have two copies of everything. Two instance of database, backend server, CI/CD pipelines, web app deployment, and mobile app artifact build pipeline.
Your situation might differ from mine, in the context of the application, user base, number of features, scalability, maintainability, etc. Every decision have its own tradeoffs compared to the next choice. There is no a single silver bullet architecture to rule all different system requirements. There is still so much to learn to be able to design a great system with its list of requirements and features. If you’re interested, I can recommend this GitHub repo donnemartin/system-design-primer for further reading.
This article is a part of my writing series about software development that cover topics such as Git, Agile framework, TDD, Clean Code, CI/CD, and many more.
