“It’s not we use technology, we live technology” — Godfrey Reggio
MoEVing is not just a company in the electric vehicles industry. While we do a lot of things in this sector, we want technology to be our primary differentiator, and that is how our first app came about.
The app serves as a demand management platform for our drivers, and we also have a web interface for our admins to track the data.
Seems fascinating, isn’t it? Let’s not keep you waiting and directly move on to the app development process.
Our Tech Stack
With our product roadmap, it seemed best to go with a microservices architecture; it offered a few major advantages:
- Increased resilience since failure in one service will have minimal impact on other services
- Independent Scaling of Services
- Ease of fault isolation and debugging
The biggest advantage of the microservices architecture is that teams can develop, maintain, and deploy each microservice independently. Each service can use its own language, database, the framework that best fits the requirement.
Hence, our entire system was designed with microservices in mind.
Which Database to Choose? — The Real Quest
For a while, we were conflicted with our choice of database, between SQL and No SQL.
SQL databases are ACID compliant but are complicated to scale vertically.
A NoSQL database is suited for unstructured data that won’t fit neatly into a table. NoSQL databases were built with flexibility and scalability in mind, and follow the BASE consistency model.
Since our data was structured, and there were parts of our system where transactions were crucial, we decided to use MySQL as the database.
For our backend, our first choice was clear-cut. It has to be python because of the extensive online support it provides, and the availability of numerous packages is something you cannot miss. The elegant syntax of the language and code readability enable rapid application development and easy debugging.
Backend Framework- Narrowing our Choices
For the backend framework, we narrowed our choices to Django, Flask, and FastApi.
Django
Django is a secure framework and comes with a built-in authentication system and Cache framework; it is popularly used for web development. It has many reusable modules that make it a heavy and not the most suitable framework for our case.
Django includes a default ORM (object-relational mapping ), which was created before SQLAlchemy, making Django ORM inferior to SQLAlchemy because it is less flexible.
Flask
Flask, on the other hand, is a lightweight framework. Flask uses Modules, which is a third-party involvement and makes it more vulnerable. The modules are in between the framework and the developer.
Flask has a singular source that implies that it will handle every request in turns, one after the other. So, regardless of how many multiple requests you put, it still takes them in turns, which is time-consuming.
FastAPI
FastAPI is a modern Python web framework for building APIs based on standards for APIs like JSON Schema (a tool used for validating the structure of JSON data), OAuth 2.0 (it’s the industry-standard protocol for authorization), and OpenAPI (OpenAPI is a publicly available application programming interface that provides developers with programmatic access to a software application or web service).
It provides automatic data model documentation with JSON Schema. Further, it leverages the asyncio library, which makes the framework suitable for asynchronous code.
We ultimately decided to go with the FastAPI framework for our application and use SQLAlchemy to interface with our database.
Why Choose React for Web Application?
We use React for our web application and React Native for our mobile application.
Choosing React was always a no-brainer. With it being the market leader in the industry, it is always a front contender for startups.
Compared to Angular, it has a larger volume of developers in the market. Also, Angular has a learning curve that would make it unsuitable as it would have impacted the pace of development.
Additionally, react paired with react-native for our mobile app gave us the flexibility to reuse the knowledge and experiences of our developers. Sticking to a single tech stack also made it faster and easier to develop applications, which are vital in a startup environment.
Traditional technologies for mobile app development required maintaining two different codebases — one for android and the other for iOS. React native eliminates this heavy cost by allowing us to have a single codebase. A huge advantage!
React Native actually converts the JavaScript components into native components, unlike hybrid mobile application technologies like Cordova, which uses browser-based webView. This gives us performance benefits because native components are always faster.
React/ React Native community is growing. Combine that with a large number of libraries, plugins, and components that are readily available for development; made the tech stack perfect for us.
Using AWS to Host our Services
Our services are hosted on AWS; we use elastic beanstalk for our application, RDS for our MySQL database, S3 for document store, and CodePipeline for our CI/CD pipeline.
Although both Azure and AWS are cutting-edge cloud platform providers, AWS has more advantages than Azure.
- AWS is more mature and offers more cloud products and services than Azure.
- Our application will compute heavily, and from our research, AWS turned out to be cheaper than Azure when it comes to compute pricing.
The fact that our team members were already familiar with AWS was one more reason to go with AWS.
Phases of the App Development Process
Even before we started our app development process, we had some operations on the ground, which were handled manually through Google forms, excel sheets, and some other tools.
It became quickly evident that this would not scale and how essential it was to have a technology-backed solution.
1. Gathering Requirements
The first step was to gather requirements. We started with understanding our current operations, their shortcomings, and the role that technology can play to overcome these challenges along the way. We also envisioned where we wanted to be a few months into the future and the features we would want later, we added those to our requirements.
Needless to say, our Product Requirements Document (PRD) blew up. It was more practical to restrict the scope of implementation for our first app, our Minimum Viable Product (MVP).
Also, it made sense to have a clearly defined vision for the product in our PRD, because it made it easier to break the work into well-defined phases. It helped determine the immediately required features and also guided the smaller decisions and clarifications in each phase.
2. Designing Phase
The next step was the design. This was very exciting because it was the first time we were visualizing the look and feel of our app.
We started with the features required for MVP and defined the workflows, and described the user stories. There was a lot of brainstorming to iron out the nitty-gritty details of the application.
While it was important to cover all the use cases, we did not want to over-engineer the very first version of our app. We anticipate that there would be some changes required, once our app is released to production and our teams start using it.
Next was the system design phase. We plotted the architecture of our application and finalized our tech stack (the details of which have been mentioned above). We mapped out our database structure with all the tables and fields required and defined the services to be created.
Then the setup, the servers, and databases were created on AWS; we used GIT for code versioning and docker to containerize our applications. We knew we wanted CI/CD to be set up from the start, and we implemented this using AWS CodePipeline.
3. Development
Then came the busiest phase — Development. We had two week-long sprints, and before each sprint, we had sprint planning meetings where we defined task priorities and assigned tasks.
We had regular scrums to track progress and make sure all of us were on the same page with respect to the requirements and implementations. Before long, we had the test cases documented, and full-fledged testing started, and then issues and bug fixes.
Parallelly, the operations team collated the user data. Once our app was stable, we imported the user data into our database.
Lo! Our first mobile app and web app were released, and users started using the app for their everyday operations.
Was it difficult? No… Well, maybe a little
Was it exciting and fun? Yes
Is it perfect? No, but we are making it better.
Is that going to stop us from making more products? Definitely not!
We conquered our first hill. What’s next?
Well, this was just the beginning.
We are on our way to design the next phase of our app.
We have many more products that are in our pipeline. We are expanding our technical team, some of them have already started the design and development of one of these products, and that too using a different framework.
But can we disclose everything now? Not yet.
Ramya T R,
Backend Developer,
MoEVing
However, if you want to know how the making of MoEVing platform started, give a read to the Making of MoEVing Platform, why was the app created?
If you want to be a part of a bigger process, apply right away at https://moeving.freshteam.com/jobs.
