About the Project
This project differed from the others we have mentioned in the case studies on this platform, in the way that it was not vibe coded, but the first time we laid eyes on it we knew that it was very much similar. The background story for this app was that it was deployed on an AWS instance but the sole developer responsible for this project was not available anymore and he had setup infrastructure to only be available for him which made it our first priority to go in there and retrieve the instance. Afterwards, what followed was
Team from Essentia
The team from Essentia consisted of myself and the Head of Engineering (Kunal Kushwaha). The initial setup was taken care of by Kunal, after which I contributed on frontend (majorly).
Scope & Duration
The application was already in a state where it did what was expected of it, in a development environment (so all the required features were already there) although there were a lot of factors that kept it from being production ready. It started with us making it live but other tasks were requirements were also made apparent with time, by the client.
It all lasted a total duration of ~11 months, during which time we ended up rewriting a huge chunk of the backend.
Tasks
1. Making the project live
- The very first task was to go in and retrieve their AWS instance. This involved configurational changes via the AWS Portal.
- For incorrect decisions which were configurational in nature, neither the backend nor the frontend could be made live. So naturally, the next step was to pin-point and rectify those.
2. Rewriting the backend
- The backend architecture was not at all designed for a scaled user base. In fact it was just being held together by a string of third party libraries that were plugged in as and when a need for their offering arised with no regard to having an optimised architecture.
- Majorly, it was using FastAPI as the api framework and Firebase for integrating database and authentication services.
- Our first step was to redraw the architecture from scratch using Django and Postgres as the primary stack. These two tools are very widely used for writing a scalable and highly maintainable backends.
- But a caviat here was, at this stage frontend changes were not a part of the picture. So, we had to craft APIs in accordance with the response payloads expected by the frontend.
3. Automation pipeline
- This stage involved us creating a CI-CD pipeline, to enable the application's automatic deployment on AWS.
4. Frontend changes
- Frontend changes came at a later stage.
- These mainly involved bug fixes and minor feature changes.