DEV Community: Ritanjit Das

posted after a long time !

Ritanjit Das — Thu, 28 May 2026 05:19:46 +0000

Ritanjit Das

May 28

I Got Tired of LeetCode Trackers Selling My Data, So I Built My Own.

#opensource #extensions #webdev #productivity

Comments

6 min read

I Got Tired of LeetCode Trackers Selling My Data, So I Built My Own.

Ritanjit Das — Thu, 28 May 2026 05:15:45 +0000

> "Your coding journey is personal. Your data should be too."

The Problem Nobody Talks About

Here's a question: when you solve a LeetCode problem at 2 AM, who else knows about it?

If you're using any of the popular LeetCode tracking tools, the answer is... a lot of people. Your solve history, your weak topics, your streak data, your pacing before interviews — all of it sitting on someone else's server, probably being used to "improve the product" (read: train models, sell insights, serve ads).

I was using three different tools to track my DSA progress. One required a Google login. Another synced to "the cloud" with no option to export. The third one just... disappeared one day. Along with six months of my progress data.

That was my breaking point.

What If Your LeetCode Tracker Was Just... Yours?

I started building My DSA Buddy — a LeetCode dashboard that runs entirely on localhost. No accounts. No cloud. No telemetry. Your data lives in a SQLite file on your machine, and the only network request that ever leaves is pushing your solution to your own GitHub repo.

That's it. That's the entire privacy model.

External network calls: 1 (GitHub push to YOUR repo)
Data stored remotely: 0 bytes
Analytics/tracking: none
Third-party dependencies on user data: zero

How It Works

The system has two parts that talk to each other locally:

A local web dashboard (Astro 5 + React 19) running on localhost:4321
A Chrome extension that silently detects "Accepted" submissions on LeetCode

When you solve a problem, the extension scrapes the solution, pushes it to your GitHub, and pings your local dashboard to update your stats. The dashboard never touches the internet.

The Architecture (For the Nerds)

This is a pnpm monorepo with Turborepo orchestration. Here's the sync flow:

┌───────────┐  ┌──────────┐  ┌────────────┐  ┌───────────┐
│ LeetCode  │  │ Content  │  │ Background │  │   Local   │
│ Page DOM  │  │  Script  │  │   Worker   │  │ Dashboard │
└─────┬─────┘  └─────┬────┘  └─────┬──────┘  └─────┬─────┘
      │              │             │               │
      │ "Accepted"   │             │               │
      │─────────────>│             │               │
      │              │ sendMessage │               │
      │              │────────────>│               │
      │              │             │               │
      │              │             │─ GitHub API ─>│(ONLY external call)
      │              │             │  PUT solution │
      │              │             │<─ 201 ────────│
      │              │             │               │
      │              │             │ POST /api/sync│
      │              │             │──────────────>│
      │              │             │               │ Update SQLite
      │              │             │               │ Recalculate stats
      │              │             │<──────────────│ 200 OK

Tech Stack

Layer	Technology	Why
Framework	Astro 5 (SSR, Node adapter)	Island architecture — only hydrate what's interactive
UI	React 19 islands	Component-driven dashboard widgets
Styling	Tailwind CSS v4.0	Utility-first, CSS variables, zero runtime
Database	better-sqlite3	Single file, zero config, fast reads
Data Import	csv-parse	Load company-wise problem lists from CSV
Extension	Vite + CRXJS (Manifest V3)	Modern build tooling for Chrome extensions
Type Safety	TypeScript 5.9 end-to-end	Shared types between dashboard and extension
Monorepo	pnpm workspaces + Turborepo	Shared code, parallel builds, caching
Animations	Motion (Framer Motion)	Smooth widget transitions

The Data Model

Everything lives in a local SQLite database. Here's the core:

CREATE TABLE solved_problems (
  id INTEGER PRIMARY KEY AUTOINCREMENT,
  problem_id INTEGER NOT NULL UNIQUE,
  title TEXT NOT NULL,
  difficulty TEXT NOT NULL CHECK(difficulty IN ('Easy', 'Medium', 'Hard')),
  topics TEXT,          -- JSON array
  companies TEXT,       -- JSON array
  solved_at TEXT NOT NULL,
  language TEXT,
  solution TEXT,
  github_path TEXT
);

CREATE TABLE daily_progress (
  date TEXT PRIMARY KEY,
  problems_solved INTEGER DEFAULT 0,
  time_spent INTEGER DEFAULT 0,
  problem_ids TEXT      -- JSON array
);

No ORM. No migrations server. Just a .db file you can copy, back up, or delete. Your data, your rules.

The Design: A Developer's Journal

I didn't want this to look like another gray SaaS dashboard. I wanted it to feel like opening your personal coding notebook.

The design system is inspired by Claude.com's aesthetic — warm cream canvas, coral accents, serif display typography. But adapted for a developer context:

Cream canvas (#faf9f5) — warm, deliberate, not the cold gray of typical dev tools
Coral accent (#cc785c) — progress bars, streak highlights, solved badges
Dark navy surfaces (#181715) — code blocks, problem cards, stats panels
Cormorant Garamond serif for headlines (the "journal" voice)
JetBrains Mono prominently for stats, IDs, code (the "developer" signal)
Full dark mode with View Transition API circular reveal animation

The result is something that feels like a curated study journal rather than a cluttered analytics tool.

/* The design system in CSS variables */
@theme {
  --color-canvas: #faf9f5;
  --color-primary: #cc785c;
  --color-surface-dark: #181715;
  --color-difficulty-easy: #5db872;
  --color-difficulty-medium: #d4a017;
  --color-difficulty-hard: #c64545;
}

What's Built (And What's Not — Yet)

I believe in being honest. Here's the current state:

Done

Complete design system (CSS variables, dark mode, component classes, animations)
Full TypeScript type definitions (Problem, Roadmap, Progress, Settings, SyncPayload)
Monorepo architecture with shared code between dashboard and extension
Chrome extension skeleton (Manifest V3, content script, background worker, popup)
Base layouts and landing page
Extension-to-dashboard communication protocol

In Progress

Dashboard widgets (ProgressOverview, StreakCalendar, StatsPanel)
SQLite database layer and API routes
Problem list with filters (difficulty, topic, company, status)
Company-wise roadmap cards

Planned

Full Chrome extension DOM extraction (LeetCode scraping)
GitHub push integration
Settings page (PAT config, theme, sync preferences)
Data export/import
Streak tracking and milestone badges

This is where you come in.

Why Open Source This Early?

Because the best open-source projects aren't built by one person in isolation. They're shaped by the community from day one.

I'm releasing this now — architecture solid, design system complete, implementation in progress — because I want contributors who can:

Shape the UX before it's locked in
Bring domain expertise (LeetCode DOM structure, Chrome extension best practices, SQLite optimization)
Challenge my decisions (Should I use Dexie.js instead of better-sqlite3 for the extension? Is Astro the right choice? Should the streak algorithm work differently?)

Good First Issues

If you want to contribute, here are concrete starting points:

Issue	Difficulty	Skills
Build the `ProgressRing` SVG component	Easy	React, SVG
Implement the streak calendar (365-day heatmap)	Medium	React, CSS Grid/SVG
Create the SQLite schema initialization script	Easy	SQL, Node.js
Build the `/api/sync` endpoint	Medium	Astro API routes, better-sqlite3
Implement LeetCode DOM extraction (content script)	Hard	DOM APIs, Chrome Extensions
Add CSV problem list files (Google, Amazon, Meta)	Easy	Data collection
Build the floating navbar with scroll animation	Medium	React, CSS transitions
Dark mode theme toggle with View Transition API	Medium	React, CSS, Web APIs

Questions for the Community

I'd genuinely love feedback on these decisions. Drop a comment if you have thoughts:

1. SQLite vs IndexedDB for the extension's local cache?
Currently the dashboard uses better-sqlite3 (Node.js), but the extension might benefit from IndexedDB (via Dexie.js) for its own local state. Is the complexity worth it, or should the extension just always ping localhost?

2. Is the "single external network call" philosophy too strict?
Right now, GitHub push is the only thing that leaves your machine. But what about optional features like LeetCode API calls for problem metadata, or optional cloud backup? Should these exist as opt-in, or does that dilute the privacy promise?

3. Astro SSR on localhost — overkill?
I chose Astro with the Node adapter for island architecture and server-side data loading. But for a purely local app, would a Vite + React SPA with a separate Express API be simpler? What's your take?

4. What features would make YOU switch from your current tracker?
Seriously — what's the one thing that would make you actually use this daily?

Try It / Contribute

# Clone and run locally
git clone https://github.com/Ritanjit/My_DSA_Buddy.git
cd my-dsa-buddy
pnpm install
pnpm dev

# Dashboard runs on localhost:4321
# Extension builds to apps/chrome-extension/dist/

Links:

GitHub: https://github.com/Ritanjit/My_DSA_Buddy.git
License: MIT
Issues: https://github.com/Ritanjit/My_DSA_Buddy.git/issues

If this resonates with you — if you've ever felt uneasy about where your coding data goes — give it a star. Or better yet, pick an issue and submit a PR. The architecture is ready. The design system is ready. We just need builders.

"Privacy isn't a feature. It's a right. Your DSA journey shouldn't require surrendering it."

Thanks for reading. Whether you contribute code, drop a suggestion in the comments, or just star the repo — it all helps. Let's build something that respects developers' data by default, not as an afterthought.

Happy grinding, and even happier data ownership.

Built with Astro 5, React 19, TypeScript, Tailwind CSS v4.0, better-sqlite3, and a healthy distrust of "free" cloud services.

First blog post :)

Ritanjit Das — Sat, 30 Aug 2025 10:16:17 +0000

Ritanjit Das

Aug 28 '25

From HTML to 3D: Why I Rebuild My Portfolio with React, Vite, Tailwind & FrontQL

#webdev #react #typescript #portfolio

Comments 4

6 min read

From HTML to 3D: Why I Rebuild My Portfolio with React, Vite, Tailwind & FrontQL

Ritanjit Das — Thu, 28 Aug 2025 13:12:16 +0000

“A portfolio isn’t just a website. It’s your story, your brand, your invitation to connect.” – Every web developer ever (including me)

Introduction: Why I Rebuilt My Portfolio from Scratch

Back in early 2022, my developer journey started with a humble, single-page website: a few lines of HTML, home-baked CSS, and a hint of JavaScript. I hosted it on GitHub Pages at RD's Portfolio. It did the job: showcasing projects, sharing my bio, and providing a contact method. But as my skills (and ambitions) grew, the limitations of this static site became glaringly obvious.

Fast forward to 2025. I rebuilt my personal site from the ground up as a 3D, interactive experience Aetheria. This wasn’t just a “glow up” for my developer identity. It’s a testament to how modern web technologies like React, Vite, TypeScript, Tailwind CSS v4.0, Three.js (via React Three Fiber), FrontQL, and even vanilla CSS can unlock new creative and functional possibilities.

In this post, you’ll trace my journey step by step, see how and why my development stack evolved, and get a walkthrough of my new portfolio with code and design insights.

Ready to go from “static site” to “interactive 3D web presence”? Let’s jump in.

TL;DR

Old Portfolio: Simple HTML/CSS/JS; hosted free on GitHub Pages. Easy to launch, but limited in interactivity and maintainability.

New Portfolio: Built as a serverless React app (Vite, TypeScript, Tailwind CSS v4.0 + vanilla CSS, 3D via Three.js/React Three Fiber) with dynamic content (FrontQL API for backendless queries). Deployed on Vercel for instant updates and global speed.

Key Takeaway: Embracing modern web tools let me tell my story with richer visuals, better UX, and easier site management.

Why Level Up? My Motivation to Move Beyond Static HTML Portfolio Sites

My original GitHub Pages site taught me the fundamentals:

Hosting a free site: No servers or credit cards. Just push to github pages branch and my site was live.
Using core web skills: HTML for structure, CSS for style, and a few lines of JavaScript for interactions.

But after a year in the web industry, I wanted more...

Efficiency: Repeating HTML for every new project or experience became a chore. Changing a color or font meant hunting through raw CSS.
Type safety & maintainability: I caught myself making silly JS errors—only seeing them in the browser. Refactoring was scary.
Performance: Despite being simple, my site wasn’t optimized, with neither lazy loading nor code splitting.
Modern Interactivity: No dark mode, animations, or dynamic data—unless I hacked it in.

I also noticed that the most impressive portfolios (from several “Best Portfolio” lists) were moving towards interactive, component-driven UIs. Some even included live 3D scenes that made you pause and explore.

The lesson? If you want your portfolio to stand out and “tell your story” not just in words but with explorable design, then there’s a better (and more fun) tech stack.

Where I Started: Anatomy of a GitHub Pages Portfolio

Let’s look at what went right (and wrong) with my v1 portfolio.

The Good

Zero cost: No servers, no surprises.
Markdown-friendly: For beginners, you can even design a simple portfolio in Markdown, as GitHub will serve up your README as a home page.
Accessible: Deploy via Git (push to a branch), visit your .github.io URL, done!

The Limitations

Manual HTML editing: Every update meant diving back into raw code. No components, no templates.
Basic forms: You could add a , but processing submissions required third-party tools (like Formspree) or APIs and more often, nothing happened at all.
No smart data: If my tech stack changed, I had to find-and-replace throughout the site.
No build process: All CSS and JS was loaded, no code splitting or tree shaking.
Limited interaction: Hover effects and toggles? Sure, but no animations, modals, or live 3D magic.

A Look at the Source: Static Portfolio Example

<!-- index.html -->
<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <title>My Portfolio | Ritanjit</title>
  <link rel="stylesheet" href="styles.css">
</head>
<body>
  <header>
    <h1>Ritanjit</h1>
    <nav>
      <a href="#about">About</a>
      <a href="#projects">Projects</a>
      <a href="#experience">Experience</a>
      <a href="#contact">Contact</a>
    </nav>
  </header>
  <section id="about">...</section>
  <section id="projects">...</section>
  <section id="experience">...</section>
  <section id="contact">...</section>
  <footer>© 2023 Ritanjit. Hosted on GitHub Pages.</footer>
  <script src="main.js"></script>
</body>
</html>

Notice: Everything is in one file; “components” are hand-built sections, and updating navigation or content in one place means updating in several files by hand.

Why this stack: Breakdown of the tools I used.

Fast, Fluid & Maintainable - My new stack isn’t just more powerful - it saves time, prevents bugs, supercharges site performance, and makes dynamic features trivial.

Vite: Lightning-Fast Builds & “Just Works” Developer Experience

Why I chose it? Vite is so instant, I’ve forgotten what it’s like to wait on a build.
How its so fast? Vite provides instant local dev server launches, hot module replacement (HMR), and production builds that are significantly smaller/faster than Create React App or Webpack. Fun Fact: In my benchmark, Vite was 58% faster at startup than CRA for a TypeScript + React app.

React + TypeScript: Components, Type Safety, and Happiness

Why TypeScript? Because the future you will thank you for catching typos and bad data before they ship.
With Re-usable components, it means updates or new pages are painless.
Hot reload is delightful, just update a component and see it propagate instantly.

Tailwind CSS v4.0: The Next Evolution of Styling

Why you ask? Because you write less CSS and get more out of every class.
With 3D transforms and container queries, you can animate in 3D, adapt layouts to any container size, and use utilities like rotate-x-*, scale-z-*, @container without using any plugins required.
The cherry on top: Use built-in imports and true CSS variables to share design tokens sitewide.

/* globals.css */
@import "tailwindcss";
@theme {
  --brand-blue: oklch(0.8 0.12 250);
  --header-font: 'Inter', sans-serif;
}
/* 3D rotation: */
.card { @apply rotate-x-12 scale-z-110 transition-all; }

FrontQL: The Serverless Backend Solution

What is it? A revolutionary tech to build Full Stack apps using only frontend tools, with direct SQL access, scalable workflows, and zero backend.
Why? I can insert new contact messages, fetch project data, or even live stats by using SQL directly in the frontend, without requiring my own backend.
Is it Secure? With role-based access and declarative rules, it ensures proper permission management and abstraction of backend operations like scaling and authentication.

async function getUsers() {
  const response = await Api.sql("/users", {
    body: {
      sql: "SELECT * FROM users WHERE id=?",
      params: ["{id}"],
    },
    session:
      "eyJIkpXVCJ9.eyJpZN30.8q8fdsKs9...",
  });

  return response;
}

Three.js and React Three Fiber: Bringing Your Story to Life

“Nothing says ‘future-proof’ like a 3D hero section that is responsive to both desktop and mobile screens.”

Three.js renders real-time 3D graphics, but what truly unlocked productivity was React Three Fiber (R3F), a renderer that makes 3D just another React component.

Usage: Hero section, project previews, 3D globe, or interactive timeline animations.

Performance: Lazy loaded and tuned for devices. R3F makes it easy to display a static fallback if WebGL isn’t supported (progressive enhancement).

Code Structure Example:

// Inside Hero3D.tsx
<Canvas>
  <ambientLight />
  <MyAnimatedModel />
  <OrbitControls />
</Canvas>

Final Takeaways & Advice

If your site feels hard to update, or can’t express your new ideas, that’s a signal to modernize.
Don’t be intimidated by the latest tools. Vite, React, Tailwind v4.0, and FrontQL are actually simpler (and safer) than the jQuery/DOM setup I started with.
Lean on utility-first CSS and component-driven UI to maximize creativity and speed.
Start small, iterate fast and document your milestones with others, not in code, but in design and the storytelling. The feedback will both inspire and shape your next version.

Thanks for reading! I hope my journey inspires your next leap, whether it’s a single Tailwind utility, a React hook, or your first spinning cube on the web.

Happy building and even happier storytelling :)