DEV Community: Upendra Dasanayaka

Why I Built an Ultra-Lightweight Rust & Tauri Desktop Command Center for Developers

Upendra Dasanayaka — Fri, 28 Aug 2026 07:34:08 +0000

Ever spent 10 minutes debugging an error only to realize port 3000 was held hostage by a ghost Node.js process you thought you killed an hour ago?
Or opened your terminal and struggled to remember which nested subfolder you cloned a repository to last week?
These daily developer friction points led me to build DevDeck — a fast, open-source desktop command center designed to scan workspaces, run scripts, and kill ghost processes with a single click.

Here is why I chose Rust + Tauri over Electron and how the tool was architected.

⚡ 1. Why Not Electron? (The Resource Dilemma)

Developer utilities like command centers, process inspectors, and launchers need to stay open in the background all day.
If built with Electron:

🛑 RAM Usage: 250MB – 450MB just to display a simple dashboard (shipping a full Chromium + Node runtime).
🛑 Binary Size: 80MB+ installer. By building with Tauri + Rust:
🚀 RAM Usage: ~20MB – 35MB idle (using native OS WebViews: WebView2 on Windows, WebKitGTK on Linux, WKWebView on macOS).
🚀 Binary Size: Under 10MB installer.

* 🚀 Native OS Access: Direct access to system processes, PIDs, and disk scans via compiled Rust binaries.

🛠️ 2. Core Features & Implementation

A. Instant Workspace Scanner (`ignore` & `walkdir` in Rust)

DevDeck indexes your projects across multiple drives without lag. Instead of running a heavy recursive JavaScript scan, we delegate filesystem traversal to Rust using the ignore crate (respecting .gitignore and skipping node_modules / .git folders):

` use std::path::Path;
use ignore::WalkBuilder;
use serde::Serialize;

pub struct ProjectMetadata {
pub name: String,
pub path: String,
pub project_type: String, // "Node", "Rust", "Python", etc.
}

pub fn scan_workspace(root_dir: String) -> Vec {
let mut projects = Vec::new();
for result in WalkBuilder::new(&root_dir).max_depth(Some(4)).build() {
if let Ok(entry) = result {
let path = entry.path();
if path.file_name() == Some(std::ffi::OsStr::new("package.json")) {
projects.push(ProjectMetadata {
name: entry.path().parent().unwrap().file_name().unwrap().to_string_lossy().into(),
path: entry.path().parent().unwrap().to_string_lossy().into(),
project_type: "Node.js".into(),
});
}
}
}
projects
} `

B. One-Click Ghost Process Killer

When port 3000, 5173, or 8080 is blocked, finding and terminating the process via terminal commands (netstat, lsof -i, kill -9) interrupts your flow.

In DevDeck, the Rust backend queries listening sockets and exposes a 1-click kill function:

`rust

use sysinfo::{Pid, ProcessExt, System, SystemExt};

pub fn kill_process_by_pid(pid: usize) -> bool {
let mut sys = System::new_all();
sys.refresh_all();
if let Some(process) = sys.process(Pid::from(pid)) {
return process.kill();
}
false
}`

C. Live Script Runner with Real-Time Output Streaming

DevDeck parses package.json scripts and Cargo.toml targets, letting you execute commands and stream stdout/stderr live to a unified terminal pane inside the app using Tauri event emitters.

🎨 3. The Frontend: Zero-Bloat Glassmorphism

To keep DevDeck blazing fast, the UI was crafted using Vanilla HTML, CSS (Glassmorphism), and modern JavaScript with zero heavy framework overhead. The interface stays buttery smooth while drawing negligible CPU resources in the background.

📦 4. Cross-Platform & Open Source

DevDeck is 100% open-source and natively built for Windows, macOS, and Linux.

🌐 Download & Release Assets: Download DevDeck
💻 Source Code: github.com/KING-UPE/DevDeck
👨‍💻 Author & Portfolio: Upendra Dasanayaka

What features would make your development workflow faster? Let me know in the comments or contribute on GitHub! US THIS PERFECTLY OUTOUTED?

How I Built a Zero-Install, Multi-Gigabyte P2P File Transfer Engine in the Browser with WebRTC & File System Access API

Upendra Dasanayaka — Fri, 28 Aug 2026 07:23:44 +0000

Ever tried sending a 15GB 4K video file or a raw dataset to a teammate sitting at the next desk?

The options are surprisingly clunky:

Hunt for a physical USB flash drive.
Upload it to Google Drive, Dropbox, or Slack (wasting your internet bandwidth, hitting upload limits, and waiting for compression) only for your coworker to spend another 20 minutes downloading it back over the same local network.

I wanted to fix this with a zero-friction experience: no desktop client installation, no cloud storage limits, and full local network transfer speed directly inside the browser.
That led me to build FluX — an open-source, peer-to-peer (P2P) file sharing tool running entirely over WebRTC and modern browser streaming APIs.

Here is an architectural deep dive into how FluX streams multi-gigabyte files directly between machines without crashing browser memory.

🏗️ 1. High-Level Architecture: How FluX Works FluX uses a hybrid model:

Signaling Server (Node.js + Socket.io): Coordinates peer discovery and exchange of SDP (Session Description Protocol) offers, answers, and ICE candidates.
Direct P2P Data Channel (WebRTC SCTP/DTLS): Once the handshake completes, all file bytes travel directly peer-to-peer over the local router/LAN, bypassing the server entirely. [ Sender Browser ] [ Receiver Browser ] | | |--- 1. SDP Offer & ICE Candidates (via Socket.io) ->| |<-- 2. SDP Answer & ICE Candidates (via Socket.io) -| | | |======= 3. Direct WebRTC Data Channel (LAN) =======>| | [SCTP Chunks -> File System Access API] |

⚡ 2. Solving the 3 Hardest Browser Engineering Challenges

Challenge A: Bypassing the Browser RAM Crash (Direct-to-Disk Streaming)

Traditional browser file downloads build an in-memory Blob or ArrayBuffer before triggering a download link. If you transfer a 10GB file, the browser tab consumes 10GB+ of RAM and instantly crashes with an Out of Memory (OOM) error.
The Solution: The File System Access API (showSaveFilePicker).
Instead of holding chunks in memory:

The receiver selects a destination file handle on disk.
A FileSystemWritableFileStream is created.
Incoming binary chunks from the WebRTC Data Channel are piped directly into disk storage in real time.

javascript // Request destination file handle from user const fileHandle = await window.showSaveFilePicker({ suggestedName: incomingMetadata.name, }); const writableStream = await fileHandle.createWritable(); // Write incoming WebRTC chunk directly to disk dataChannel.onmessage = async (event) => { if (event.data instanceof ArrayBuffer) { await writableStream.write(event.data); } else if (event.data === "TRANSFER_COMPLETE") { await writableStream.close(); console.log("File saved directly to disk!"); } };

Challenge B: Smart Backpressure Management (bufferedAmount)

WebRTC Data Channels have an internal buffer queue. If your disk or local network sends faster than the channel can flush, RTCDataChannel.bufferedAmount skyrockets, leading to packet drops or crashed tabs.

The Solution: Custom Backpressure Queue.

We monitor dataChannel.bufferedAmount and pause chunk slicing whenever the buffer exceeds a high-water mark (e.g., 8MB), resuming only when bufferedamountlow fires:

javascript

Challenge C: Non-Blocking UI with Web Workers

Calculating cryptographic checksums (SHA-256) and slicing massive files can freeze the React render thread. We offloaded hashing and file chunking into dedicated Web Workers, keeping the Framer Motion animations smooth at 60 FPS.

🛠️ The Tech Stack
Frontend: React 18, Zustand (Atomic state management), Framer Motion, Tailwind CSS.
Protocols: WebRTC (SCTP/DTLS Data Channels), WebSockets (Socket.io).
Browser APIs: File System Access API, Web Workers, Blob slicing.
Signaling Backend: Node.js, Express, Socket.io (Stateless signaling).

🚀 Try It Out & Source Code
🌐 Live Demo: fluxbykingupe.vercel.app
💻 GitHub Repository: github.com/KING-UPE/FluX
👨‍💻 Portfolio & Contact: Upendra Dasanayaka

Have feedback or ideas on improving WebRTC throughput? Feel free to drop a comment or open an issue on GitHub!