DEV Community: MD Masud Ur Rahman

I’m done building CRUD apps. It’s time to learn real systems engineering.

MD Masud Ur Rahman — Wed, 12 Aug 2026 05:08:27 +0000

I recently wrapped up a project idea for my university (CampusCare) I got from a friend. I managed to get the setup and initialization running pretty quickly by adapting the foundation from a previous app I built (FrontDesk).

Everything was going fine, but I ran into a couple of weird edge cases I hadn't faced before:

The Supabase RLS Infinite Loop: I hit a wall with Row Level Security recursion and had to figure out how to use SECURITY DEFINER helper functions to execute queries as the database owner without crashing the database.

Zod UUID Strictness: I got totally blocked by a silent validation error. It turns out Zod's .uuid() method strictly enforces RFC 4122 rules (requiring specific characters at the 14th/17th position), which was silently dropping my form inputs before they even hit the server.

Those two bugs were the only actual new things I learned. The rest was just the exact same CRUD, multi-tenant boilerplate.

Even though I knocked the project out in about a day (admittedly using AI to do the heavy lifting for the UI/UX), it honestly wasn't fun.

I came back from university today and had a realization: building an e-commerce app next would lead me absolutely nowhere. It would just be the exact same framework magic with a shopping cart attached. I’d be typing the same Next.js routes and Supabase queries, and learning very little.

My goal right now needs to be depth, not quantity.

So, I'm pivoting. I sat down, and mapped out a massive 52-week roadmap to completely push myself out of this framework fatigue. It’s a complete guide to understanding low-level systems engineering—going from how a computer actually processes memory, down to raw TCP/IP networking, headless Go APIs, raw PostgreSQL, and Docker deployment.

I’ll be logging my progress every single day. I find this kind of raw learning genuinely exhilarating right now, and the drive to do this is definitely a blessing from my Creator.

So yeah, no more shallow, full-stack CRUD apps for a while. It’s time to go deep.

I’ll drop in here occasionally to post anything interesting I figure out along the way. If you want to follow along or critique the path, here is the GitHub repository where I'll be tracking everything:

👉 Road to Complete Backend (GitHub)

I Tried to Build Monkeytype to Learn React. It Nearly Broke Me.

MD Masud Ur Rahman — Sun, 09 Aug 2026 11:27:12 +0000

I got off FrontDesk not satisfied with its UI/UX, and figured: FrontDesk already taught me some things, so why not build something frontend-heavy and actually learn useRef, useMemo, rendering, and state management properly this time.

Back in early college, I'd built a simple typing checker: a plain <textarea> where typing checked against the target word and swapped CSS classes. Very simple. This time, with more knowledge and AI tools to ask for help and explain things along the way, I figured I'd rebuild it properly as a retro RobCo CRT terminal app: Typedesk.

I was completely blown away by how miserable the experience got.

1. Where It Worked: Modules 1 & 2

Up through Module 2 (Setup, Design System & Event Architecture), I could actually keep up and understand what was happening.

I set up localStorage persistence, built useLocalStorage and useThemeSwitcher hooks, and put together a 5-theme CRT design system (FALLOUT green, WYSE amber, RADAR emerald, CODEX parchment, CYBER hot magenta).

I was tracking every decision:

Managing root [data-theme="..."] CSS custom properties on <html> as the single source of truth, so theme switches bypassed React's Virtual DOM diffing entirely.
Writing an anti-FOUT hydration script to kill theme flashes on load.
Using a render-phase state-adjustment pattern to update state during render instead of chasing cascading useEffect re-renders.

I was thinking, "okay, I'll drop a useMemo here and there" - everything felt under control.

The 5-theme CRT switcher: Fallout Green, Wyse Amber, Cold War Radar, Monastic Codex, Cyberpunk Edo.

2. The Wall: Module 3 (Hot-Path Rendering & Caret Math)

Then I hit Module 3: Hot-Path Rendering & Caret Math. That's where the typing engine came in, and I got completely floored.

My god. Both Gemini and Claude started hallucinating and couldn't figure it out. Forget teaching me best practices—they couldn't even implement a working approach once React's Virtual DOM state loops got mixed with monospace caret pixel math. One prompt would fix caret drift but break line wrapping; the next would fix wrapping and trigger infinite re-renders instead.

The caret math wasn't just "move right after each character." I had to calculate the exact pixel width of every character across different monitors, handle monospace line-breaking, sync it with CSS transitions, and run a high-precision performance.now() monotonic timer on top of all of it.

It felt more like designing an operating system than building a website. Like, damn.

I was in a rush, so I thought: fuck it, let's push. I pushed again, and again, juggling prompts from here and there. The sheer complexity was unfathomable to me: how does a typing engine website get this fucking hard and require this much goddamn complexity?

I just gave up. Understood: React just ain't it, man.

3. The Reframe: Turns Out I Was Half Right

My gut reaction at the time was blunt: React just isn't it for this. Turns out I was half right.

I checked how the actual Monkeytype is built. Monkeytype uses no framework at all: plain vanilla TypeScript, direct DOM manipulation, no Virtual DOM, no state reconciliation.

The caret coordinate math is inherent to any real-time positioned-cursor UI: that part was never React's fault. But wrapping high-frequency keydown events (10+ per second) inside React's rendering model (useState, useRef, referential equality, component re-renders) piled a whole extra layer of state-management hell on top of an already hard problem.

The real takeaway: match your stack to the problem, not the other way around. Don't take on a rendering-engine-grade problem and a new framework's mental model at the exact same time.

4. What's Next

The idea itself was solid, and I actually pulled it off with AI's help. It's the optimization layer, the React re-render chasing, the state-management spiral, where I hit the wall.

Despite that, Typedesk is finished, responsive, and deployed:

🚀 Live Demo: https://shoytanbaba99.github.io/typedesk/
📦 Typedesk GitHub Repo: https://github.com/Shoytanbaba99/typedesk
🔗 Monkeytype Source Code: https://github.com/monkeytypegame/monkeytype

Next up: something more bearable. Got a college assignment, asked a friend for ideas, and he said: "just build a complaint management system, just pass, man." Fair enough.

That's the next target, back to CRUD, forms, and state transitions, where I can actually hold the whole thing in my head, and hopefully learn something new instead of just surviving it. Cheers for now.

Escaping Tutorial Hell: Building FrontDesk

MD Masud Ur Rahman — Fri, 07 Aug 2026 21:17:11 +0000

Recently, I decided it was time to step out of tutorial hell and actually build a serious full-stack application from scratch. I wanted to understand how production software is planned, structured, and secured.

That project became FrontDesk, a multi-tenant solo service provider platform. It basically allows freelancers to create a public profile, display their services, and let clients request bookings straight into a private inbox. I built it using Next.js 16 (App Router), Supabase, Zod, and Tailwind CSS.

Here is a breakdown of the mental models I gained, how the security pipeline actually works, and why I am immediately moving on to a new project.

How Real Software Actually Gets Planned

Before this, I did not really know where to start when building a complex web app. Do you build the buttons first? The database?

Through FrontDesk, I finally understood the sequential phases that software goes through. I realized you do not just start writing React components. The flow looks more like this:

Database Schema (DDL): Designing the PostgreSQL tables (profiles, blocks, requests) and foreign keys first.
Auth & Proxy: Setting up HttpOnly session cookies and the Next.js middleware proxy.
Server Actions & Validation: Building the backend mutation logic and parsing inputs with Zod.
Component Assembly: Creating the decoupled React components.
UI/UX Polish: (Which I admittedly kind of skipped... more on that later).

The 4-Layer Defense-in-Depth Funnel

My biggest takeaway was learning that modern web security is not just a single if (user) check. It is a multi-stage defense funnel.

If someone tries to submit a form on FrontDesk, here is the exact pipeline their data has to survive:

Client-Side Validation (Zod): Catching typos and malformed types before a network request is even sent.
Middleware Proxy Session Check: Verifying the HttpOnly cookie and refreshing the auth state securely.
Server Action Validation: Re-running Zod checks on the server because client-side validation can always be bypassed.
Database Row Level Security (RLS): PostgreSQL policies ensuring the authenticated user actually owns the target resource.

The Supabase Abstraction Realization

Supabase is an amazing BaaS (Backend as a Service). It abstracts away a lot of heavy backend complexity.

Initially, the architecture looked pretty overwhelming, but eventually, the mental model clicked. I realized that while Supabase handled the connection pooling, the JWT signing, and the background refresh tokens, I still had to architect the application logic. I had to manually manage session redirection, set up the Edge proxy, and write the Row Level Security (RLS) policies in PostgreSQL so that users could only mutate their own data.

The "Ugly UI" Confession & What is Next

So, here is the truth about the frontend: the default UI of FrontDesk is highly minimal.

I spent so much mental energy focusing on the backend pipeline, the security layers, and the database schema that I intentionally kept the UI generic. However, the beauty of the platform is that it is entirely data-driven. The interface comes to life once a user customizes it, uploading custom avatars, injecting their own hex accent colors, and populating service blocks with dynamic cover images. It’s a functional, workable canvas.

Still, wrestling with the backend architecture was exhausting, and honestly? I need a palate cleanser.

I want to dive deep into frontend-heavy, client-side state management without worrying about database schemas or RLS for a minute. So, my next project is going to be TypeDesk, a completely sanitized, SPA speed-typing website (like Monkeytype) with a retro terminal aesthetic. I'm going to focus entirely on high-frequency UI updates, requestAnimationFrame, and hyper-optimized React rendering.

I'll write about that once it's done. Until then, you can check out the FrontDesk repo [here].

Pretty crazy journey so far, ig ;3

🚨 UPDATE: Security Post-Mortem (Application-Layer Rate Limiting)

So, after publishing this post, a code review pointed out a massive blind spot I completely missed regarding public write endpoints.

Sure, RLS handles who can touch a table, and Vercel/Supabase stop basic network DDoS attacks. But PostgREST doesn't know anything about custom business logic for my requests table. Left unchecked, a basic script could just spam my booking form in a loop and fill my database with garbage data until storage blows up.

The Fix: Before a form submission even sniffs the database, the Next.js Server Action has to hit an IP rate-limiter (like an Upstash Redis sliding window) to cap public submissions, keeping it locked to something sensible like 3 requests per minute per IP.

How Node.js Actually Works (A Beginner's Mental Model)

MD Masud Ur Rahman — Thu, 06 Aug 2026 13:30:42 +0000

Recently, I went down a rabbit hole trying to understand how Node.js handles asynchronous operations under the hood. I took a bunch of notes, refined them to make sense of the chaos, and wanted to share the mental model that finally made it "click" for me. If you are a beginner like me, I hope this helps you too!

What Node.js Actually Is

Node.js is a server-side JavaScript runtime environment. It takes the V8 JavaScript engine (the exact same engine that powers Google Chrome) out of the browser and wraps it in C++ bindings.

This allows JavaScript to break out of the browser sandbox and interact directly with the Operating System, file systems (fs), and network protocols.

How It Executes Code (The Delegation Model)

JavaScript is strictly single-threaded. This means its main execution space (the V8 Call Stack) can only process one operation at a time. To prevent your server from freezing during slow tasks (like querying a database), Node.js uses a delegation architecture:

Encounter & Delegate: When JavaScript hits an operation it cannot execute directly on the main thread (such as reading from disk or fetching from a remote API), V8 immediately delegates that task to Node's underlying C++ background engine (libuv).
Registers & Frees the Stack: Node hands libuv the background task alongside a reference to your callback. V8 finishes executing the initial setup function immediately and pops it off the Call Stack. This frees the main JavaScript thread to instantly handle other users or execute the rest of your script.
Background Work: While JavaScript continues executing code on the main thread, libuv carries out the heavy lifting in the background using OS kernel facilities or a background Worker Thread Pool.
Task Queue Resolution: When libuv finishes the background work, it pushes the completed result along with its callback into the Task Queue.
Resuming Execution: The Event Loop constantly monitors the V8 Call Stack. Once it detects that the Call Stack is completely empty, it picks up the callback from the Task Queue, pushes it back onto the V8 Call Stack, and JavaScript resumes executing the rest of the code.

Visualizing the Flow

Here is a simple architectural map of how V8 and C++ work together:


      [1] JAVASCRIPT CODE
      fs.readFile('data.json', callback) 
               |
               v
  [2] V8 ENGINE (Call Stack)
      - Looks up function in C++ Binding Registry
               |
               v
  [3] C++ BINDING BRIDGE
      - Registers callback with libuv & returns to V8
               |
               +-----------------------------------+
               |                                   |
               v                                   v
  [4] V8 CONTINUES MAIN THREAD            [5] LIBUV (C++ Thread / OS Kernel)
      - Call stack is freed!       - Reads file from physical disk
      - Runs next lines of JS code                 |
                                                   v
                                          [6] TASK COMPLETE
                                    - Pushes result to Task Queue
                                                   |
                                                   v
                                          [7] EVENT LOOP
                               - Detects V8 Call Stack is empty
                        - Moves callback back onto V8 Call Stack

If we write a simple script, we can see this exact delegation happening in real-time:

const fs = require('fs');

console.log("1. V8 runs this immediately on the Call Stack.");

// V8 delegates this to Node (libuv), empties the stack, and moves on! 
fs.readFile('database.json', (err, data) => { console.log("3. The Event Loop pushes this back to V8 when the background work is done."); });

console.log("2. V8 runs this without waiting for the file to finish reading.");

If you run this code, it will always print in this exact sequence:

1. V8 runs this immediately on the Call Stack.

2. V8 runs this without waiting for the file to finish reading.

3. The Event Loop pushes this back to V8 when the background work is done.

The main thread never blocked for a single millisecond!

Pretty cool i guess \+_+/.