Darshan

Performance Optimization – Sevavaani Worker & Backend
The initial implementation of the system had several performance bottlenecks due to inefficient data handling and synchronous processing. Frequent redundant database queries, over-fetching of unnecessary data, and blocking operations led to high response times and instability. On the frontend, improper lifecycle handling caused duplicate API calls, while navigation and search logic further added to performance overhead.
Key Issues

• Redundant database queries increased latency and server load
• Over-fetching of complete datasets even when partial data was sufficient
• Synchronous operations blocking workers, causing restarts
• Duplicate API calls due to improper useEffect handling
• Inefficient navigation leading to unnecessary stack growth
• Backend-dependent search increasing response time and load

Optimizations Implemented
Significant improvements were made by restructuring both backend and frontend logic. Data fetching was optimized to reduce redundancy, asynchronous processing was introduced to improve speed, and concurrency handling was enhanced to ensure system stability under load.

Backend Improvements

• Reduced redundant queries and filtered only required data
  → getAllJobs improved from ~13s to ~0.43s
• Optimized client data fetching using selective retrieval
  → get-chatlist improved from ~9.56s to ~1.9s
• Introduced asynchronous data fetching to parallelize operations
  → reduced from ~6.24s to ~1.15s
• Enabled concurrency using gevent for non-blocking execution
  → stable handling of ~1000 concurrent connections

Frontend Improvements

• Prevented duplicate API calls using controlled useEffect logic
• Implemented global context caching to reuse fetched data
• Optimized navigation to avoid redundant screen pushes
• Implemented client-side search using filtering to eliminate repeated backend calls

Additional Enhancements

• Implemented search across jobs, requests, and chat
• Added Help & Support modal with email integration
• Linked the About Us section to the project repository

After much much errors, now things are getting functional
For many days, i was struggling with websockets + async functions + kafka producers/consumers + deployment issues.
The issue was things worked well on localhost with ws:// but when deployed on railway or render.
So i switched from flask to fastapi in python and use create_task() for background tasks

ITS TIME FOR DEVLOG
Update : Completed the producer and consumer part of kafka from react native app and admin webpage.
.
.
Journey:

• I faced a struggle in figuring out the actual and correct architecture for producer and consumer, but at last, after going to multiple YouTube videos and articles, I implemented websockets in Python Flask and a separate room for producing events, and a separate room for consuming location events
• New challenge which arose later was running producer and consumer loop simultaneously and asynchronously… but later I switched to creating a separate thread for each consumer
• At last, I created an admin dashboard to select a particular topic and consume events from it

Finally completed with both screens, i.e., “NEW RIDE” and “ACTIVE RIDE” in the app, So my next task is to keep producing events from driver app and monitor those from admin dashboard

––UPDATION IN WORKFLOW––
Earlier, I decided to directly produce location events from the driver’s app (in react native) to kafka topic and then directly consume it into the admin portal (webpage) to monitor and track
BUT BUT BUT, I didn’t get any working module of Kafka which will be compatible with React Native.
So I went through 2-3 articles and found out the correct architecture, and accordingly I revised my plan,
Now the following is my work flow
Driver app(react native) —–connects, joins and sends loc events—> python–>websocket room–>kafka-topic—–stream events—>admin portal

Due to new version release of Expo, I struggled a lot with project setup. I had to debug and research to solve many module version mismatches.
And the most time consuming and boring part is app prebuilding and bundling….Its always took long to assembleDebug and installDebug…
But after long, finally the project is free from all version mismatches and now runs smoothly

Earlier, while registering a new user, they need to verify the phone number, but this process required the OTP service to be continuously active on my local machine (which was not possible). So I removed that dependency and introduced a simple worker registration. Give it a try and let me know your feedback.
Guys, for your convenience, I have created a combined working video of my application..Enjoyyy

My last ship got rejected because the user registration failed due to inactive OTP server..
Actually, my original approach was to keep phone number verification using OTP but when searched about it, all OTP services were paid (quite costly as well). So i built my own approach..
You guys can check the sequence diagram in attached images. I built an android app with broadcast receiver registered for incoming messages and i run that on my device..
So when user enters phone number and clicks “Continue”, an OTP request sms along with uid is sent from their device to my phone, and as broadcast receiver is present, The app detects the new message -> generated secure random OTP -> sends back to USER from my phone + store in db
—–But PROBLEM : It required the app to be continuosly active on my device, which is practically not possible..
So i removed that dependency in this update, and now the user registration would work fine

AND—––
Guys, for your convenience, I have created a combined working video of my application..Enjoyyy

In this phase, I worked on sending quotation to jobs, and then viewing “My Requests”

• Once job is assigned, It will appear in “My Jobs”
• While completing job, unique QR will be generated, which will be shown to client
• Offline app interactions using async storage and syncing logic
• Aadhar based worker verification
• Corresponding backend apis in Python Flask

Recently I worked on adding a business model by integrating 3 subscription plans

• Basic
• Standard
• Premium
  and based on these plans, the client will have different level of privileges
  like client with BASIC subscription plan is only allowed to post max 3 jobs, chat with max 2 workers

I’m working on my first project! This is so exciting. I can’t wait to share more updates as I build.