Forem: Arnab Saha

A Curated LeetCode List for Full-Stack Developers

Arnab Saha — Sat, 18 Apr 2026 11:14:05 +0000

I built this list for myself while going through a full-stack web development journey and preparing for job placement in parallel. If you are in a similar position — actively building things, learning a framework, and trying to keep problem-solving consistent without burning out — this might be useful for you too.

Link: https://leetcode.com/problem-list/wgazxxzm/

What is in the list

191 problems across four categories in this order:

TypeScript (23) → DSA Part 1: Arrays & Hashing, Two Pointers, Sliding Window, Stack, Binary Search → SQL (21) → DSA Part 2: Linked List, Trees, Heap/Priority Queue, Backtracking, Tries, Graphs, Advanced Graphs, DP, Greedy, Intervals, Math & Geometry, Bit Manipulation (143) → Bash (4)

Why TypeScript

My daily stack is Node.js and React. Solving in TypeScript means I am reinforcing types, generics, and interfaces while solving the problem. The language practice compounds with the algorithmic practice instead of running separately. You are not context-switching into a language you do not use — you are practicing the one you already write every day.

The only rule I follow

Spend at least 30 minutes and up to 1 hour each day before starting development. The ceiling is the point. I am building real projects at the same time. Uncapped LeetCode time kills everything else.

Deep work on 191 curated problems beats shallow coverage of 500.

If you are on a similar path — full-stack dev, job hunting, trying to keep everything moving without dropping the ball — feel free to use the list. Would love to hear how others are balancing this.

I Built a Multi-Provider AI Chat App with Django and React — Here's What Actually Happened

Arnab Saha — Mon, 02 Mar 2026 17:14:34 +0000

The Idea

The core idea was simple: a ChatGPT-like interface backed by free-tier AI APIs, with Google login, persistent chat history, and real-time streaming. The twist was multi-provider routing — if Groq's free quota runs out mid-day, the app silently falls back to Gemini, then Mistral. The user never sees an error. They just keep chatting.

Stack I chose:

Django 6 + Django REST Framework on the backend
React 19 + TypeScript + Tailwind CSS v4 on the frontend
Groq (Llama 3.3 70B), Google Gemini 2.0 Flash, Mistral Small for AI
Google OAuth 2.0 for auth
Render (backend) + Vercel (frontend) + Neon (Neon) — all free tier

Starting with Auth

I wanted Google OAuth because it's frictionless for users. No password forms, no email verification — just "Sign in with Google" and you're in.

The standard django-allauth approach assumes a server-side redirect flow — Google redirects back to your Django backend, and Django sets a session cookie. That doesn't work cleanly when your frontend is a separate React SPA on a different domain.

So I went with the implicit flow: the frontend handles the Google popup, gets the credential token directly from Google, then sends it to Django. Django validates it against Google's API, finds or creates the user, and returns a JWT pair (access + refresh). From that point forward, it's just JWT auth.

This meant writing a custom GoogleLoginView that takes a Google credential, calls Google's tokeninfo endpoint, extracts the email and profile data, and issues tokens. It worked — but it took longer than expected because the django-allauth docs assume the redirect flow, and the custom path is not well documented.

What I learned: When your frontend and backend live on different origins, think about auth flows from first principles. Don't assume a library's default flow fits your architecture.

Designing the Database Before Writing Any AI Code

I made a deliberate choice to fully design and implement the data layer before touching any AI integration. The models were:

ChatSession — belongs to a user, has a title, tracks created/updated time
Message — belongs to a session, stores role (user/assistant), content, which AI provider responded, and which model was used
ProviderUsage — tracks daily usage per provider so the routing logic knows when to fall back

That last model was the important one. The fallback logic needed to survive server restarts. If I tracked quota exhaustion in memory only, a Render dyno restart would reset it and I'd hammer a dead quota again immediately. Storing it in the database means the state persists across restarts.

Building the Multi-Provider Router

This is the part I'm most satisfied with.

The router works like this:

Try Groq first (fastest, Llama 3.3 70B)
If Groq returns a quota error, mark it exhausted in the DB for today and try Gemini
If Gemini fails, fall back to Mistral
If all three are exhausted, return a clear error to the user

Every message response records which provider and model actually served it. So in the DB you can see "this message was answered by Gemini because Groq was exhausted."

The tricky part was making the fallback transparent to the streaming layer. Once I start streaming tokens to the client, I can't switch providers mid-response. So the fallback only happens before streaming begins — the router tries to open a connection with the provider, and if that fails, it retries with the next one before sending a single byte to the client.

SSE Streaming Was Harder Than I Expected

Server-Sent Events looked simple on paper: Django yields chunks, the browser reads them. In practice, several rough edges appeared.

CORS and SSE don't play well by default. My frontend is on Vercel, my backend on Render — two different origins. SSE connections are long-lived and behave differently from regular XHR requests when it comes to CORS headers. I had to verify that Django's CORS middleware applied correctly to streaming responses.

Django's ORM doesn't like being called inside a generator. When you yield from a Django streaming response, you're inside a generator function. Database writes (like saving the completed message after streaming finishes) need careful handling. I collected the full streamed content and wrote it to the DB in the generator's finally block.

The client needed an abort mechanism. If the user clicks "stop generating," the frontend needs to cleanly close the SSE connection. On the React side, this meant using an AbortController. On the Django side, catching GeneratorExit when the client disconnects.

Tailwind v4 and the Design Token System

Tailwind v4 is a significant departure from v3. There's no tailwind.config.js anymore — all custom tokens are defined in your CSS file using @theme:

@theme {
  --color-surface-base: #1a1a1a;
  --color-ink-primary: #f0ede8;
  --color-line: #2e2e2e;
}

I mirrored these in a theme.ts file for the rare cases where I needed values in JavaScript. The rule I set for myself: no hardcoded hex values in any component. Everything goes through a token class like bg-surface-base or text-ink-primary. This paid off when I wanted to adjust the base background — one line in the CSS file, done everywhere.

The downside: Tailwind v4 is still new and the ecosystem hasn't fully caught up. I hit cases where shadcn/ui components assumed v3 configuration and needed manual adaptation.

Deploying on Free Tiers

Both Render and Vercel have generous free tiers, but they come with real constraints you have to design around.

Render's free backend spins down after 15 minutes of inactivity. The first request after a cold start can take 30-50 seconds. For a chat app where the first thing a user does is send a message, that's a painful first impression.

The fix turned out to be simple. I created a lightweight /health endpoint on the Django backend that just returns a 200 OK, then set up a free UptimeRobot monitor to ping it every 5 minutes. Render never gets the chance to spin the instance down. No cold starts, no 50-second waits, no frustrated users — and it costs nothing on either side.

Sometimes the "real" fix is just a cron job with a URL.

PostgreSQL on Neon free tier has connection limits. Django's default connection behavior opens a new connection per request. Under any real load, this exhausts the connection pool. The fix is CONN_MAX_AGE in Django's database settings.

Environment variables across two deployments get tedious. Django needs GOOGLE_CLIENT_ID. React also needs VITE_GOOGLE_CLIENT_ID (Vite's required prefix for client-side vars). The same value, two names, two dashboards. Small thing, but error-prone. I kept a .env.example for both services and updated them in sync.

The Context Window Problem

Early on, I was only sending the user's latest message to the AI. The AI had no memory — every message was a fresh conversation. Obviously wrong for a chat app.

The fix is sending the last N messages as conversation history on every request. But N has to be bounded — very long sessions would exceed the model's context window limit and the API would return an error.

I settled on a configurable CONTEXT_WINDOW_SIZE (last 20 messages by default), queried from the DB before every AI call.

Auto-Generating Session Titles

When a new session starts, it has no title. I wanted it to appear automatically after the first exchange.

After the first user message and AI response are saved, a separate lightweight AI call generates a short title (under 8 words) based on the conversation content. It runs after streaming completes so it doesn't block anything. The frontend polls for the session update and renders the title in the sidebar when it arrives.

Small feature, but it makes the app feel complete rather than like a half-finished prototype.

What I Would Do Differently

Start with the streaming architecture. I built the basic request/response flow first, then had to rework significant parts to support SSE. Designing for streaming from day one would have avoided most of that rework.

Write the API contract first. I built backend and frontend somewhat in parallel, which meant changing endpoint shapes while the frontend was already consuming them. A simple spec written upfront would have saved some self-coordination overhead.

What I Actually Learned

Free tiers shape your architecture whether you plan for it or not. Cold starts, connection limits, quota limits — these aren't edge cases on free hosting. They're the default. Design for them early.

Multi-provider AI routing is genuinely useful, not just clever. Since deploying, Groq's free tier has hit its daily limit multiple times. Without the fallback, the app would be broken for the rest of the day. With it, users don't notice.

SSE is underused and underappreciated. For one-directional streaming from server to client, SSE is simpler than WebSockets in almost every way. It works over plain HTTP, handles reconnection natively, and needs no special infrastructure. Reach for it before WebSockets when you only need server-to-client streaming.

Design tokens are worth the upfront investment. The Tailwind v4 token setup took a couple of hours. But having a consistent, named color system meant I never debated "is this the right shade?" The answer was always "use the token and move on."

Try It

The app is live at arnabsahawrk-ai-chat-assistant.vercel.app. Sign in with Google and send a message. If Groq's quota is spent for the day, you will be talking to Gemini without knowing it.

Source code is on GitHub and the API documentation is at ai-chat-assistant-4agm.onrender.com.

If you spot something that could be done better or have an idea worth trying, drop it in the comments — always open to it.

Access Token & Refresh Token: A Breakdown

Arnab Saha — Thu, 18 Jul 2024 06:31:01 +0000

Understanding Access Tokens and Refresh Tokens: The Keys to Secure Authentication

Introduction

In this post, I'm trying to explain the concepts of access tokens and refresh tokens, two crucial components of secure authentication in web applications and APIs. By understanding their roles and how they work together, we can build robust and user-friendly authentication systems.

What is an Access Token?

An access token acts like a digital key that grants temporary permission to access a specific resource within an application or API. When a user successfully logs in, an access token is issued. This token contains essential information, such as user identity and permissions, allowing them to interact with the application's functionalities.

Key characteristics of access tokens:

Short-lived: Access tokens typically have a short lifespan, often expiring within minutes or hours. This security measure helps minimize the potential damage if the token is compromised.
Limited scope: Access tokens can be granted with specific scopes, restricting the actions a user can perform. This prevents unauthorized access to sensitive data or functionalities.
Self-contained (sometimes): Access tokens might contain enough information to validate the user's identity without needing to contact the authentication server for every request.

What is a Refresh Token?

While access tokens are essential for immediate access, their short lifespan poses a challenge: what happens when the token expires? This is where refresh tokens come in. A refresh token is a long-lived credential (often lasting days or weeks) issued alongside the access token during login.

Key characteristics of refresh tokens:

Long-lived: Designed to last longer than access tokens, allowing users to maintain their logged-in state for extended periods.
Limited functionality: Refresh tokens themselves cannot access resources. They are used solely to obtain new access tokens.
Secure storage: Refresh tokens are more sensitive than access tokens and should be stored securely on the server-side (e.g., database) to prevent unauthorized use.

The Flow of Authentication

Login: The user enters their credentials (username and password) to log in.
Authentication: The server verifies the credentials and, upon successful authentication, issues an access token and a refresh token.
Access: The user interacts with the application, sending the access token with each request to access resources.
Expiration: As the access token nears its expiration, the application sends the refresh token to the server.
Refresh: The server verifies the refresh token and, if valid, issues a new access token, allowing the user to continue accessing resources without needing to re-login.

Benefits of Using Access and Refresh Tokens

Enhanced Security: Short-lived access tokens minimize the risk of unauthorized access even if compromised.
Improved User Experience: Refresh tokens prevent frequent login prompts, ensuring a smooth and uninterrupted user experience.
Reduced Server Load: By using cached access tokens, the server is not overloaded with constant authentication requests.

Conclusion

Access tokens and refresh tokens play a vital role in secure and user-friendly authentication. Understanding their distinct characteristics and their coordinated function is essential for building robust web applications. By implementing this two-token approach, we can ensure a seamless user experience while safeguarding sensitive data within our application or API.

TanStack Table Explained: Everything You Need to Know

Arnab Saha — Fri, 28 Jun 2024 12:37:49 +0000

Unlocking TanStack table potential to get started with it. Learn by creating something cool with it.

Introduction

In the world of modern web development, displaying data effectively and efficiently is a common challenge. Whether it's a simple list of users or a complex financial report, tables are essential. While there are many libraries available to handle tables in React, few offer the flexibility, performance, and ease of use that TanStack Table does.

TanStack Table, previously known as React Table, has quickly become the go-to solution for developers needing powerful and customizable table components. TanStack is not only compatible with React but it also supports Angular, Lit, Qwik, Solid, Svelte, Vue, and also Vanilla JavaScript/TypeScript.

In this post, I'll dive into what makes TanStack Table stand out, explore its core features, and provide a hands-on example to get you started.

What is TanStack Table?

TanStack Table is a lightweight, highly customizable, and headless UI for building powerful tables & data grids. By "headless," I mean it comes with all the core functionality and logic for table operations without any user interface. This gives us total control over our table's appearance while also taking advantage of the built-in functionality.

Why Choose the TanStack Table?

Choosing a table library for your project can be confusing as so many options are available online. Here’s why TanStack Table might be the best fit for your next project:

1. Performance

When our dataset is large, managing it efficiently becomes crucial as we also have to take performance into account. TanStack uses features like Virtualization and Tree shaking which are methods for optimizing performance. It also optimizes rendering to ensure that even if there are tens of thousands of rows the performance is smooth.

Tree shaking is a process of optimizing during final javascript bundling, it removes all the dead code or unused code from the bundle.

Virtualization or Windowing is a technique to improve performance by only rendering the items that are currently in view.

2. Adaptability

TanStack table supports headless architecture which allows us to be free from any built-in UI. Its high customizability lets us integrate it with any CSS framework or theme. This flexibility comes in very handy when design changes are required for almost every project.

3. Advanced Feature

TanStack Table supports a wide range of feature lists such as:

Sorting with customizable sort functions.
Built-in filters or custom filter logic.
Hide or unhide any column.
Built-in pagination logic.
Group rows by any criteria.
Dynamic resizing of columns.
Select rows with checkboxes or other UI elements.

4. Active Community and Support

TanStack Table is actively maintained and is supported by a great community. The documentation is precise and easy to understand.

Key Challenges When Using TanStack Table

Although TanStack Table offers many advantages, it also has some drawbacks:

Managing column width according to data length.
Making the table responsive for all screen sizes.
Debugging a custom build table using the TanStack table.
Comprehensive documents can make it difficult to find quick answers.
The learning curve is steep.

Getting Started with TanStack Table

Let's start with a simple example. I'll create a basic table using TanStack Table.

Step 1: Install TanStack Table

First, let's install TanStack Table and its peer dependencies.

npm install @tanstack/react-table

Step 2: Set Up the Table

I'll start by setting up our table component. For this example, I’ll use a simple dataset of users.

import * as React from 'react';
import {
  createColumnHelper,
  flexRender,
  getCoreRowModel,
  useReactTable,
} from '@tanstack/react-table';

export type User = {
  id: number;
  name: string;
  age: number;
  email: string;
  country: string;
  subscription: string;
  wallet_balance: number;
};

export const users: User[] = [
  {
    id: 1,
    name: 'John Doe',
    age: 35,
    email: 'john.doe@example.com',
    country: 'United States',
    subscription: 'Premium',
    wallet_balance: 150.25,
  },
  {
    id: 2,
    name: 'Alice Smith',
    age: 28,
    email: 'alice.smith@example.com',
    country: 'Canada',
    subscription: 'Basic',
    wallet_balance: 50.75,
  }
];

const columnHelper = createColumnHelper<User>();

const columns = [
  columnHelper.accessor('name', {
    header: () => 'Name',
    cell: (info) => info.getValue(),
  }),
  columnHelper.accessor('age', {
    header: () => 'Age',
    cell: (info) => info.getValue(),
  }),
  columnHelper.accessor('email', {
    header: () => 'Email',
    cell: (info) => info.getValue(),
  }),
  columnHelper.accessor('country', {
    header: () => 'Country',
  }),
  columnHelper.accessor('subscription', {
    header: 'Subscription',
  }),
  columnHelper.accessor('wallet_balance', {
    header: 'Wallet balance',
  }),
];

const Table = () => {
  const [data, _setData] = React.useState([...users]);

  const table = useReactTable({
    data,
    columns,
    getCoreRowModel: getCoreRowModel(),
  });

  return (
    <table>
      <thead>
        {table.getHeaderGroups().map((headerGroup) => (
          <tr key={headerGroup.id}>
            {headerGroup.headers.map((header) => (
              <th key={header.id}>
                {header.isPlaceholder
                  ? null
                  : flexRender(
                      header.column.columnDef.header,
                      header.getContext()
                    )}
              </th>
            ))}
          </tr>
        ))}
      </thead>
      <tbody>
        {table.getRowModel().rows.map((row) => (
          <tr key={row.id}>
            {row.getVisibleCells().map((cell) => (
              <td key={cell.id}>
                {flexRender(cell.column.columnDef.cell, cell.getContext())}
              </td>
            ))}
          </tr>
        ))}
      </tbody>
    </table>
  );
};

export default Table;

In the code above we have the users data to populate the table. I'm using the createColumnHelper function to create columnHelper which is then used to define an array of columns. These columns decide how data will appear in the table. It creates columns according to the header I have provided. In this case, it is "Name," "Age," "Email," etc. We can customize cell rendering behavior by providing the cell property. If it is not provided then it indicates that the default cell rendering behavior will be used.

The useReactTable hook is used to set up a table component with data and column configurations. This configuration decides how data will be rendered in the table. I'm using table.getHeaderGroups() and table.getRowModel().rows for generating the header and body of the table.

After some styling, the table would look like the below image:

Step 3: Customize Accordingly

You can now start customizing the table according to your needs. You can add search, sorting, pagination, or any other features. TanStack provides the hooks and ease to add all this functionality. You can refer to their official documentation here.

Conclusion

TanStack Table could be a great option for your next project. Its headless UI makes design integration effortless, and its rich feature set makes it simple to create pagination, sorting, filtering, and other features. For further clarity, explore additional examples in the documentation.

Happy coding!

Why Should We Use React For the Front-End?

Arnab Saha — Sat, 18 May 2024 08:15:12 +0000

React JS is a JavaScript library built and maintained by Facebook. React is an efficient, declarative, and flexible open-source JavaScript library for creating simple, fast, and scalable frontends of web applications.

The language used to build React applications is JSX. JSX is basic JavaScript that facilitates HTML quoting and uses the syntax of this HTML tag to make subcomponents.

ReactJS is a stronger framework because of its ability to break down the complex interface and allow users to work on individual components.

ReactJS's core objective is to deliver the best rendering performance possible. Its strength stems from the emphasis on individual parts. ReactJS helps developers break down the complicated UI into smaller components, rather than operating on the entire web framework.

Key Benefits of React JS for Front-End Development

React JS offers tons of benefits. Let’s see the key benefits of React JS to understand why it stands out from other front-end JavaScript development frameworks.

Speed

React allows developers to utilize individual parts of their application on both the client-side and the server-side, which ultimately boosts the speed of the development process.

In simple terms, different developers can write individual parts and all changes made won’t affect the logic of the application.

Flexibility

Compared to other front-end frameworks, the React code is easier to maintain and is flexible due to its modular structure. This flexibility, in turn, saves a huge amount of time and cost for businesses.

Performance

React JS was designed to provide high performance in mind. The core of the framework offers a virtual DOM program and server-side rendering, which makes complex apps run extremely fast.

Usability

Deploying React is fairly easy to accomplish if you have some basic knowledge of JavaScript.

In fact, an expert JavaScript developer can easily learn all the ins and outs of the React framework in a matter of a day or two.

Reusable Components

One of the main benefits of using React JS is its potential to reuse components. It saves time for developers as they don’t have to write various codes for the same features. Furthermore, if any changes are made in any particular part, it will not affect other parts of the application.

So, now that you know the key benefits of the React framework, let’s move forward and also check out the top reasons to Choose React JS for your next project.

Why React JS Can Be the Best Choice for Your Project

If you are still not sure whether to choose React JS for your project or not, these reasons will help you make the decision.

Below, I mention the top reasons why React JS can be the best framework for your project.

It helps to build rich user interfaces

Today, the quality of the user interface in an application plays an important role. If the user interface is poorly designed, then it lowers the chances of an application to succeed.

But, if an application has a high-quality UI, then there are better chances that your users will love to use the app.

Therefore, building rich user interfaces is sort of necessary for an application to survive and thrive.

The good news is that React allows building such high-quality, rich user interfaces through its declarative components, which brings us to our next point.

It allows writing custom components

React comes with JSX, an optional syntax extension, which makes it possible to write your own components.

These components accept HTML quoting and also make all subcomponent rendering a delightful experience for developers.

Though there have been many debates on the matter of JSX, it has already for writing custom components, building high-volume applications, and converting HTML mockups into ReactElement trees.

Not only this but after creating components developers can reuse them in the whole app as components are highly customizable, and due to this it speeds up the development process.

It uplifts developers’ productivity

Frequent updates often turn into headaches when an app has complex logic and when a single modification in one component can dramatically affect other components.

But, to combat this problem, Facebook has amplified React with the component reusability feature.

Component reusability in React basically allows developers to redeploy the same digital objects.

The process is simple too! – developers, for example, can begin adding simple components such as buttons, text fields, and checkboxes and then move them to wrapper components, which are ultimately moved forward to the root component.

This approach provides better code maintenance and growth as each component in React has its own internal logic, which is easy to manipulate and as a result, boosts the productivity of application development.

It offers fast rendering

When you’re building a complex, high-load app, it becomes mandatory to define the structure of the app in the beginning since it can impact the performance of your app.

In simple words, the DOM model is tree-structured. So, a minor modification at a higher level layer can awfully impact the user interface of an application. To solve this, Facebook has introduced a virtual DOM feature.

Virtual DOM, as the name suggests, is the virtual representation of DOM that allows testing all changes to the virtual DOM first to calculate risks with each modification.

This approach, as a result, helps to maintain high app performance and guarantees a better user experience.

It comes with useful developer toolset

Learning emerging technologies and using them in real-life projects can be both fun and beneficial, but only if they are used correctly.

Facebook understands this, and it’s for this reason they have added much-needed React dev tools and Chrome dev tools to their React JS framework.

These React tools help developers discover child and parent components, observe component hierarchies, and inspect components’ present state and props.

Strong community support

One of the biggest reasons why you should choose React for front-end development is that it has very strong community support. A large community of React developers is making it better as it’s an open-source library and coders from around the world are helping people learn the technology in different ways.

ToolKit support

In the market there bunch of toolkits are available that can be used to start the upper level of development directly as the toolkit contains provides bundle of configuration and code of boilerplate.

Final Thoughts

Actually, one of the reasons why I believe React is better than other frameworks is that it has a larger community support and, great development tooling and it has tons of different libraries for every use case. Also, I should mention that React has maintained a much more stable API compared to Angular and Vue at this juncture.

From my perspective, these things make React the best choice for enterprise web application development.

But, React has some trade-offs too. Apart from the advantages of React that were mentioned above, React has some problems too:

Too much boilerplate code to write
Really complicated state management strategies
Too easy to abuse its features and develop applications in a wrong way

Sometimes, it's worth to use React and sometimes it's not. I believe choosing a web app framework depends on the type of project. The framework that fits your project's needs is the perfect choice.