Abhijit's Garden

Using RSS to take control of what I consume

2026-08-01T00:00:00Z

Nowadays brain-rot, brain-fog and decision paralysis are becoming increasingly common due to the overwhelming amount of content available on the internet. On top of this, big companies investing heavily to keep us longer on their platform, So it's easy to get distracted now a days. That's why, since few days I have been researching about how I can choose what I consume. Then I found out about RSS.

So what is this RSS? As per the wikipedia, it's a web feed that allows users and applications to access updates to websites. Basically it will monitor the websites for new content and show it in my feed aggregator.

So I started my quest of searching for a good RSS aggregator. Then I found Inoreader and used it for few days. But the problem with Inoreader is that it's bloated. My needs are simple: I just want an simple aggregator to add/remove feed and view their content.

Then I did some research and discovered a few self-hosted options. Among them, Miniflux seemed good for me. I liked it but for me it is also bloated. I have a 5$ server and as per miniflux setup instruction, I don't wanna use docker. Also it uses postgresql which I think overkill for my use case. I know there is a way to install it without docker but I don't wanna go through all those things.

Then I searched again and found another self-hosted option called yarr(yet another RSS reader). I will try setting this one up on my server.

I am also considering building my own RSS feed reader using simple tech stack like express.js, pug and sqlite. For my use case, this might be the best option.

I Thought Normalized State Would Fix My Re-render Problem. It Didn't.

2026-04-04T00:00:00Z

I was building a Kanban board called Kantoo and hit a classic React performance problem. This is what I tried, what didn't work, and what actually fixed it.

What I Built First

I went with a normalized state architecture managed through useReducer. The idea was simple: instead of deeply nested state, keep everything flat. Each column and card lives in its own lookup object, and you reference them by ID.

It felt clean.

The Problem

Even with normalized state, two things were going wrong.

A single card update was causing every component on the board to re-render, including columns that had nothing to do with that card. I could see it clearly in React DevTools Profiler. The render time for a single card move was sitting at around 55ms.

I was also passing data to components that didn't need it. Some components were receiving data purely so they could pass it further down, even though they didn't use it themselves. Just middlemen adding to the problem.

My First Idea: React Context

My first thought was to reach for Context. Put state in a provider and read only what each component needs inside a custom hook.

Sounds good in theory. But here's the catch: even if you only read one value from context, React still re-renders the component whenever anything in that context changes. The component is subscribed to the entire context object under the hood.

So Context would just move the problem, not solve it.

What Actually Fixed It: Zustand with Selective Subscriptions

The real fix is a library that supports selective subscriptions, where a component only re-renders when the specific piece of state it cares about changes. Zustand does exactly this.

// This component only re-renders when cards changes
const cards = useStore((state) => state.cards);

Once I migrated Kantoo to Zustand and combined it with the normalized state architecture I already had, something clicked. Untouched cards stopped re-rendering entirely. A card move now only wakes up the components actually involved.

The Results

I measured both before and after using React DevTools Profiler.

With useReducer and prop drilling, a single card move produced a render time of around 55ms.

After migrating to Zustand with selective subscriptions, the same card move commits in around 15ms. That is a ~73% reduction, not from micro-optimizations but from rethinking how state flows through the tree.

Why Memoization Alone Was Not Enough

This tripped me up early. React.memo only prevents re-renders when props do not change. But when state lives at the top and gets passed down, the parent re-renders on any update and passes new references down, so memo never gets a chance to bail out.

Zustand's subscriptions bypass this entirely. Components pull what they need straight from the store and ignore everything else.

What This Taught Me

Once you understand the difference it changes how you think about state:

Context is great for things that rarely change like a theme or current user. Zustand is better when you have frequently updated state that different components care about independently.

The key phrase is granular subscriptions. Components only pay attention to exactly what they need, nothing more.

Check out Kantoo on GitHub.

Re-rendering is not a bad thing in React

2026-03-03T00:00:00Z

Earlier, I had a misconception that if React re-renders, it’s a bad thing because extra work is being done.

I believed that when re-rendering happens, React has to do the same work again and again. So I thought, why repeat the same rendering process multiple times?

While deep diving into React, I learned about the Virtual DOM.

The real DOM is part of the browser and updating it is expensive. The Virtual DOM, however, is just a JavaScript representation of the real DOM. Updating the Virtual DOM is much cheaper compared to directly manipulating the real DOM.

Under the hood, when state changes, React creates a new Virtual DOM.

Then it compares the new Virtual DOM with the previous one. This process is called diffing.

If React finds differences, it updates only the changed parts in the real DOM instead of re-rendering everything. This entire cycle of creating a new tree, diffing it, and updating the browser is known as Reconciliation.

Re-rendering can become a problem in some cases:

If a child component performs an expensive task
- If the child component runs an expensive calculation during rendering, it may slow down performance.
- We can use React.useMemo to memoize the calculated value so it only recomputes when its dependencies change.
When a parent component updates but the child’s props do not change
- By default, when a parent re-renders, its child components also re-render.
- We can prevent unnecessary child re-renders by wrapping the child component with React.memo.
When passing a function as a prop
- Every time a parent re-renders, functions inside it are recreated.
- Since functions are compared by reference, React treats it as a new prop, even if the logic is the same.
- We can use the React.useCallback hook to memoize the function and keep its reference stable between renders.

Final Takeaway

Re-rendering itself is not bad in React. React is designed to handle it efficiently using the Virtual DOM. The real problem is unnecessary expensive operations during re-renders, not the re-rendering process itself.

BloodZone: Building a Scalable, Location-Based Donation Platform

2026-02-06T00:00:00Z

The Problem: Logistics, Not Lack

In emergency situations, the bottleneck isn't usually a lack of blood donors; it's an information gap. Finding a donor with the right blood type within a reachable distance often involves frantic calls and WhatsApp spam.

I built BloodZone to solve this logistics problem using engineering. The goal was to create an "Uber-like" experience for blood donation: finding the nearest eligible donor in milliseconds, not hours.

The Architecture

BloodZone follows a 3-tier architecture designed for speed and reliability. Unlike simple CRUD apps, the complexity here lies in three key areas: the Geospatial Engine, the Real-Time Communication layer, and the Secure Identity System.

The Stack:

Mobile: React Native (Expo) - Optimized for Android.
API: Node.js & Express (TypeScript).
Database: MongoDB Atlas (Utilizing 2dsphere indexing).
Real-Time: Socket.io with custom middleware guards.
Auth: Google OAuth 2.0 (Deep Link + Server Exchange).

Figure 1: High-level system architecture showing the Round-Trip Auth flow, Geospatial Query engine, and Real-Time Sockets.

Key Engineering Challenges

1. The "Radius" Problem (Geospatial Logic)

The core feature of the app is finding donors within a strict boundary (e.g., exactly 5km). Initially, I considered fetching all users and filtering them in JavaScript, but I realized that would kill performance as the user base grew.

I moved this logic to the database layer using MongoDB's $geoWithin combined with $centerSphere. The tricky part was the math: MongoDB requires radians, so I had to implement a converter to translate kilometers into radian coordinates relative to Earth's radius.

// The query that saved me from fetching 10k records
const users = await UserModel.find({
  location: {
    $geoWithin: {
      $centerSphere: [
        [longitude, latitude],
        radiusInKm / 6378.1 // Converting km to radians
      ]
    }
  }
});

2. Securing Open Sockets (Real-Time Auth)

I used Socket.io to allow seekers to chat directly with donors. The biggest risk with WebSockets is that they often bypass standard HTTP Auth headers, leaving the chat server vulnerable to spam bots.

To fix this, I implemented a Handshake Middleware. Before a socket connection is even "upgraded" to a real-time link, the backend intercepts the handshake, extracts the JWT, and verifies the user identity. If the token is invalid, the socket is forcibly disconnected before any data is exchanged.

3. Deep-Link Authentication (Handling State)

Security was a priority, so I didn't want to handle Google passwords inside the app. I opted for a "Round Trip" Deep Link strategy.

When a user logs in, the app throws them out to the system browser (Chrome/Safari) for a secure Google login. The challenge was getting them back into the app with the session intact. I had to configure a custom URL scheme (bloodzone://) so that once the server verified the user, it could "wake up" the app from the background and inject the secure tokens directly into the device's secure storage.

4. Architecting Real-Time Alerts (The Push Pipeline)

Blood donation relies on speed. To ensure donors are notified the second a request is generated nearby, I engineered a custom push notification infrastructure that bridges Expo, MongoDB Geospatial Queries, and Firebase Cloud Messaging (FCM).

1. Idempotent Token Synchronization The client lifecycle relies on a custom usePushNotifications hook to manage tokens. I implemented an idempotent synchronization pattern, ensuring that device tokens in the database remain consistent and unique without redundant network calls or duplicate records on the backend.

2. Geospatial Aggregation Engine The backend utilizes MongoDB’s 2dsphere indexing to execute precise, real-time proximity checks. When a request is triggered, the aggregation pipeline simultaneously filters active users within a 5,000-meter radius, excludes the requester, and validates token availability—reducing database load by combining discovery and filtering into a single operation.

3. Modern FCM Delivery Infrastructure I migrated away from legacy server keys in favor of the Firebase Cloud Messaging V1 API. By configuring Expo with a Google Service Account, the system dynamically mints short-lived OAuth 2.0 access tokens. This establishes a secure, authenticated relay for reliable message delivery to Android devices without managing long-lived secrets.

Lessons Learned & Future Scope

Building BloodZone taught me two critical engineering lessons that tutorials don't cover:

Database > Code: My first prototype tried to calculate distances using a JavaScript function. It was slow and crashed the app with large datasets. Moving that logic to MongoDB's geospatial index reduced query times by ~90%. It taught me to let the database do the heavy lifting.
State Management is Tricky: Handling the "app-to-browser-to-app" jump for OAuth was the hardest bug to squash. I learned the hard way that mobile apps often lose their "state" when backgrounded, requiring robust checks when the app re-mounts.

Current Constraints:

The app is currently optimized and tested for Android devices.
iOS support is in beta due to specific styling differences in the React Native engine.

Next Steps: Now that the main features are working, I want to fix any small bugs that come up during testing and finish the design tweaks needed to make the app run smoothly.

Project Links

Watch Demo Video
Request Access (Email)
Note: This project is currently in closed beta.

Hello, World!

2026-01-17T00:00:00Z

Welcome to my new portfolio and blog!

As a developer, there is almost a ritualistic obligation to title the first post "Hello World", so here we are.

Why I built this

I wanted a space that felt like me—minimal, fast, and completely under my control. I designed this site from scratch in Figma and built it using:

Astro for performance.
Tailwind CSS for styling.
TypeScript for type safety.

What to expect

I plan to use this space to document my journey in software engineering. You can expect posts about:

Low-level programming (C, systems, and networking).
Web development (building efficient, modern interfaces).
Project updates (deep dives into tools like Kuan and Termzic).

Thanks for stopping by.