DEV Community: Zul Ikram Musaddik Rayat

Building a Transparent Drag-and-Drop Shelf for Windows with Tauri: The Engineering War Stories

Zul Ikram Musaddik Rayat — Wed, 17 Jun 2026 15:17:43 +0000

I recently shipped SnapShelf, a transparent always-on-top "staging shelf" for Windows; you fling files at the right edge of your screen, it slides in, you drop stuff on it, and later you drag that stuff back out into whatever app needs it. Think of it as a temporary holding tray for files, images, text, and URLs while you move things around your desktop.

It's built with Tauri v2 (Rust backend + React/TS frontend). On paper it's a small app. In practice, almost every "small" feature collided with a deep Windows/WebView2 constraint that wasn't in any quickstart. This post is the engineering autopsy: the problems that actually cost me days, and the non-obvious fixes.

If you're building anything that touches native drag-and-drop, transparent windows, or MSIX packaging with Tauri, this'll save you some hair.

The architecture, briefly

One main WebviewWindow. Transparent, undecorated, always-on-top, skipTaskbar.
A Rust polling thread that reads the cursor position every 50ms via the Win32 API and decides when to open/close the shelf.
A small set of atomics as the single source of truth for window state, read lock-free by the poll thread and the IPC commands.
React frontend for the UI; Rust owns all the window-positioning and OS integration.

That sounds clean. Getting there was not.

Challenge 1: WebView2 silently refuses drag-and-drop unless the window was composited before the drag started

This was the big one.

The whole point of the app is dragging files in from Explorer. So naturally my first design was: keep the window hidden (visible: false), and show() it the moment a drag approaches the edge. Clean, no startup flash, minimal resource use.

It did not work. The shelf would slide in, I'd release the file over it, and nothing. No drop event. Ever.

The cause: WebView2 registers its OLE drop target (RegisterDragDrop / IDropTarget) only when the window is first shown and composited by the DWM. If the first show() happens mid-drag, which is exactly my trigger flow, the drop target isn't registered yet when the file is released. The drag silently does nothing.

The fix is counterintuitive: start the window "visible" but parked far off-screen.

// tauri.conf.json
{
  "windows": [
    {
      "label": "main",
      "visible": true,        // MUST be true so WebView2 composites + registers IDropTarget
      "x": -10000,            // but park it off every monitor so nothing flashes
      "transparent": true,
      "decorations": false,
      "alwaysOnTop": true,
      "skipTaskbar": true,
      "dragDropEnabled": true
    }
  ]
}

The window is technically "visible" from the OS's perspective, so WebView2 composites it and registers the drop target at startup, but it's at x: -10000, off every physical monitor, so the user never sees a flash. By the time any drag happens, the drop target has been live for seconds.

Takeaway: "visible" in Tauri config means "composited," not "on a monitor the user can see." For OS drag-drop to work, you need composited-before-drag. Park off-screen instead of hiding.

Challenge 2: dragDropEnabled is ignored if you set it in the Rust builder

Closely related, and a great way to lose an afternoon. Tauri lets you build windows two ways: declaratively in tauri.conf.json, or imperatively with WebviewWindowBuilder in Rust.

There's an open Tauri bug (#13761) where dragDropEnabled only takes effect when the window is declared in tauri.conf.json. Set it on the Rust builder and it's silently dropped; drag events never fire.

So: declare the window (and dragDropEnabled: true) in the config file, not in Rust. This conflicts with a lot of "spawn your window dynamically" advice you'll find, but it's non-negotiable if you need OS drops.

Challenge 3: Never call .hide(), it kills the Acrylic backdrop

I wanted that native Windows 11 Acrylic glass look, applied once at startup:

#[cfg(target_os = "windows")]
{
    use window_vibrancy::{apply_acrylic, apply_mica};
    if apply_acrylic(&win, Some((18, 18, 18, 90))).is_err() {
        let _ = apply_mica(&win, Some(true)); // fallback
    }
}

This works great, until you hide() and show() the window. On show, the Acrylic effect is gone; you're left with a flat or black backdrop, and re-applying it on every show causes visible flicker and DWM recomposition jank.

The fix ties back to Challenge 1: I never call hide() / show() at all. Showing and hiding the shelf is purely set_position; slide it on-screen to reveal, park it off-screen to "hide":

const PARK_X: i32 = -32000; // guaranteed off all monitors

fn do_show_shelf(app: &tauri::AppHandle) {
    let win = app.get_webview_window("main").unwrap();
    let _ = win.set_position(tauri::PhysicalPosition::new(shelf_x(), shelf_y()));
    // emit event so the frontend can play its slide-in transition
}

fn do_hide_shelf(app: &tauri::AppHandle) {
    let win = app.get_webview_window("main").unwrap();
    // emit hide event, then after the CSS transition, park it:
    let _ = win.set_position(tauri::PhysicalPosition::new(PARK_X, 0));
}

The window is always composited and Acrylic is applied once. The user just sees it slide in and out. Bonus: positioning is cheaper than show/hide and never re-triggers vibrancy.

Takeaway: with transparent/vibrancy windows, treat the window as permanently alive. Move it, don't hide it.

Challenge 4: set_focus() breaks the OLE drag you're trying to catch

When the shelf slides in during a drag, my instinct was to set_focus() so it's ready for interaction. Don't. Calling set_focus() on the target window mid-drag disrupts Explorer's DoDragDrop loop; the OLE drag gets interrupted and the drop fails.

This created an interesting design tension: in Tray mode (where the user opens the shelf manually with no active drag) I do want focus so I can auto-close on blur. But in the drag-in path, focus is poison.

I solved it with a per-open "close policy"; the show function takes a policy that decides whether to focus:

static CLOSE_POLICY: AtomicU8 = AtomicU8::new(0);

const CP_CURSOR_PARK: u8 = 0;   // drag-in / hover: close when cursor leaves
const CP_CURSOR_SLIVER: u8 = 1; // tab mode: collapse to a strip
const CP_BLUR: u8 = 2;          // tray mode: close on focus loss
const CP_MANUAL: u8 = 3;        // pinned: only explicit close

fn do_show_shelf(app: &tauri::AppHandle, policy: u8) {
    // position the window...
    CLOSE_POLICY.store(policy, Ordering::Relaxed);
    // set_focus ONLY when there's no active OLE drag to disrupt:
    if policy == CP_BLUR {
        let _ = win.set_focus();
    }
}

The drag-in path passes CP_CURSOR_PARK (never focuses). Tray open passes CP_BLUR (focuses, so the blur handler can close it). One enum, no broken drags.

Challenge 5: I deleted the "edge detector" window entirely and replaced it with a 50ms poll

The textbook way to detect "user dragged something to the screen edge" is a thin, transparent, always-on-top trigger window glued to the edge that listens for drag-enter. I built that first. It worked, but:

It's a second WebView; more RAM, against my under-30MB idle goal.
A click-through (set_ignore_cursor_events) window won't receive OS drag-enter, so it can't be click-through, which means it eats a 2px strip of clicks.
It's another moving part that can race with the main window.

I scrapped it for a single Rust thread polling the Win32 cursor API directly. It owns both open and close decisions, for every mode:

#[cfg(target_os = "windows")]
fn start_drag_edge_poll(app: tauri::AppHandle) {
    use windows_sys::Win32::Foundation::POINT;
    use windows_sys::Win32::UI::Input::KeyboardAndMouse::GetAsyncKeyState;
    use windows_sys::Win32::UI::WindowsAndMessaging::GetCursorPos;

    std::thread::spawn(move || {
        let mut hover_dwell: u8 = 0;
        loop {
            std::thread::sleep(std::time::Duration::from_millis(50));

            let mut pt = POINT { x: 0, y: 0 };
            if unsafe { GetCursorPos(&mut pt) } == 0 { continue; }

            let lbtn_down = unsafe { GetAsyncKeyState(0x01) } as u16 & 0x8000 != 0;

            // Drag-in: left button held + cursor at right edge -> open. Works in every mode.
            if lbtn_down && pt.x >= screen_right() - 30 && in_y_band(pt.y) {
                do_show_shelf(&app, CP_CURSOR_PARK);
            }
            // hover-dwell, tab-strip, and auto-close logic follow...
        }
    });
}

50ms is imperceptible to the user but trivial for the CPU (the thread is asleep 99% of the time). No second webview, no click-eating strip, and all the timing logic lives in one place. The polling-thread-as-state-machine pattern turned out far simpler than coordinating two windows via events.

Challenge 6: Dragging an item out trips your own auto-close

Here's a fun self-inflicted bug. Auto-close fires when the cursor leaves the shelf rectangle. But dragging a file out of the shelf is literally moving the cursor off the shelf, so the shelf would slam shut mid-drag, cancelling the drag-out.

Fixed with a flag that the drag-out command raises for its duration, and which the poll loop's close check respects:

pub static DRAG_OUT_ACTIVE: AtomicBool = AtomicBool::new(false);

#[tauri::command]
pub async fn start_file_drag(app: tauri::AppHandle, paths: Vec<String>) -> Result<(), String> {
    DRAG_OUT_ACTIVE.store(true, Ordering::Relaxed);
    let result = tauri::async_runtime::spawn_blocking(move || {
        drag::start_drag(/* ... */);
    }).await.map_err(|e| e.to_string());
    DRAG_OUT_ACTIVE.store(false, Ordering::Relaxed); // self-clearing after the drag completes
    result
}

And in the poll loop:

if (policy == CP_CURSOR_PARK || policy == CP_CURSOR_SLIVER)
    && !DRAG_OUT_ACTIVE.load(Ordering::Relaxed)   // don't auto-close mid drag-out
    && cursor_outside_shelf_rect(pt)
{
    do_hide_shelf(&app);
}

It's self-cleaning: the flag clears when start_drag returns (after drop), and the next poll tick tidies up if the cursor is now off the shelf.

Challenge 7: Shrinking the binary from 17MB to 5.6MB

The first release build was 17MB. For something that markets itself as "lightweight," that stung. Two big levers:

Cargo release profile. This alone is enormous:

# src-tauri/Cargo.toml
[profile.release]
opt-level = "s"      # optimize for size
lto = true           # link-time optimization
codegen-units = 1    # better optimization, slower compile
strip = true         # strip symbols
panic = "abort"      # drop unwinding machinery

Kill default features on heavy crates. The image crate pulls in decoders for a dozen formats I'll never see in a clipboard shelf:

image = { version = "0.25", default-features = false, features = ["png", "jpeg", "webp", "gif"] }

I also ripped out syntax highlighting entirely. I'd reflexively added Shiki + highlight.js for "code snippet" cards early on; it was about 11MB of the frontend bundle. A clipboard shelf does not need a syntax highlighter. Deleting it took the dist/ from 11MB to 249KB. Sometimes the best optimization is admitting a feature was never needed.

Takeaway: audit your default-features. Most heavy crates pull in things you don't use, and Cargo won't tell you. And question features that drag in megabytes for marginal value.

Challenge 8: A regex that quietly corrupted my MSIX manifest

Last one, and a good "always read the docs for the function signature" lesson.

For Microsoft Store distribution I pack the MSIX myself with a PowerShell script. It patches the Identity Version in the manifest from package.json at pack time. My first version used a regex:

# Intended: replace ONLY the Identity version
$xml = [regex]::Replace($xml, 'Version="\d+\.\d+\.\d+\.\d+"', "Version=""$Version.0""", 1)

Bundling failed with 0x80080215, and worse, I burned an hour blaming MinVersion and platform-targeting before I looked at the actual emitted manifest. The bug: that trailing 1 is not "replace the first match." In .NET's Regex.Replace, that overload's last parameter is RegexOptions, and 1 is the integer value of RegexOptions.IgnoreCase. So it replaced every match.

And MinVersion="10.0.18362.0" contains the substring Version="...". So my "version bumper" was happily rewriting MinVersion to a garbage value, producing an invalid manifest that makeappx rejected with an unhelpful error.

The fix: stop pattern-matching XML, use the XML DOM and target exactly the node I mean:

[xml]$doc = Get-Content $Manifest -Raw -Encoding UTF8
$ns = New-Object Xml.XmlNamespaceManager($doc.NameTable)
$ns.AddNamespace("pkg", "http://schemas.microsoft.com/appx/manifest/foundation/windows10")
$doc.SelectSingleNode("/pkg:Package/pkg:Identity", $ns).SetAttribute("Version", "$Version.0")
$doc.Save($out)

Takeaway: two lessons. (1) Don't regex structured formats when a real parser exists. (2) When a build tool throws a cryptic hex error, inspect its actual input before theorizing about the tool.

What I'd tell my past self

The platform constraints are the product. 80% of the engineering was respecting WebView2/OLE/DWM rules, not writing features.
"Visible" is not the same as "on screen." Park, don't hide.
One state-owning thread beats coordinating multiple windows via events. Fewer races, simpler reasoning.
Tauri's size win is real but not automatic; you still have to tune the release profile and audit features.
Read the function signature. That 1 cost me an afternoon.

The interesting part was always the fight with the platform underneath.

Happy to go deeper on any of these in the comments. The WebView2 drop-target thing especially; if you're hitting "my drop events never fire," I've probably made your exact mistake.

Try it

SnapShelf is free on the Microsoft Store: Get SnapShelf

Works on Windows 10 (22H2) and Windows 11.

How I Built and Launched a 100% Offline AI Productivity Tracker (Tauri 2, Rust, and Llama 3.2)

Zul Ikram Musaddik Rayat — Thu, 11 Jun 2026 04:49:41 +0000

After months of late-night coding, debugging, and wrestling with compiler errors, I finally reached a major milestone: I published my first-ever desktop application to the Microsoft Store. 🎉

The app is called Focus Stream. It tracks how you spend time on your PC and turns it into an AI-generated focus journal. The catch? It runs fully on-device. No accounts, no cloud database, and absolutely no telemetry. Window snapshots, activity timelines, and LLM inference all happen locally.

In this post, I want to share the architecture behind Focus Stream, how I fit a local Large Language Model (LLM) into a lightweight desktop app, and what it took to package and ship it to the Microsoft Store.

The Core Concept: Privacy-First AI

We've all seen the news about cloud-based activity trackers scanning user screens. While productivity tracking is incredibly useful, uploading your screen snapshots, open documents, and active window titles to a third-party server feels like a major privacy risk.

I wanted to build a tool that gives you the power of AI analysis and natural language query over your day, but with zero data leaving your machine.

To make this happen, I designed a local-first architecture:

  [ User Desktop ]
         │
         ▼ (Activity logs & snapshots sampled)
  [ Local SQLite Database ]
         │
         ├───────────────────────────────┐
         ▼                               ▼
  [ React 19 Frontend ] ◄──────── [ Local Llama 3.2 1B ]
  (Visual timeline, trends)     (Local inference via mistral.rs)

The Tech Stack

I chose a stack that balances web-ecosystem UI flexibility with native-performance system hooks:

Layer	Technology
Frontend	React 19, TypeScript, Vite, Recharts, Base UI
Backend	Rust, Tauri 2
Database	SQLite (`tauri-plugin-sql` with WAL enabled)
AI Inference	`mistral.rs` running a quantized Llama 3.2 1B model
Packaging	MSIX (x64 and arm64), Microsoft Store

Deep Dive: Solving the Local LLM Challenge

Running a local LLM inside a desktop application introduces two major hurdles:

How do you keep the installer small? You can't bundle a 1.2 GB GGUF model in the installer without turning away users.
How do you support multiple architectures and hardware setups (CPU vs. GPU)?

Here is how I solved them.

1. The Dynamic DLL & On-Demand Model Download

Instead of compiling the AI inference engine directly into the main binary, I built a modular architecture using compile-time features.

Focus Stream compiles in production with an ai_dll feature flag. The core executable is extremely slim.

First Launch: The app prompts the user to download the Llama 3.2 1B model (~1.2 GB quantized GGUF) directly from Hugging Face into their local app data directory.
Dynamic Linking: At runtime, the app checks the system architecture and dynamically loads the compiled C-compatible DLL (focus_stream_cpu.dll or a future GPU-accelerated equivalent) using the libloading crate in Rust.

// A look at how we dynamically load the inference backend at runtime
pub fn load_backend(path: &Path) -> Result<Box<dyn AIBackend>, Box<dyn Error>> {
    unsafe {
        let lib = libloading::Library::new(path)?;
        let constructor: libloading::Symbol<unsafe extern "C" fn() -> *mut dyn AIBackend> = 
            lib.get(b"create_backend")?;
        Ok(Box::from_raw(constructor()))
    }
}

This keeps the base application installer under 70MB, downloading the heavy LLM weights only when the user is ready.

2. Multi-Architecture CPU Builds (x64 + arm64)

Since Windows runs on both Intel/AMD (x64) and Snapdragon (arm64) architectures, Focus Stream had to support both.

I wrote a PowerShell script that compiles the CPU DLLs targeting both architectures:

# Building the Rust-based CPU backend DLL for ARM64
pwsh src-tauri/scripts/build-cpu-backend.ps1 aarch64-pc-windows-msvc

In our CI/CD pipeline, both the x86_64-pc-windows-msvc and aarch64-pc-windows-msvc DLLs are bundled as resources, ensuring native execution speeds regardless of the processor.

Wrestling with the Microsoft Store & MSIX Packaging

This was my first time packaging a desktop app for the Microsoft Store, and the learning curve was steep. The store requires signing your app package inside a .msix container.

Version Synchronization

To release updates, the Microsoft Store requires a 4-part version structure (e.g., 1.0.0.0) in your XML app manifest, while npm uses SemVer (e.g., 1.0.0).

To avoid manual mistakes, I wrote a Node script (sync-version.mjs) that acts as a single source of truth. When I run pnpm version, the script automatically:

Bumps package.json
Syncs the version to Tauri's config files (tauri.conf.json)
Syncs the cargo version in Cargo.toml
Propagates the version to the XML elements in Package.Store.appxmanifest

CI/CD Automation

Our GitHub Actions pipeline builds both x64 and arm64 MSIX installers, merges them into a single .msixbundle file, and uses the Windows Partner Center API to submit the build directly to the Microsoft Store when a tag is pushed.

Lessons Learned on My First Desktop Launch

Rust is a perfect match for Tauri 2: Writing low-level native logic (like screen capturing, active window polling, and database caching) in Rust is extremely safe and fast, while React lets me build a modern dashboard with ease.
Local AI is highly viable: You don't need a RTX 4090 to run local inference. Llama 3.2 1B runs surprisingly fast on mid-range laptop CPUs using quantization. It's more than capable of summarizing text journals and doing lightweight RAG.
Packaging is 50% of the battle: Building the app is only half the job. Code signing, target architectures, MSIX manifest constraints, and store policy reviews take a significant amount of effort.

What's Next?

Now that the foundation is live on the store, I am working on:

Optional GPU Acceleration: Packaging CUDA-compatible DLLs that automatically load if a user has a dedicated NVIDIA GPU, falling back to CPU if not.
More detailed dashboards: Using recharts to build granular charts tracking productivity trends over months.

Focus Stream is available on the Microsoft Store with a 7-day free trial and a one-time purchase of $9.99 (no subscriptions!). If you are a developer, freelancer, or someone looking to analyze your time privately, I'd love for you to check it out.

apps.microsoft.com

Have you built desktop apps with Tauri 2? Have you experimented with local LLM integration on client machines? Let's discuss in the comments below!

I Bought My Phone, But Android 16 Owns My Data: The Death of Non-Root Access

Zul Ikram Musaddik Rayat — Fri, 05 Jun 2026 06:36:33 +0000

I recently tried to do something that should be the digital equivalent of picking up a rock: copying a single file.

I had a save file (some.save) for a game sitting in the standard /Android/data/com.app/files/saves/ directory. I bought the phone with my own money. It sits in my pocket. But after spending hours throwing everything from Shizuku to WSL at it, I learned a harsh lesson: On Android 16, you don't own your data.

Google’s "Scoped Storage" and aggressive SELinux policies have crossed the line from protecting user privacy to completely trapping power users. If your device isn't rooted, your data is locked in a digital fortress.

Here is the technical breakdown of my descent into Android 16 madness, and how the OS systematically blocked every single advanced workaround I threw at it.

Attempt 1: The Shizuku-Powered File Managers

My first thought was that Scoped Storage was just blocking standard file managers. No problem, right? We have Shizuku, which runs processes via the ADB shell user (UID 2000).

I installed ZArchiver and FV File Explorer, authorized them through Shizuku, and navigated to the /Android/data/com.app/ directory.
Result: Permission Denied / Access Denied.

Android 16 has patched the system-level Java binders. Even with Shizuku privileges, graphical file managers are blinded by the OS security layer.

Attempt 2: Dropping into the Terminal

Fine. If the GUI fails, go to the CLI. I fired up Termux, triggered my Shizuku rish (shell) session, and tried to brute-force a copy.

cp /data/data/com.app/files/saves/some.save /sdcard/Download/

Result: Permission Denied.

Even trying to read the raw text stream using cat /data/data... > /sdcard/... was slapped down. Android 16’s SELinux policy strictly prohibits the shell user from interacting with physical app sandbox directories.

Attempt 3: The `run-as` Illusion

Android has a built-in debugging command designed specifically for this: run-as. It lets the shell assume the permissions of the target application.

run-as com.app cat /data/data/com.app/files/saves/some.save

Result: run-as: package not debuggable: com.app

Because the app's manifest had android:debuggable="false", the OS refused to grant the shell access.

Attempt 4: Modding the APK

If the app isn't debuggable, make it debuggable. I pulled the base APK to my Windows machine, fired up WSL, and used Apktool to decompile it. I injected android:debuggable="true" into the AndroidManifest.xml, rebuilt it, and signed it with a debug keystore.

To avoid signature mismatch errors (which would require uninstalling and losing the save file), I even cloned the app by changing the package name to com.app.debug so I could install it side-by-side and try to push the save file into the clone's directory.
Result: cat: permission denied.

Even pushing data into an open, debuggable clone was blocked by the overarching SELinux filesystem locks.

Attempt 5: The `adb backup` Betrayal

While looking at the decompiled manifest, I noticed a beacon of hope: android:allowBackup="true".

Perfect. I connected my phone to my PC and ran a native ADB backup command via WSL:

adb backup -noapk com.app -f game_data.ab

The prompt appeared on my phone, I clicked "Back up my data," and a file was generated. I used dd, zlib-flate, and tar in WSL to strip the 24-byte Android OS header and unpack it:

dd if=game_data.ab bs=1 skip=24 | zlib-flate -uncompress | tar -xvf -

Result: 525 bytes copied... tar: This does not look like a tar archive.

A 525-byte file means it’s empty. Android 16 introduces an aggressive background security layer that blocks backup streams for side-loaded apps or apps with high SDK restrictions. The OS literally lied—it accepted the backup request, drew the UI prompt, and then silently aborted the stream right after writing the header.

Attempt 6: Forcing the Migration Engine

If adb backup is blocked, maybe the internal migration engine works. I went back into rish to force the device's Backup Manager to dump the local transport payload.

bmgr transport com.android.localtransport/.LocalTransport
bmgr backupnow com.app

Result: backup is not allowed.

Front door, back door, side door—all welded shut.

The Grim Conclusion

After exhausting WSL pipelines, Shizuku shells, Apktool manifesting, and ADB protocols, the reality set in. Google has officially killed non-root app data access.

The rationale is "security." But when I purchase hardware, install an app, generate local data, and am systematically barred from moving a 1MB text file to a backup folder by the operating system, that isn't security. That is captivity.

If a developer doesn't explicitly build an "Export Save" button into their UI, your data will die on that device. For power users and developers, the message from Android 16 is clear: Root your device, or accept that you are just a guest on your own hardware.

Has anyone else hit this wall on Android 16? Are there any obscure binder exploits or PC-side loopbacks left, or is Magisk officially the only way out? Let me know in the comments.

Why I Walked Back from Next.js and RSC to a Plain SPA and a Separate Backend

Zul Ikram Musaddik Rayat — Thu, 21 May 2026 14:04:09 +0000

I've been writing React for a long time, and I want to tell you a story about a round trip. It starts with me being a true believer in Next.js, runs through the era when the App Router and Server Components moved into my house and rearranged the furniture, passes through a couple of genuinely scary security incidents, and ends with me happily back on a boring, well-understood architecture: a single-page app and a separate backend that talk over a plain HTTP boundary.

This isn't a "framework X is dead" hot take. It's a description of how my own thinking changed, and why the thing I reach for in 2026 looks a lot like the thing I would have reached for in 2018... except smarter about the parts that actually matter.

When Next.js was genuinely great

I want to be fair to Next.js, because for a long stretch it earned its reputation.

The Pages Router era was a sweet spot. You had file-based routing that you could explain to a new hire in five minutes. You had getStaticProps and getServerSideProps - two functions, clearly named, with an obvious mental model: one runs at build time, the other runs per request, and everything else is just React. You got code splitting, image optimization, and a dev server that mostly worked. Deploying was a non-event.

The thing I appreciated most was that the boundary between server and client was legible. Data fetching happened in named lifecycle-ish functions at the top of a route. The component tree below them was ordinary client React. I could point at any line of code and tell you which machine it ran on. That legibility is worth more than people realized at the time, and we mostly only noticed it once it was gone.

So when I say I left, understand that I left something I used to love.

Then the App Router and Server Components moved in

The App Router and React Server Components were pitched as the next evolution, and on paper the pitch is seductive: render components on the server, ship less JavaScript, colocate data fetching with the component that needs it, stream HTML to the browser as it becomes ready. Who doesn't want less JS and faster paint?

In practice, here is what I actually experienced.

The mental model fractured. Suddenly every file was either a Server Component or a Client Component, the distinction was load-bearing, and the boundary was declared with a "use client" string at the top of a file. That directive is viral in one direction and silent about it. A component that was fine yesterday breaks today because something three levels up crossed the boundary, and the error you get is rarely "you crossed a boundary"; it's a serialization complaint, or a hydration mismatch, or a hook being called somewhere it can't be.

"It works in dev" stopped meaning anything. Caching behavior between next dev, next build && next start, and the production edge deployment diverged enough that I stopped trusting local results. I had bugs that only existed in the production cache. I had stale data that no revalidate value seemed to fix. I learned more about the Next.js caching layers than I ever wanted to, and the reward for that knowledge was a permanent low-grade anxiety about whether any given page was actually fresh.

The server/client boundary stopped being legible. This is the one that really got me. The thing I loved most about the Pages era, being able to look at code and know where it ran, was exactly the thing RSC took away. Data fetching is now scattered through the tree. async components look like normal components but aren't. The boundary is real and consequential but invisible at the call site.

None of these are unfixable in isolation. Together they meant I was spending a large fraction of my time fighting the framework's model instead of building the product. That's the signal I should have read sooner.

Then the security incidents made it concrete

Architectural friction is a judgment call. Security incidents are not, and a run of them turned my vague unease into a decision.

It started with CVE-2025-29927, the middleware authorization bypass disclosed in March 2025 at CVSS 9.1. The mechanism was almost embarrassingly simple: Next.js used the internal header x-middleware-subrequest to mark subrequests and prevent infinite middleware loops, but the header was never meant to be client-controlled, and by spoofing it, attackers could skip middleware entirely, auth and authorization included, and reach protected routes with one crafted curl.

If that had been a one-off, I'd have shrugged it off; every framework has bugs. But it wasn't a one-off. The back half of 2025 and the start of 2026 brought a steady drumbeat, and the pattern is what mattered:

CVE-2025-55182 (December 2025) - a React Server Components flaw rated CVSS 10.0, the maximum. It sat in the react-server-dom-* packages and therefore affected every framework built on RSC & Next.js, React Router's RSC APIs, Waku, Parcel's RSC plugin, and the Vite RSC plugin. A perfect score is rare, and this one lived in the RSC machinery itself.
CVE-2026-23864 (January 2026, CVSS 7.5) - a denial-of-service flaw in React Server Components: a malicious payload sent to a Server Function endpoint triggers memory exhaustion or runaway CPU. Patched alongside two more medium-severity Next.js CVEs in the same release.
CVE-2026-23869 and CVE-2026-23870 (early 2026) - more DoS issues in Server Components, triggered by specially crafted HTTP requests to App Router Server Function endpoints that blow up CPU on deserialization. Affected Next.js 13.x through 16.x on the App Router.
CVE-2026-44578 (May 2026, CVSS 7.8) - a server-side request forgery in the self-hosted Next.js Node server: crafted WebSocket upgrade requests let an attacker proxy requests to arbitrary internal destinations, including cloud metadata endpoints.

Look at where these clusters are. A middleware bypass, then a string of Server Component and Server Function flaws, several of them triggered specifically on deserialization of a crafted request. This isn't bad luck distributed randomly across a codebase. The vulnerable surface is the server-rendering and server-function machinery, the exact part of the stack that the App Router and RSC made central. The more your framework does on the server on every request, the more attack surface you have signed up for, and a 10.0 in the shared RSC packages means a single bug ripples across every framework that adopted the model.

What unsettled me wasn't any single CVE... it was what the cluster implied about the architecture. Teams like mine had been quietly nudged to treat middleware as the authorization layer, because in the App Router model, auth-in-middleware is the path of least resistance. The level-headed takeaway in every writeup was the one that stung: middleware should supplement, not replace, security enforced closer to the data. So, I sat with a question: how much of my security posture do I want coupled to a rendering framework's internal request plumbing? My answer was "as little as possible."

The TanStack route - also not a free lunch

When developers get fed up with Next.js, a common next stop is the TanStack ecosystem - TanStack Router and TanStack Start. And I'll be honest: TanStack Router is a genuinely nice piece of engineering. The type-safe routing is best-in-class, the search-param handling is thoughtful, and the data loading is well-considered. If you'd asked me purely about developer experience, I'd have said good things.

But "switch to TanStack" is not the escape hatch some people think it is, and recent history makes that point sharply.

In May 2026, the TanStack npm packages were hit by a supply chain attack. On 11 May 2026, a threat group ran a coordinated supply chain attack against the npm and PyPI ecosystems, compromising packages across multiple namespaces, including the @tanstack namespace, which contains @tanstack/react-router, one of the most widely-used routing libraries in the React ecosystem, with roughly 12 million weekly downloads. Between 19:20 and 19:26 UTC on a single Monday, the attacker published 84 malicious versions across 42 TanStack packages.

The payload was not subtle. It targeted CI/CD tokens, cloud credentials across AWS, GCP, and Azure, Kubernetes service accounts, Vault, and registry tokens, and it used stolen npm and GitHub Actions tokens to publish poisoned versions of more packages, functioning as a worm spreading through the npm ecosystem. It also installed a persistent daemon that polled GitHub every 60 seconds, and on detecting token revocation would attempt to run rm -rf on the user's home directory. One detail makes this especially grim: the compromised packages carried valid SLSA Build Level 3 provenance attestations, making it the first documented npm worm to produce validly attested malicious packages because the malicious versions were published through the project's own GitHub Actions release pipeline using hijacked OIDC tokens.

I want to be careful and fair here. This was not a flaw in TanStack Router's code. The attackers got in by forking a TanStack repository on GitHub and submitting a malicious commit under a fabricated identity. The TanStack maintainers responded quickly and communicated well. This could have happened, and has happened, to almost anyone - 2025 saw significant growth in supply chain attacks, and the npm ecosystem, because of its popularity, absorbed a large share of them. The September 2025 Shai-Hulud worm was the first self-propagating worm in the npm ecosystem and affected over 500 packages.

So the lesson I drew from the TanStack incident isn't "TanStack is unsafe." It's the opposite of tribal. The lesson is: no framework choice immunizes you from supply chain risk, and the more of your stack you concentrate into one heavyweight meta-framework, the larger and more attractive a single compromise becomes. Switching framework brand doesn't fix that. Reducing surface area and dependency count does.

The deeper reason full-stack RSC was always going to be hard: serialization

Set the CVEs aside for a moment, because I think there's a more fundamental issue, and it's the one that finally settled my thinking.

The whole promise of Server Components, server actions, and streaming is that the server/client boundary should feel seamless... You just write components and call functions, and the framework figures out what runs where. But a function call across a network is not a function call. The boundary is real, and it is made of serialization.

Everything that crosses from server to client has to be serialized into the RSC payload, streamed, and deserialized. That constraint quietly shapes everything:

You can't pass a function to a Client Component from a Server Component unless it's a server action, because functions don't serialize. So "just pass a callback", the most ordinary thing in React, becomes a boundary decision.
Class instances, Date semantics, Map/Set, anything with methods or identity, all of it has to be flattened to plain data, or it doesn't make the trip cleanly.
Errors that originate on the server are serialized before you see them on the client, so the stack trace you get is often a translation of the real problem rather than the problem itself.
Streaming adds time as a dimension. Components resolve out of order, Suspense boundaries flush independently, and now you're reasoning about the partial states of a tree mid-stream, which is a genuinely harder mental model than "fetch, then render."

This isn't a bug anyone can patch. It's intrinsic. The instant you let a UI tree straddle a network boundary, you have signed up for a distributed-systems problem dressed in component clothing, and serialization is where that problem leaks through. RSC's seamlessness is, to a real degree, a leaky abstraction over an inherently unseamless thing. You can build impressive demos on it. Holding it stable across a large app, a team, and a year of changes is a different sport.

And notice the connection back to that CVE cluster. Several of those 2026 flaws, the Server Function DoS bugs, trigger on deserialization of a crafted request. That is not a coincidence. Deserializing untrusted input into a live program is one of the oldest, most dangerous operations in computing, and the RSC model puts a deserialization boundary on the hot path of ordinary feature work. The architecture didn't just make my app harder to reason about; it made the framework itself a richer target. Serialization is both the ergonomic tax and the security surface, the same seam, charged twice.

Once I framed it that way, my decision basically made itself. I don't want my UI framework and my data boundary fused. I want the network boundary to be explicit, visible, and boring, a place I deliberately walk up to, not a seam hidden inside my component tree.

The stack I actually use now

So here's where I landed. None of it is exotic. That's the point.

Frontend: React Router in framework mode, on Vite, mostly SPA

I use React Router in its framework mode with Vite. Framework mode gives me the things I genuinely missed from Next.js file-based-ish routing conventions, loaders and actions, nested layouts, type-safe params without forcing a server-rendering model on me.

The crucial part: I don't run SSR. A handful of pages that are truly static marketing, docs, and the landing page get prerendered at build time, so they ship as fast static HTML and are friendly to crawlers. Everything else is a plain client-rendered SPA.

People will say, "But SPAs are slow/bad for SEO / out of fashion." For an authenticated application, a dashboard, a tool, or a product behind a login, almost none of that critique applies. There's nothing for Google to index behind the login wall. The first paint is a thin shell, the bundle is code-split per route, and from then on, navigation is instant because it's all client-side. I get a build artifact that is just static files. I can put it on any CDN or object store. There is no server-rendering process to keep alive, patch, scale, or get a CVE in. The deployment story is "upload a folder," and the security surface of the frontend collapses to almost nothing.

And critically: there is no serialization boundary inside my UI. The component tree runs entirely in the browser. It talks to the backend through fetch, against an API I designed on purpose. The boundary is visible in the code, at exactly the lines where it exists.

Here's what that looks like in practice. A route loads its data in a clientLoader which, despite living in a framework-mode route file, runs entirely in the browser and just calls my API:

// app/routes/projects.tsx
import type { Route } from "./+types/projects";
import { api } from "~/lib/api-client";

export async function clientLoader({ params }: Route.ClientLoaderArgs) {
  // Runs in the browser. No server. Just an HTTP call to my backend.
  const projects = await api.projects.$get();
  if (!projects.ok) throw new Response("Failed to load", { status: 502 });
  return { projects: await projects.json() };
}

export default function Projects({ loaderData }: Route.ComponentProps) {
  return (
    <ul>
      {loaderData.projects.map((p) => (
        <li key={p.id}>{p.name}</li>
      ))}
    </ul>
  );
}

There's no loader (server) here at all, only clientLoader. The seam is the api.projects.$get() call, and I can point at it. Auth is enforced the same way, with a clientMiddleware that runs before the loaders on protected routes:

// app/routes/dashboard.tsx - a protected layout route
import { redirect } from "react-router";
import type { Route } from "./+types/dashboard";
import { api } from "~/lib/api-client";

export const clientMiddleware: Route.ClientMiddlewareFunction[] = [
  async ({ context }) => {
    const res = await api.auth.me.$get();
    if (!res.ok) throw redirect("/login");
    context.set(userContext, await res.json());
  },
];

But notice what this middleware is not: it is not my security boundary. It's a UX convenience; it bounces an unauthenticated user to the login screen so they don't stare at a broken page. If someone skips it entirely, they gain nothing, because every API endpoint enforces auth itself, server-side, on every request. This is the whole lesson of CVE-2025-29927 applied: client-side middleware is for experience, never for enforcement. The frontend can't bypass a check that the backend owns.

The backend side of that contract, in Hono, is explicit and inspectable:

// server/index.ts
import { Hono } from "hono";
import { cors } from "hono/cors";
import { csrf } from "hono/csrf";
import { authMiddleware } from "./auth";

const app = new Hono();

app.use("*", cors({ origin: ["https://app.example.com"], credentials: true }));
app.use("*", csrf({ origin: ["https://app.example.com"] }));

// Real enforcement: the API itself rejects unauthenticated requests.
const projects = new Hono()
  .use("*", authMiddleware)
  .get("/", async (c) => {
    const user = c.get("user"); // set by authMiddleware, trusted here
    return c.json(await db.projectsForUser(user.id));
  });

const routes = app.route("/projects", projects).route("/auth", authRoutes);
export type AppType = typeof routes; // <- exported for the frontend

That last line is the only reason I reach for Hono specifically. Exporting AppType lets the frontend build a fully typed client with no codegen step and no shared runtime:

// app/lib/api-client.ts
import { hc } from "hono/client";
import type { AppType } from "../../server";

// `api` is end-to-end typed against the backend routes.
export const api = hc<AppType>("/api", { init: { credentials: "include" } });

If the backend changes a route's shape, the frontend stops compiling. That's the type safety people credit good Next.js setups with, and I keep it without fusing the two halves into one runtime. Swap Hono for Go or Python, and I lose only this typed-client convenience; the architecture is unchanged, because the contract is just HTTP.

For data that loads after the initial render, a slow widget on an otherwise-ready page, I reach for Suspense and the use hook. This is the one genuinely good idea from the streaming era, and the nice part is it works perfectly well in a plain SPA, with no server rendering involved:

import { Suspense, use } from "react";
import { api } from "~/lib/api-client";

// Kick off the request; do NOT await it. `use` will suspend on the promise.
function ActivityFeed({ feedPromise }: { feedPromise: Promise<Activity[]> }) {
  const activity = use(feedPromise); // suspends until resolved
  return <Feed items={activity} />;
}

export default function Dashboard() {
  // Promise created during render, in the browser. No RSC payload.
  const feedPromise = useMemo(() => api.activity.$get().then((r) => r.json()), []);
  return (
    <>
      <Header />
      <Suspense fallback={<FeedSkeleton />}>
        <ActivityFeed feedPromise={feedPromise} />
      </Suspense>
    </>
  );
}

Same Suspense, same use, same streaming-feel UX of content arriving progressively, but the promise is an ordinary fetch resolving in the browser, not a chunk of a serialized server tree. There's no out-of-order flush to reason about, no hydration boundary, no payload format. I got the ergonomic win of the streaming era and left behind the serialized-tree machinery that came bundled with it.

Backend: a separate service - Hono if I want TypeScript

The backend is its own thing, deployed, scaled, and reasoned about independently. Right now, I mostly reach for Hono, because it's small, fast, runs anywhere from Node to workers to Bun, and lets me keep TypeScript end to end. With Hono, I can share types between client and server and even get a typed client, so I lose none of the type safety that good Next.js setups gave me.

But, and this matters the backend doesn't have to be JavaScript at all. It could just as easily be Go or Python. The reason that's now a free choice is precisely the serialization point from earlier: when your frontend is an SPA talking to an API over plain HTTP and JSON, there is no RSC payload, no server-action boundary, no shared-component-tree contract that forces both sides to be the same language. The contract is just HTTP. Go is fantastic for a backend. Python is fantastic for a backend. I use Hono specifically and only when I want the TypeScript type-sharing convenience; it's a preference, not a requirement. The architecture itself is language-agnostic, and that flexibility is a feature I gave myself by removing the fused boundary.

Security lives in the backend, on purpose

This is the part I care about most, and it's the direct lesson of CVE-2025-29927. Authorization and security are the backend's job, enforced at the API layer, every request, no exceptions. Not in framework middleware. Not coupled to a renderer's internal request plumbing. In the service that owns the data.

Concretely, on the backend, I run:

Authentication as a real, deliberate layer of sessions or tokens, validated server-side on every protected request. The server, which owns the database, decides what you can see. The frontend is never trusted to enforce this; it only reflects it.
CORS configured tightly - an explicit allowlist of origins, not a wildcard, so the browser only lets my actual frontend talk to the API.
CSRF protection - since a SPA-plus-API setup often uses cookies, I use proper anti-CSRF tokens and/or SameSite cookie attributes so a malicious site can't ride a logged-in user's session.
CAPTCHA on the abuse-prone endpoints, signup, login, password reset, public form submissions to keep bots and credential-stuffing out.
Plus the usual unglamorous hygiene: rate limiting, strict input validation at the API edge, security headers, secrets kept out of the client bundle, and least-privilege everywhere.

Every one of these is something I configure and can point at. There's no invisible header that flips my auth off, because my auth was never a header; it's a checked condition in the request handler that sits between the attacker and the database. If someone bypasses a routing layer, they hit the API, and the API still says no.

What I actually gained

Stepping back, here's the trade I made and why I'm happy with it.

I gave up: server-rendered dynamic pages out of the box, and the "it's all one project" convenience of a meta-framework.

I got back, in exchange:

A legible architecture. I can point at any line and say which machine it runs on. The network boundary is one explicit place where the API, instead of being smeared invisibly through a component tree.
No serialization tax. The UI tree lives entirely in the browser. No RSC payload, no server-action plumbing, no streaming-order puzzles.
A tiny frontend attack surface. Static files on a CDN. Nothing to keep running, nothing to patch, no Server Functions to send crafted payloads at, nothing to catch the next 10.0 in the RSC packages.
Security I can see. Auth, CORS, CSRF, CAPTCHA, and rate limiting all live in one service, enforced per request, decoupled from any renderer.
Backend freedom. Hono today for the TypeScript ergonomics; Go or Python tomorrow if a project wants them. The HTTP contract doesn't care.
Smaller blast radius. Two modest, separately-updated pieces with fewer heavyweight dependencies, instead of one large meta-framework whose single compromise is a very attractive target.

So, is Next.js bad? Is TanStack bad?

No. I want to end honestly, because tribal blog posts age badly.

Next.js and TanStack are both serious, well-engineered projects built by talented people. The CVEs and the supply chain attack I described are real and worth knowing about, but the CVEs got patched, and the TanStack incident was an account-and-pipeline compromise that could have hit almost any popular package. If your product genuinely needs server rendering for SEO on dynamic content, or you have a content-heavy site where streaming pays for itself, a meta-framework can absolutely be the right call. Plenty of teams ship great things on exactly the stack I walked away from.

My point is narrower and more personal. For the apps I build, authenticated products where the UI is interactive and the data is the crown jewels, the full-stack RSC model added a serialization-shaped boundary I didn't want, hid the seam I most needed to see, and nudged my security toward the framework's plumbing instead of my own backend. A SPA plus a separate, well-secured backend gave me a smaller, more legible, more boring system. And in software, boring is usually a compliment.

That's the round trip. I left, I looked around, and I came back to a plain SPA and a real backend, older ideas, held with sharper reasons.

Email Verification with Better-Auth (Basics Tutorial, Ep. 2)

Zul Ikram Musaddik Rayat — Sun, 21 Sep 2025 16:27:58 +0000

Welcome back to the Better-Auth Basics series! 🚀

In Episode 1, we set up Better-Auth with Drizzle ORM and implemented sign-up and login functionality. It worked great… but there’s a big flaw:

👉 Anyone can sign up with any random email — even one they don’t own.

That’s obviously not safe for production. So in this post, we’ll fix that by adding Email Verification with Better-Auth.

❌ The Problem Without Verification

Right now, a user can type any email address on the registration page, and the server will happily accept it.

That means fake accounts, spam signups, and security risks. We need a way to make sure the person actually owns the email they’re registering with.

✅ Email Verification with Better-Auth

The good news? Better-Auth already has email verification built in for email/password authentication. We just need to configure it. Let’s go step by step.

🛠 Step 1: Configure an Email Provider

For sending verification emails, I used Resend.

Create a Resend account
Add your custom domain
Generate an API key
Save it in your .env file:

RESEND_API_KEY=your-api-key

🛠 Step 2: Create Email Templates

Inside Resend, configure simple templates for your verification emails.
This is the message your users will see in their inbox with the verification link.

🛠 Step 3: Enable Email Verification in Better-Auth

In your Better-Auth configuration, enable the verification features:

import { betterAuth } from "better-auth/server";
import { schema } from "../db/schema";

export const auth = betterAuth({
  schema,
  emailAndPassword: {
    enabled: true,
    requireEmailVerification: true,
  },
  emailVerification: {
    sendOnSignUp: true,
    autoSignInAfterVerification: true,
    async sendVerificationEmail({ user, url, token }, request) {
      await sendVerificationEmail({ email: user.email, url, token });
    },
  },
});

🛠 Step 4: Send Verification Email on Sign Up

Better-Auth will now automatically send a verification email when a new user registers.

After sign-up, redirect the user to a verify page in your app.
Tell them to check their inbox for the verification link.

// app/verify/page.tsx
export default function VerifyPage() {
  return (
    <div>
      <h1>Verify Your Email</h1>
      <p>
        We’ve sent you a link. Please check your inbox and click it to activate your account.
      </p>
    </div>
  );
}

🛠 Step 5: Testing the Flow

Register with a real email address
Check your inbox → you’ll see the verification email
Click the link → the server validates it
You’re automatically signed in and redirected to the homepage 🎉

Here’s what the successful response looks like:

{
  "status": 200,
  "message": "Email verified and user signed in"
}

🎉 And That’s It!

With just a few lines of configuration, we added secure email verification to our Better-Auth setup.

Now:

Users must prove they own their email
Fake signups are blocked
Onboarding is safer and more production-ready

📌 What’s Next?

This was Episode 2 of Better-Auth Basics.
In future episodes, we’ll cover:

👥 Role-based authentication
⚡ Rate limiting
🛡 Middleware for protecting routes Stay tuned — we’re just getting started.

🔗 Stay Connected

📽️ Youtube: code_unhinged
🐦 Twitter (X): zul_rayat
💻 GitHub: devrayat000
💼 LinkedIn: zim-rayat
📷 Instagram: rayatttttttt
📘 Facebook: rayat.ass

💬 Got questions? Drop them in the comments — I reply to every one!
👍 Don’t forget to like, share, and subscribe for more dev content.

Authentication Using Better-Auth (Basics Tutorial)

Zul Ikram Musaddik Rayat — Wed, 17 Sep 2025 00:04:40 +0000

What’s up, devs! 👋
In this post, I’ll walk you through setting up authentication in a Node.js/Next.js project using Better-Auth — a powerful new authentication library. This is based on the first episode of my YouTube playlist Better-Auth Basics.

Better-Auth makes it really easy to implement secure authentication with features like:

✅ Email + Password authentication
✅ Social sign-ins
✅ Built-in rate limiting
✅ Automatic database management & adapters
✅ Two-factor authentication support
✅ Simple client API for frontend integrations

Sounds exciting? Let’s dive in! 🚀

🛠 Project Setup

For this tutorial, I’m working on my personal project — a ride-sharing app.
We’ll integrate Better-Auth into it step by step.

1. Install Dependencies

We’ll need Better-Auth, Drizzle ORM, and Postgres.

bun add better-auth drizzle-orm postgres

2. Environment Variables

Generate a secret key and add it to your .env file:

BETTER_AUTH_SECRET=your-secret-key
BETTER_AUTH_URL=http://localhost:3000 # Base URL of your app
DATABASE_URL=postgresql://user:password@localhost:5432/dbname

⚙️ Database Setup with Drizzle

Better-Auth ships with ready-to-use schemas.
We’ll copy those into our project and run migrations.

1. Generate Schema

bunx @better-auth/cli generate # create better-auth schema

2. Run Migrations

bunx drizzle-kit generate # generate migration files
bunx drizzle-kit migrate

Once done, your database will have all the required tables.

🔑 Enable Email/Password Authentication

Inside your Better-Auth server setup, enable email/password auth:

// lib/auth.ts
import { betterAuth } from "better-auth";
import { drizzleAdapter } from "better-auth/adapters/drizzle";
import { db } from "@/db"; // your drizzle instance
import * as schema from "@/db/schema"; // your drizzle schema

export const auth = betterAuth({
  database: drizzleAdapter(db, {
    provider: "pg", // or "mysql", "sqlite"
    schema,
  }),
  emailAndPassword: {
    enabled: true,
  },
});

🖥 Setting Up the Client

Better-Auth provides a client utility to make frontend integration simple.

// lib/auth-client.ts
import { createAuthClient } from "better-auth/react";

export const authClient = createAuthClient({
  /** The base URL of the server (optional if you're using the same domain) */
  baseURL: "http://localhost:3000",
});

📡 Next.js API Routes

Now, let’s connect it with Next.js routes.

// app/api/auth/[...all]/route.ts
import { auth } from "@/lib/auth";
import { toNextJsHandler } from "better-auth/next-js";

export const { GET, POST } = toNextJsHandler(auth.handler);

This route will handle all sign-in, sign-up, and session management APIs.

👤 Implement Sign-Up

On your register page, use the client:

async function handleRegister(e) {
  e.preventDefault();
  try {
    await authClient.signUp.email({
      name: form.name,
      email: form.email,
      password: form.password,
      callbackUrl: "/",
    });
  } catch (err) {
    console.error(err);
  }
}

🔐 Implement Sign-In

Similarly, on your login page:

async function handleLogin(e) {
  e.preventDefault();
  try {
    await authClient.signIn.email({
      email: form.email,
      password: form.password,
      callbackUrl: "/",
    });
  } catch (err) {
    console.error(err);
  }
}

🎉 Testing It Out

Tried signing up → User was created successfully ✅
Tried logging in → Redirected to homepage with 200 response ✅

That’s it! We now have a working authentication flow with Better-Auth.

📌 What’s Next?

This tutorial only covers the basics:

Setting up Better-Auth
Running database migrations with Drizzle
Implementing Sign-In & Sign-Up

In upcoming posts/videos, I’ll cover:

🔑 Authorization & Role-Based Access
⚡ Rate Limiting
🔒 Two-Factor Authentication
🔗 Social Logins

Stay tuned!

🔗 Connect With Me

🐦 Facebook
💻 GitHub
💼 LinkedIn
📽️ Youtube

👉 If you found this useful, drop a comment and let me know what you’re building with Better-Auth.
And don’t forget to follow me here on DEV.to + subscribe on YouTube for more tutorials.

Happy coding! ✨

🍳 Recipe Generator – What’s in Your Pantry?

Zul Ikram Musaddik Rayat — Sun, 14 Sep 2025 20:33:41 +0000

This is a submission for the Google AI Studio Multimodal Challenge

What I Built

Have a few random ingredients lying around but no idea what to cook?
Recipe Generator helps you turn everyday pantry items into delicious meals.

Simply type or select ingredients you already have, and the app instantly generates recipe ideas — complete with images, instructions, and serving tips.

This makes meal planning fun, reduces food waste, and gives home cooks an easy way to experiment with new dishes.

Demo

🔗 Live Demo Link

Screenshots

How I Used Google AI Studio

Built the app on Google AI Studio, deployed via Cloud Run.
Used Gemini’s multimodal capabilities for:
- Text understanding: Parsing ingredient inputs.
- Image generation: Producing realistic dish images that match the recipe.
- Recipe generation: Turning ingredient lists into step-by-step cooking instructions.

Multimodal Features

Ingredient → Recipe (Text): Natural language input is converted into structured recipes.
Recipe → Image (Visual): Each generated recipe is paired with a dish image for inspiration.
Instructional Output: Clear step-by-step cooking instructions with serving notes.

Why This Matters

Practical impact: Helps reduce food waste by suggesting meals from what you already own.
User delight: A fun, interactive way to explore cooking ideas.
Strong multimodal showcase: Combines text understanding, recipe creation, and visual generation in a single workflow.

Team

Solo submission by @devrayat000

Hairstyle AI Try-On ✂️🤖

Zul Ikram Musaddik Rayat — Sun, 14 Sep 2025 19:55:25 +0000

This is a submission for the Google AI Studio Multimodal Challenge

What I Built

What if, before getting a haircut, you could actually see how you’d look?
Hairstyle AI Try-On lets you upload your photo and instantly preview multiple hairstyles, complete with AI-generated ratings to help you find your perfect match.

This app solves a very real problem: most of us take a risk when we try a new hairstyle. By using multimodal AI, you can confidently test different styles virtually before visiting the barber.

Demo

🔗 Live Demo Link

Screenshots

Initial State (upload your photo):

AI-Generated Hairstyles:

How I Used Google AI Studio

I built and deployed the entire experience on Google AI Studio.
The backend runs on Cloud Run, making it scalable and easy to deploy.
Gemini was used for image understanding (detecting the face and aligning hairstyles) and content generation (evaluating & scoring hairstyles).

Multimodal Features

Image Understanding: The uploaded photo is analyzed to detect face features and properly overlay hairstyles.
Image Generation/Transformation: Hairstyles are applied virtually, with realistic blending to match lighting and head shape.
Text + Scoring Output: Gemini provides natural-language feedback and a numerical “style score” (e.g. 8.5/10 for Curly Fringe).

This mix of visual + evaluative output makes the experience both fun and practical.

Why This Matters

Delightful user experience: Try on hairstyles virtually, no risk.
Practical application: Helps people make confident styling decisions.
Shows multimodal power: Combines vision, generation, and evaluation in one workflow.

Team

Solo submission by @devrayat000

Closing Thoughts

This project demonstrates how Gemini’s multimodal capabilities can power consumer-friendly, real-world experiences. It’s fun, engaging, and practical — all in one.

Highlighting Image Text

Zul Ikram Musaddik Rayat — Tue, 30 Apr 2024 22:10:00 +0000

Image processing and data extraction has become one of the most powerful features of Machine Learning now. But doing it from scratch is a pain in the a**. The one thing programming taught me that no one else did is not to reinvent the wheel every time and to prioritize getting the job done. Keeping that in mind, I have come across an easy solution for the problem at hand.

The Problem At Hand

For simplicity's sake, let us consider this to be a page from a book. We want to highlight the word comment wherever it occurs. This could be an intuitive feature for image search engines to direct the users' attention to their desired content.

Solution

We are going to be using an OCR (Optical Character Recognition) engine called Tesseract for the image-to-text recognition part. It is free software, released under the Apache License. Install the engine for your desired OS from their official website. I'm using Windows for this. Add the installation path to your environment variables.

Create a python project with a virtual environment set up on it. Install the necessary packages.

pip install opencv-python # for image processing
pip install pytesseract # to use the ocr engine in your project
pip install pandas # to conduct search queries

In your main.py import the necessary libraries and define the necessary variables. Read the image from the source using the imread method. Make a copy of the original image for the overlay. Extract text information from the image. It is important to set the output_type to be a pandas Dataframe object which will ease the filtering process.

import cv2
from pytesseract import pytesseract, Output

ALPHA = 0.4

filename = "devto.png"
query = "comment"

img = cv2.imread(filename)
# make a copy of the original image for the highlight overlay
overlay = img.copy()

# extract text data from the image as a pandas Dataframe object
boxes = pytesseract.image_to_data(img, lang="ben+eng", output_type=Output.DATAFRAME)

The dataframe object returned has the following structure:

level	page_num	block_num	par_num	line_num	word_num	left	top	width	height	conf	text
5	1	5	1	1	4	169	537	99	14	96.276794	comments

We are only interested in the text, left, top, width, and height columns. We need to prepare the dataframe for this specific job by applying various filters. Drop the rows that have NaN or empty string in the text column to make our data error-proof and the computations more efficient. The text column usually contains single words. We can iterate through each row to find out if any of them matches our query string.

# drop rows that have NaN values in the text column
boxes = boxes.dropna(subset=["text"])
# remove empty text rows
boxes = boxes[boxes["text"].str.len() > 1]
# Search through the text column for matching words
boxes[boxes["text"].str.contains(query.strip(), case=False)]

Now we can get started with the highlighting part. We will draw rectangular highlight boxes around the matched positions.

for _, box in boxes.iterrows():
    left = box["left"]
    top = box["top"]
    width = box["width"]
    height = box["height"]

    # draw a yellow rectangle around the matched text
    cv2.rectangle(
        overlay,
        (left, top),
        (left + width, top + height),
        (0, 255, 255),
        -1,
    )

# Add the overlay on the original image
img_new = cv2.addWeighted(overlay, ALPHA, img, 1 - ALPHA, 0)
# Some more image processing to make the highlights more realistic
r = 1000.0 / img_new.shape[1]
dim = (1000, int(img_new.shape[0] * r))
resized = cv2.resize(img_new, dim, interpolation=cv2.INTER_AREA)

Show the modified image using opencv's imshow method.

cv2.imshow("Highlighted", resized)
cv2.waitKey(0)
cv2.destroyAllWindows()

The result is this modified image with every occurring comment highlighted in yellow.

Bonus Tip

The search-through mechanism in this process can only detect and highlight a single word or full sentence with exact matches. If we want to highlight words that are not in a single sentence, we just need to filter the dataframe with a little bit of pandas magic.

+ from pandas import concat

- boxes[boxes["text"].str.contains(query.strip(), case=False)]
+ boxes = concat(
        [
            boxes[boxes["text"].str.contains(word.strip(), case=False)]
            for word in query.split()
        ]
  )

With this, the user can query "essential comments" and it will highlight essential and comments even though they are not together.

Hash routing in Remix!

Zul Ikram Musaddik Rayat — Fri, 29 Jul 2022 15:09:58 +0000

Remix is the newest hottest full-stack React framework. Remix supports file-based routing which uses react-router-dom under the hood which is a popular react routing library.

Because Remix users react-router's BrowserRouter internally, you can't actually do Hash Routing (id based routing that triggers scrolling) with it.

For example, if you create a link like this,

<Link to="#footer">
    Go to bottom
</Link>

it will surely change the browser URL, but won't scroll down to the element with an id of footer.

Of course, there's an easier way to achieve this behavior.

Turning off Client-Side Routing

We can add a reloadDocument prop to the specialized Link component and it will start acting like a normal anchor tag.

<Link to="#footer" reloadDocument>
    Go to bottom
</Link>

This in turns, turns off client-side routing and lets the browser handle the transition, as mentioned here

This is fine until you want both client-side routing and scroll behavior on hash routing.

Manual Scrolling via Side-Effect

The workaround this is to catch the side-effect created by the route change inside a useEffect and handle the scrolling manually.

In the root (root.jsx file) of our projects, we have to get the location object from the useLocation hook provided by remix. Then, we have to create a useEffect which depends on that location object. The location object has a property called hash which provides us with the hash portion of the URL e.g. #footer if the URL is www.example.com/#footer. Then we can look up the element containing that id and manually scroll down to it using the scrollIntoView method.

const location = useLocation();

useEffect(() => {
  if (location.hash) {
    const el = document.querySelector(location.hash);
    if (el) {
      el.scrollIntoView();
    }
  }
}, [location]);

DEV Community: Zul Ikram Musaddik Rayat

Building a Transparent Drag-and-Drop Shelf for Windows with Tauri: The Engineering War Stories

The architecture, briefly

Challenge 1: WebView2 silently refuses drag-and-drop unless the window was composited before the drag started

Challenge 2: dragDropEnabled is ignored if you set it in the Rust builder

Challenge 3: Never call .hide(), it kills the Acrylic backdrop

Challenge 4: set_focus() breaks the OLE drag you're trying to catch

Challenge 5: I deleted the "edge detector" window entirely and replaced it with a 50ms poll

Challenge 6: Dragging an item out trips your own auto-close

Challenge 7: Shrinking the binary from 17MB to 5.6MB

Challenge 8: A regex that quietly corrupted my MSIX manifest

What I'd tell my past self

Try it

How I Built and Launched a 100% Offline AI Productivity Tracker (Tauri 2, Rust, and Llama 3.2)

The Core Concept: Privacy-First AI

The Tech Stack

Deep Dive: Solving the Local LLM Challenge

1. The Dynamic DLL & On-Demand Model Download

2. Multi-Architecture CPU Builds (x64 + arm64)

Wrestling with the Microsoft Store & MSIX Packaging

Version Synchronization

CI/CD Automation

Lessons Learned on My First Desktop Launch

What's Next?

I Bought My Phone, But Android 16 Owns My Data: The Death of Non-Root Access

Attempt 1: The Shizuku-Powered File Managers

Attempt 2: Dropping into the Terminal

Attempt 3: The run-as Illusion

Attempt 4: Modding the APK

Attempt 5: The adb backup Betrayal

Attempt 6: Forcing the Migration Engine

The Grim Conclusion

Why I Walked Back from Next.js and RSC to a Plain SPA and a Separate Backend

When Next.js was genuinely great

Then the App Router and Server Components moved in

Then the security incidents made it concrete

The TanStack route - also not a free lunch

The deeper reason full-stack RSC was always going to be hard: serialization

The stack I actually use now

Frontend: React Router in framework mode, on Vite, mostly SPA

Backend: a separate service - Hono if I want TypeScript

Security lives in the backend, on purpose

What I actually gained

So, is Next.js bad? Is TanStack bad?

Email Verification with Better-Auth (Basics Tutorial, Ep. 2)

❌ The Problem Without Verification

✅ Email Verification with Better-Auth

🛠 Step 1: Configure an Email Provider

🛠 Step 2: Create Email Templates

🛠 Step 3: Enable Email Verification in Better-Auth

🛠 Step 4: Send Verification Email on Sign Up

🛠 Step 5: Testing the Flow

🎉 And That’s It!

📌 What’s Next?

🔗 Stay Connected

Authentication Using Better-Auth (Basics Tutorial)

🛠 Project Setup

1. Install Dependencies

2. Environment Variables

⚙️ Database Setup with Drizzle

1. Generate Schema

2. Run Migrations

🔑 Enable Email/Password Authentication

🖥 Setting Up the Client

📡 Next.js API Routes

👤 Implement Sign-Up

🔐 Implement Sign-In

🎉 Testing It Out

📌 What’s Next?

🔗 Connect With Me

🍳 Recipe Generator – What’s in Your Pantry?

What I Built

Demo

Screenshots

How I Used Google AI Studio

Multimodal Features

Why This Matters

Team

Hairstyle AI Try-On ✂️🤖

What I Built

Attempt 3: The `run-as` Illusion

Attempt 5: The `adb backup` Betrayal