DEV Community: Rahman Nugar

Owlyn: Building a Multimodal Agent Ecosystem for Live Technical Interviews and Real-Time Assistance #GeminiLiveAgentChallenge

Rahman Nugar — Mon, 16 Mar 2026 17:48:40 +0000

The current landscape of technical hiring is bottlenecked by a fundamental scalability problem. Organizations receiving hundreds of applications per role find it impossible to conduct live, high-quality interviews for every candidate, often resorting to cold, non-immersive recordings or static tests. These traditional "AI interviews" are neither live nor engaging—they strip away the conversational nuance that defines a great engineer and leave both the company and the candidate with a fragmented view of technical potential.

We built Owlyn to solve this gap using real-time multimodal intelligence. Instead of a static AI assessment, Owlyn operates as an autonomous agent ecosystem capable of seeing, hearing, and reasoning about a candidate’s live workspace. By leveraging the Gemini Live API, Owlyn conducts real-time technical interviews and provides a persistent assistant mode that can see, hear, and interact with sub-second latency. Every interaction is synchronized with live transcripts, ensuring the system is both high-fidelity and accessible across every workflow.

Watch the Owlyn Demo on YouTube

This piece of content was written by me, Abdulrahmon Adenuga (@rahmannugar), along with Akeem Adetunji and Mosimiloluwa Adebisi and created for the purposes of entering the Google #GeminiLiveAgentChallenge hackathon. It covers how we built Owlyn using Google AI models and Google Cloud.

The Core Objectives
System Architecture
The Multi-Agent Protocol
Live Workflows: Interview, Monitoring, and Assistant
Recruitment Management: Dashboards and Talent Pools
Real-Time Multimodal Pipelines
Security: The Sentinel Mode
Engineering Decisions
Closing Thoughts and Future Roadmap

1. The Core Objectives

Existing AI interview tools often fail because they are built as wrappers around static LLMs, leading to two major deal-breakers: hallucination and latency. If an AI takes 5 seconds to respond, the conversation is dead. If it "guesses" what your code does instead of analyzing its logic, it loses all technical authority.

To solve this, we defined four design pillars for Owlyn:

Zero-Latency: Using Gemini Live to achieve sub-second response times, this eliminates the "awkward silence" typical of LLM-based bots, ensuring the conversation maintains the natural momentum of a real-world technical discussion.
Multimodal Reasoning: The agent must do more than listen; it must "see" the workspace. By streaming the screen feed, the agent can react to a candidate's cursor movements or a logic error in a whiteboard diagram.
Inclusive Accessibility: Building a system that is accessible to everyone. This means supporting multiple spoken languages and providing live transcripts for candidates with hearing disabilities, ensuring that automation doesn't come at the cost of inclusion.

2. System Architecture

Owlyn is designed as a distributed, real-time multimodal system composed of four major layers:

Electron Client Layer
Backend Orchestration Layer
Worker Agent Layer
Infrastructure & AI Layer

This separation allows the system to maintain sub-second conversational latency, while supporting multiple AI agents analyzing different signals simultaneously.

2.1 Electron Client Layer

The client application is built with Electron + React, which allows Owlyn to access system-level capabilities that are unavailable in the browser.

The Electron frontend is responsible for:

Capturing camera, microphone, and screen feeds
Rendering the Monaco coding workspace
Streaming audio/video via WebRTC
Sending application events to the backend via HTTPS REST

The client communicates with the backend in two ways:

HTTPS / REST
Used for:

Authentication
Session creation
Interview configuration
transcript synchronization

LiveKit WebRTC
Used for low-latency real-time streams:

microphone audio
webcam video
workspace signals

These streams are routed to the backend orchestration layer and AI agents.

2.2 Backend Orchestration Layer

The backend is built using Spring Boot and acts as the central orchestrator of the entire system.

Rather than allowing each AI agent to independently connect to the client, all signals pass through the backend first. This ensures:

consistent session state
controlled AI communication
centralized logging and monitoring

The backend exposes two internal interfaces:

REST API
Handles standard application workflows:

interview creation
candidate session management
transcript storage
session metadata

Internal API
Used for agent-to-agent communication and system orchestration.
This internal API connects to the Assessor Agent, which performs post-interview analysis and scoring.

2.3 Worker Agent Layer

Owlyn runs several specialized Python worker agents responsible for processing multimodal signals during a session.
These agents operate independently from the core backend to keep real-time processing lightweight.

LiveKit Agent
The LiveKit Agent connects to the LiveKit WebRTC stream and manages:

real-time voice conversation
audio streaming to Gemini Live
returning AI responses to the candidate

This forms the primary conversational loop of the interview.

Proctor Sentinel
The Integrity Sentinel monitors the webcam feed to ensure the session remains secure.
Using Gemini Vision, it detects:

unauthorized devices
additional people in frame
suspicious behavior
environmental anomalies

Any violation is immediately flagged and logged.

Workspace Sentinel
The Workspace Sentinel observes the candidate’s coding environment, including:

Monaco editor
whiteboard interactions
cursor behavior
code structure

It continuously analyzes implementation logic and forwards observations to the Interviewer agent so the conversation can react to the candidate’s code in real time.

2.4 Infrastructure and AI Layer

The final layer provides the persistent infrastructure and AI services that power the system.

Dockerized PostgreSQL & Redis
We utilize Docker to containerize our data layer, ensuring a consistent and isolated environment for both PostgreSQL and Redis.

PostgreSQL: Handles durable storage for interview sessions, transcripts, reports, and user data. It is accessed through the Spring Boot backend via JPA.
Redis: Stores live session state (transcript buffers, agent context, security flags) for sub-millisecond updates during live conversations.

Note on Backend Deployment: The Owlyn backend (orchestration layer and worker agents) is hosted on Google Cloud Virtual Machines (VMs). This provides the stable, high-performance environment necessary for sub-second multimodal processing and session management.

LiveKit Server
LiveKit acts as the real-time media server for Owlyn.
It manages:

WebRTC signaling
audio/video transport
stream synchronization

This allows voice conversations to occur with sub-second latency, which is critical for maintaining natural dialogue.

Gemini AI
Owlyn integrates multiple Gemini models for specialized reasoning tasks:

Gemini Live API → real-time voice conversation
Gemini 3.1 Pro → deeper reasoning and evaluation
Gemini 3 Flash → lightweight real-time inference
Gemini Vision → visual analysis of the workspace and webcam Each model powers a different agent in the system.

2.5 Cross-System Communication Flow

During a live interview session, the system operates as a continuous pipeline:

The Electron client streams audio/video via LiveKit.

The Spring Boot backend orchestrates session state.

Python agents process multimodal signals in parallel.

Signals are routed to Gemini AI models for reasoning.

Results are returned through LiveKit to the candidate in real time.

Redis stores live context while PostgreSQL stores persistent records.

This architecture allows Owlyn to maintain low latency, contextual awareness, and modular AI reasoning, enabling the system to behave less like a scripted bot and more like a real technical interviewer.

3. The Multi-Agent Protocol

Owlyn is built on a decoupled multi-agent architecture. We designed the system from the ground up using specialized Gemini instances for distinct tasks; voice interaction, workspace vision, and real-time code analysis rather than relying on a single monolithic agent. This ensures that the interviewer remains grounded by the candidate's actual workspace signals while maintaining sub-second conversational latency.

The Orchestrator is our server. Since Gemini agents can't directly talk to each other without a shared context, the Orchestrator acts as the central router. It receives video and audio via WebRTC, pipes them to the correct Gemini model, and then relays context between the different agents. This ensures the interviewer can react to a failing test case or a specific logic choice in real-time.

Agent 1: The Question Generator (Gemini 3 Flash Preview): This agent runs during the interview creation phase on the management dashboard. It analyzes the job role and requirement details to draft specific technical challenges and coding tasks. This ensures the interviewer (Agent 2) has a tailored set of objectives ready before the candidate even starts the session.
Agent 2: The Interviewer (Gemini Live): This is the conversational agent the candidate hears. It handles the voice loop with sub-second latency, maintaining a natural dialogue flow throughout the session.
Agent 3: The Sentinels (Gemini 3.1 Flash Lite): These are the specialized "eyes" and "ears" of the system.
- Integrity Sentinel: Processes the video feed to monitor session security and detect unauthorized activity.
- Workspace Sentinel: Observes the Monaco editor and whiteboard. It analyzes the implementation logic in real-time, providing deep structural insights to the interviewer.
Agent 4: The Technical Assessor (Gemini 3): Once the interview ends, this agent takes the full transcript and the logic reasoning logs to generate a structured JSON report. It looks purely at the data to give an unbiased score.

graph LR
    %% Phase 1: Setup
    subgraph Setup ["1. Pre-Interview Setup"]
        Start(Job Role) --> A1[Agent 1: Question Generator]
        A1 -- "Drafts" --> Tasks(Technical Tasks)
    end

    %% Phase 2: Live
    subgraph Interaction ["2. Live Interaction"]
        Candidate((Candidate)) <--> |LiveKit WebRTC| Orch[Spring Boot Orchestrator]
        Orch <--> A2[Agent 2: Gemini Live Interviewer]
        Orch <--> A3[Agent 3: Workspace Sentinels]
        A3 -- "Visual & Code Feed" --> A2
    end

    %% Phase 3: Reporting
    subgraph Evaluation ["3. Final Scoring"]
        Interaction -- "Session Logs" --> Data(Transcripts & Context)
        Data --> A4[Agent 4: Technical Assessor]
        A4 -- "Report" --> Result(Unbiased Score)
    end

    %% Logic Flow
    Tasks -.-> A2

This "Agent-to-Agent" handoff is what makes Owlyn feel smart. When Agent 3 identifies a logic error in your code, it tells Agent 2: "Hey, their solution might have a performance issue." Agent 2 then asks the candidate: "I noticed your current approach might have some performance challenges. Can you walk me through your time complexity?"

Persona Customization: Defining the Interviewer

We built a Persona Engine to move away from a "one-size-fits-all" agent ecosystem. Recruiters can configure their agents' behavior through several technical levers in the management dashboard:

Linguistic Localization: The spoken language can be set per session, supporting English, German, Spanish, French, and several other locales for a global candidate pool.
Behavioral Scalars: Instead of basic prompts, we use weighted scores for Empathy, Analytical Depth, and Directness. These values are injected into the agent's core instructions to shift the tone from a supportive guide to a rigorous technical evaluator.
Document-Based Knowledge: Recruiters can upload PDFs or DOCX files—such as internal engineering rubrics or company values—which the system parses and uses to inform the agent's specific technical knowledge during the session.

4. Live Workflows: Interview, Monitoring, and Assistant

We didn't just stop at an interview screen. We built four distinct ways to use Owlyn. Across all modes, we prioritized accessibility through Live Transcripts. For developers with hearing disabilities or those in noisy environments, Owlyn provides a threaded, real-time transcript of every word the agent says. This ensures the system remains inclusive and that the agent's logic can be read and reviewed as it happens.

A. The Interview Workspace

This is the core experience. The candidate has a professional-grade workspace with the Monaco Editor, a canvas-based Whiteboard, and a Notes app. Everything is synced in real-time.

Support for Multiple Programming Languages

We engineered the workspace to be language-agnostic. By utilizing Monaco Editor (the engine behind VS Code), Owlyn provides a native coding experience for over 20+ languages, including Typescript, Python, Go, Java, and C++. The Workspace Sentinel (Agent 3) is specifically tuned to understand the idiomatic nuances of these languages, ensuring that whether a candidate is writing a high-performance Go routine or a clean React component, the evaluation remains context-aware and accurate.

B. Monitoring Mode

For organizations, visibility is just as important as the evaluation itself. We built a Monitoring Dashboard that serves as a real-time command center for recruitment teams.

Hiring managers can join any active session as a "Silent Observer," gaining a comprehensive view of the candidate’s performance without interfering with the natural flow of the interview. The dashboard provides a live, rolling transcript, a synchronized audio waveform to visualize the conversation's cadence, and an instant alert system. If our sentinels detect a security anomaly—such as the presence of a mobile device or an unauthorized person in the frame—a flag is immediately raised on the recruiter's screen, allowing for instant intervention if necessary.

C. Assistant Mode

Assistant Mode transforms Owlyn into a persistent multimodal companion for everyday development. Beyond the interview, this mode operates as a floating widget that lives alongside your IDE and terminal.

Environmental Context: The agent utilizes screen-share vision and your microphone to stay synchronized with your active tasks.
Voice-First Interaction: Leveraging the LiveKit protocol for sub-second responses, it acts as a senior pair-programmer you can talk to in real-time.
Ambient Assistance: Whether you're debugging a complex stack trace or architecting a new service, the Assistant provides contextual insights based on exactly what it sees on your screen.

D. Practice Mode

Before entering a real technical interview session, candidates need a way to test their technical skills and get comfortable with the interview environment. We built Practice Mode as a standalone version of the workspace where users define their own parameters:

Customizable Sessions: Users input a specific topic (e.g., "React Performance" or "Distributed Systems") and set a difficulty and timer. The agent then dynamically generates a technical session based on those constraints. --Multi Language Support: Users can select their preferred language from the list of supported languages. This instructs the AI agent to communicate with the candidate in their preferred language.
Protocol Parity: It uses the same multi-agent orchestration, audio/video streaming, and code analysis as the Enterprise mode. This ensures the candidate is getting the real experience in a private environment.

5. Recruitment Management: Dashboards and Talent Pools

Technical hiring is about more than just one interview; it is about managing many candidates effectively across an entire company. We built a management system to help teams handle their hiring process from start to finish:

The Recruitment Dashboard

This is the main control center where hiring teams manage their daily work. It shows what is happening in the company right now:

Track Candidates in Real-Time: Managers can see which candidates are waiting in the lobby, which interviews are currently live, and which ones are finished. This helps teams stay organized during busy hiring seasons.
Role-Based Customization: Recruiters can set different rules for different positions. You can choose the language the AI speaks and set how strict it should be. For example, you can make the AI a helpful guide for a junior developer or a very rigorous judge for a senior lead. You can also upload specific coding tasks for each role.
Human Decision Making (Hire or Decline): While the AI handles the interview, the final choice always belongs to a human. After the interview, a recruiter reviews the technical report and uses the Hire or Decline buttons to make a final evaluation. This ensures that a real person always has the last word.

Team Collaboration

Hiring is a team sport. We added features to help engineering leads and recruiters work together:

Team Management: Organizations can invite multiple team members to the dashboard. This allows different people to review the same candidate report and share their feedback.
Shared Feedback: Recruiters can leave notes on a candidate's profile for other team members to see. This helps build a complete picture of the candidate’s performance from different perspectives.

Analysis and Reporting

Once an interview is over, the AI generates a detailed technical report. This report is the primary tool recruiters use to make their hiring decisions:

Technical Radar Charts: The system visualizes candidate skills (like Problem Solving, Communication, and Code Quality) on a radar chart. This makes it easy to see at a glance where a candidate is strongest.
Full Transcripts and Code History: Recruiters can read every word said during the interview and see exactly how the candidate's code evolved over time.
Automated Summary: The AI provides a short summary of the candidate's performance, highlighting both their strengths and their mistakes.

The Talent Pool

The Talent Pool is a central library where all candidate results are kept. It helps teams find the best talent faster:

Compare Skills Side-by-Side: The system takes the AI's technical scores and puts them in a simple table. This lets recruiters filter candidates by their score or role, making it easy to see who performed best across hundreds of sessions.
Talent Analytics: The dashboard shows overall stats for your hiring pipeline, such as the total number of candidates, the percentage of high-potential profiles, and the average score for a specific role.
Exporting for Teams: Recruiters can export lists of elite candidates to share with other departments, ensuring that top talent is never lost in the system.
Unbiased Ranking: Because the AI scores everyone using the same technical rules, the Talent Pool gives teams an objective way to rank people based on their actual coding ability.

6. Real-Time Multimodal Pipelines

Capturing human interaction for an autonomous agent is technically demanding. We had to solve for two main things: data shape and latency.

For the Video Feed, we stream 1 frame per second. We found this to be the "sweet spot" for Gemini’s Vision capabilities—it’s enough to detect a phone or a change in gaze without destroying the candidate's upload bandwidth.

For Audio, we use 16kHz mono PCM. This is streamed up to our Java server, which then pipes it directly into the Gemini Live API via the Google ADK. We spent a lot of time on the audio.service.ts to ensure that audio chunks are small enough for low latency but large enough to maintain quality.

7. Security: The Sentinel Mode

Integrity is non-negotiable for professional assessments. We implemented what we call Sentinel Mode to protect the session:

OS-Level Lockdown: We use Electron's globalShortcut to block navigation and win.setContentProtection(true) to make the screen appear black to recording software like OBS.
Environmental Breach Detection: We listen for "blur" events. If the candidate switches windows, it’s logged as a breach, and the agent verbally warns them to focus.
Vision-Based Security Monitoring: Since Gemini is looking at the 1fps feed, it natively detects unauthorized objects (phones, tablets) or external participants in the room.

8. Engineering Decisions

Every engineering project is a series of trade-offs.

Latency vs. Accuracy: We chose 1fps for the vision feed over a smoother 10fps. While less "fluid," it ensures that candidates on a standard home connection can participate without lag or video fragmentation.
Centralized Session Orchestration: We chose to coordinate multiple agents through our Spring Boot backend rather than having the client manage separate peer-to-peer connections with 4+ different Gemini models. While this centralization adds architectural complexity, it was essential for maintaining a unified state across the Interviewer, Workspace Sentinel, and Integrity Sentinel.
In-Context Logic Verification: We leveraged Gemini’s specialized reasoning models to verify logic in real-time. This avoided the overhead of a formal execution sandbox while allowing the agent to provide feedback on implementation details as they unfold.
Memory-First State Management: We use Redis for all active session data (transcripts, flags, editor state). This sacrifices the "safety" of persistent disk writes for the sub-millisecond updates required in a live, voice-driven environment.

9. Closing Thoughts and Future Roadmap

Building Owlyn for the #GeminiLiveAgentChallenge allowed us to move beyond traditional AI interviews by creating a truly live and immersive workspace. By synchronizing voice and vision, we’ve enabled both high-fidelity technical assessments and a persistent assistant mode for everyday development. We see this multimodal synergy as the new standard for how technical talent is discovered, validated, and empowered in a high-stakes engineering world.

Looking forward, we’re expanding the Owlyn ecosystem with the following roadmap:

Team-Based Mode: Moving beyond silent monitoring to allow recruiters to "jump in" to the live session at any point. This enables a hybrid workflow where a human interviewer can take over the lead from the AI for a final, high-fidelity cultural evaluation.
Deeper ATS Integration: One-click exports to tools like Greenhouse or Lever to automate the hiring funnel.
Collaborative Whiteboarding: Support for real-time collaboration between the agent and candidate on the same whiteboard canvas.

Building this for the #GeminiLiveAgentChallenge has been an incredible experience, and we’re just getting started. 🦉

The Owlyn Team

Code Repository

Frontend: https://github.com/A-Simie/Owlyn
Backend: https://github.com/Akeem1955/OwlynBackend

Contributor	GitHub Profile
Mosimiloluwa Adebisi	@A-Simie
Akeem Adetunji	@akeem
Adenuga Abdulrahmon	@Rahmannugar

Designing a Flight Search Engine: Architecture, Caching, and Trade-offs

Rahman Nugar — Tue, 20 Jan 2026 08:31:38 +0000

I was recently asked to design and build a flight search engine using the Amadeus API as part of a frontend assessment. While the visible requirement was to surface flight results and price trends through a user-facing interface, I chose to approach the problem as a complete system rather than a UI-only task.

To reflect how flight search products are built in practice, I introduced a server layer responsible for integrating a rate-limited external API, defining a stable internal data contract, and implementing a caching strategy that keeps latency low under repeated queries.

The system uses global, deterministic caching keyed by search parameters rather than per-user caching. This allows identical searches to share cached results, reducing redundant upstream requests while keeping response times consistent across the application.

This article documents the system design of Flight33, part of an ongoing series of applications I build under the “33” naming convention. You can view the live application available at Flight33.

1. System Architecture
2. System Boundaries and Constraints
3. Data Flow and Responsibilities
4. Global Caching Strategy
5. Data Normalization and Contracts
6. Code Structure and Separation of Concerns
7. Client Responsibilities and State Management
8. Booking Flow Integration
9. Trade-offs and Limitations
10. Closing Thoughts

1. System Architecture

Flight33 is structured as a two-tier system with a clear separation between the client application and a server layer that mediates all access to external flight data.

The client is responsible for user interaction, search input, filtering, and presentation.
The server layer handles integration with the Amadeus API, response shaping, caching, and enforcement of system constraints.

The client does not communicate directly with the Amadeus API. All search requests are routed through the server layer, which acts as the single integration point for external flight data.

User
 ↓
Web Client (Next.js)
 ↓
Flight33 API
 ↓
Redis Cache
 ↓
Amadeus API

With this abstraction, Rate limits, response inconsistencies, and caching behavior are handled once, in a controlled environment, rather than being distributed across the client. As a result, the client remains predictable and focused on delivering a responsive search experience.

2. System Boundaries and Constraints

The design of Flight33 is driven primarily by the constraints imposed by the Amadeus API and the expectations of a responsive search experience.

The Amadeus API is rate-limited, exhibits variable latency, and returns responses whose structure can vary depending on query shape. Treating it as a direct dependency of the client would couple user experience to these constraints and make system behavior harder to control.

To avoid this, all interaction with Amadeus is isolated behind the server layer. This establishes a clear boundary where external variability is handled explicitly, rather than leaking into the client through retries, conditional logic, or UI workarounds.

Within this boundary, the system enforces a small set of invariants:

External API access is centralized and controlled
Identical searches resolve deterministically
Cached data is shared globally rather than scoped to individual users
The client interacts only with normalized, stable data structures

3. Data Flow and Responsibilities

A flight search in Flight33 follows a deliberately constrained flow designed to minimize external API usage while keeping client interactions responsive.

A search begins when the client submits a set of parameters, including origin, destination, dates, and passenger configuration. These parameters are forwarded to the server layer as a single search request.

On receipt, the server layer performs three sequential steps:

Cache resolution
A deterministic cache key is generated from the full search payload. If a matching entry exists, the cached result is returned immediately.
External fetch
If no cached result is found, the server fetches data from the Amadeus API using the validated search parameters.
Response shaping
The raw response is normalized into a stable internal structure before being returned to the client and written to cache.

Once the client receives the search results, no further network requests are required for filtering or pagination. All subsequent interaction operates on the in-memory dataset provided by the initial response.

4. Global Caching Strategy

Caching is central to how Flight33 controls latency and external API usage.

Search results are cached globally, not per user. A deterministic cache key is derived from the complete search payload, ensuring that identical searches resolve to the same cached entry regardless of who initiates them. This allows repeated queries to benefit from shared cache state rather than fragmenting cache usage across sessions.

The cache itself is backed by an in-memory data store(Redis) running alongside the server layer. Cached entries are written with a short time-to-live to balance freshness with performance, allowing the system to serve repeat searches quickly while avoiding long-lived stale data.

Because caching is handled within the server layer, the client remains unaware of whether a response was served from cache or fetched upstream. This keeps client behavior consistent while allowing cache policies to evolve independently.

During development and deployment, the cache service runs alongside the server layer using Docker, allowing cache behavior to be tested under the same assumptions used in production. This avoids environment-specific logic and keeps cache semantics consistent across local and deployed setups.

5. Data Normalization and Contracts

Responses from the Amadeus API are not consumed directly by the client. The raw payload contains deeply nested structures, optional fields, and variations that depend on the search parameters.

Before any data is returned, responses are transformed into a normalized internal format. This step extracts only the fields required for search results, pricing, and filtering, and maps them into a predictable structure.

This normalization step serves two purposes:

It isolates the client from upstream response variability
It establishes a stable contract that the rest of the system can rely on

As a result, changes in the external API surface do not propagate directly to the client, and frontend logic does not need to defensively handle inconsistent data shapes.

6. Code Structure and Separation of Concerns

The server layer is structured around explicit responsibilities rather than generic layers or framework conventions.

Search handling is composed of three distinct concerns:

Request coordination: receiving search input, validating parameters, and managing the request lifecycle
Search execution: resolving cached results, invoking the external flight data provider when required, and aggregating responses
Data transformation: converting provider-specific payloads into a stable internal data contract

Caching logic is treated as a first-class concern rather than an implementation detail. Cache key generation, read/write behavior, and expiry policies are centralized and invoked explicitly as part of the search flow, rather than being hidden behind decorators or middleware.

External integrations, including the Amadeus client and the cache client, are isolated behind well-defined interfaces. This prevents upstream changes or integration-specific behavior from leaking into search logic or request handling.

7. Client Responsibilities and State Management

The client is intentionally limited to interaction and presentation concerns.

Its responsibilities include:

Collecting and validating search input
Triggering search execution
Rendering search results
Managing UI state such as loading, errors, filtering, and pagination

Once search results are returned, the client does not issue additional requests when filters change. All filtering and sorting operations are applied to the in-memory dataset returned by the initial search.

This approach ensures fast feedback during interaction while keeping network usage predictable and minimal.

8. Booking Flow Integration

Flight33 does not attempt to handle bookings directly.

Each search result exposes a booking action that redirects users to an external booking platform with the relevant search parameters pre-filled. This allows users to continue the booking process without the system managing reservations, payments, or ticketing flows.

This decision keeps the system focused on search and comparison while delegating transactional complexity to a platform designed for it.

9. Trade-offs and Limitations

This design makes several deliberate trade-offs.

Search result sets are expected to remain within a manageable size
Client-side filtering assumes sufficient browser memory
Cached results tolerate short-lived staleness

If result volume or traffic patterns increased significantly, filtering and pagination would need to move server-side and be sent via every request, also the cache policies would need to be revisited.

10. Closing Thoughts

Flight33 was approached as a system design problem rather than a UI exercise.

By introducing a server layer to control external API access, define stable data contracts, and apply deterministic caching, the client remains predictable and responsive without compensating for upstream uncertainty.

Flight33 demonstrates that even a simple search-driven application lives or dies by how external data is handled. By centralizing API access, caching identical searches globally, and returning a stable dataset for client-side interaction, the system keeps both performance and behavior predictable.

Suite 33: A business management platform for SMEs.

Rahman Nugar — Thu, 27 Nov 2025 01:26:49 +0000

Running a small or medium sized business is difficult enough when operations are structured. Small and medium sized enterprises often rely on manual processes to run their operations. Sales are recorded on paper, inventory is tracked informally, payroll is handled in notebooks, and staff performance is evaluated without any structured system. These gaps often create delays, inaccuracies which is detrimental to business growth.

Suite33 was created to close those gaps. It is a business management platform designed specifically for SMEs. The goal is simple. Build a digital system that reflects how small businesses already work, while making their day to day operations cleaner, faster and easier to track.

Live Link - Suite33

1. Why Suite33 Was Built
2. Understanding the Challenges SMEs Face
3. Designing the Suite33 Experience
4. Getting Started: Onboarding and Setup
5. The Modules That Shape Suite33
6. Business Security and Roles
7. Lessons Learned While Building Suite33
8. Closing Thoughts

1. Why Suite33 Was Built

Suite33 did not begin as a random idea. It came from firsthand experience.
Recently, I was consulting with a business and I quickly noticed they ran their entire business activities with unorganized records. The business owner had no central view of how the business was performing. Decisions were made from instinct instead of data. It became clear that these businesses needed structure, hence Suite33.

2. Understanding the Challenges SMEs Face

Before writing a line of code, it was important to understand the real problems facing several SMEs in Nigeria.

After a thorough case study, I was able to draft out some of the most common issues:

Sales records disappear easily because they are written in notebooks or loose sheets.
Inventory is uncertain, making it difficult to know what is available at any moment.
Payroll takes too long, especially when each staff salary is calculated manually.
Staff performance is subjective, with no historical score or monthly evaluation.
Financial insights are unclear, since there is no unified view of revenue, spending and profit.

3. Designing the Suite33 Experience

I modelled Suite33 around clarity and structure. Instead of building a complex enterprise style system, the goal was to create something simple enough for daily use but powerful enough to rely on.

Every screen, every form and every action follows three principles:

1. Keep the workflow familiar
If a business is used to notebooks, Suite33 should feel like a digital extension of that, not a replacement that forces new habits.

2. Reduce cognitive load
No cluttered screens, no confusing menus. Businesses should be able to understand their data at a glance.

3. Centralize everything
Sales, expenses, inventory, payroll, staff and KPIs should all be centralized in a single dashboard application.

This approach ensured that Suite33 could serve small teams without overwhelming them.

4. Getting Started: Onboarding and Setup

The onboarding flow guides the business into the platform step by step.

Business Setup
Users begin by providing the essential details:

Business name
Industry
Location
Optional Business logo

This immediately personalizes the workspace and prepares the environment for operations.

Inviting Staff
Admins can invite up to 10 staff members per month.
This limit is intentional. It encourages businesses to gradually set up their team and ensures the system remains manageable during early adoption.
Staff receive an email and join the business with their own login. Their roles determine what they can access in the platform.

Editing Profile
Every user can update their personal information. This includes updating name, avatar.

5. The Modules That Shape Suite33

Suite33 contains several core modules, each responsible for one part of the business operation. They are connected behind the scenes, which allows the dashboard to generate a complete view of business performance.

Sales Management
The sales module makes it easy for businesses to record daily sales and monitor revenue trends over time.
With the ability to track monthly progress, visualize data export results and gain insights, SMEs finally gain clarity about how their business is performing. This transforms guesswork into informed decisions.

Expenditures
For a business to truly understand its profit margins, it must first understand spending.
Suite33 allows businesses to log every expense, categorize it and review spending patterns throughout the year. Every expenditure feeds directly into the dashboard’s profit and loss calculation.

Inventory Management
Inventory issues are one of the biggest pain points for SMEs. Suite33 simplifies this process with a clean, structured layout.

Businesses can:

Create categories
Add new inventory items
Track quantities
Edit details as stock changes
Export inventory lists
View low stock

The system prevents accidental deletion of categories that still contain items, protecting the integrity of the data.

Payroll
Payroll is often the most repetitive and time consuming task for SMEs. Suite33 introduces a monthly payroll batch system that automates most of the work.

Each month:

The admin generates a batch.
Staff salaries are automatically included.
Admin can update staff salaries and mark each staff as paid or unpaid.
When the batch is complete, it can be locked to prevent accidental changes.
Staff can view their payslip privately.
Admins can export the payroll to Excel or CSV.

Staff Management
Staff records are organized in one place. Admins can:

Add new staff
Remove staff
Edit roles
Assign departments
Staff only see information relevant to them.

KPI Tracking
Performance evaluation becomes simpler with monthly KPI scoring.
Instead of relying on memory or last minute judgments, businesses can maintain a consistent record of how each staff performs throughout the year.
KPI scores help guide promotions, reviews and improvements.

Dashboard Overview
The dashboard is the heart of Suite33.
It brings together data from every module to give the business a complete operational overview.

The dashboard displays:

Sales summary
Expenditures summary
Staff count
Inventory count
Payroll status
Profit and loss table
Business identity This allows business owners to view their financial and operational health at a glance.

6. Business Security and Roles

Suite33 is structured around three access levels:

Admin

Full access to all operations and business management.

Sub Admin(Assistant Admin)

Support role with management access but limited payroll visibility.

Staff

Restricted access with visibility limited to personal payslips and details.

This structure ensures privacy, accountability and security on all fronts.

8. Lessons Learned While Building Suite33

Building Suite33 revealed several important insights about SMEs and software design.

1. SMEs value simplicity above all else
Most small businesses do not need complex systems. They need clarity. They need something that simplifies their existing processes instead of replacing them.

2. Onboarding is as important as the product
Businesses lose interest quickly if the first steps feel overwhelming. Refining onboarding to be quick and human centered made adoption smoother.

3. Accuracy is everything when dealing with money
Payroll and financial modules must leave no room for uncertainty. The smallest error can create distrust. Ensuring reliability at every stage became a priority.

4. A business cannot grow without visibility
SMEs often operate in the dark. When they finally see their numbers clearly, they make better decisions. Data presentation mattered just as much as data storage.

5. Scalability is not only about technology
It is also about designing workflows that still make sense when the business grows from 5 staff to 50 staff. Features were built to feel predictable, even when usage increases.

6. Every role needs a different view of the system
Admins do not need the same interface as staff, and staff should never see what belongs only to administrators. Clear separation of roles became essential.

8. Closing Thoughts

Suite33 is designed to give SMEs a more organized way to run their business. It replaces manual processes with a single system that tracks sales, inventory, expenses, payroll and staff performance in one place.

The platform does not aim to complicate operations. Instead, it brings the structure small businesses need to work more efficiently and make informed decisions.

As SMEs continue to grow, Suite33 gives them a dependable foundation to grow on.

Contemporary State Management and Data Operations in React

Rahman Nugar — Thu, 16 Oct 2025 13:29:14 +0000

Tools evolve, trends change.

React introduced developers to a new way of thinking about UI, where components react to data and user interactions in real time. It started as a simple idea: manage state locally and let the UI update automatically. But as applications grew more complex, so did the challenge of handling state that needed to live across many parts of an app.

Fast forward to currentDate(), and we’ve come a long way from simple useState and useEffect for state management and data fetching respectively. Today, React developers work with Context API, Zustand, Redux Toolkit, for managing state and TanStack Query, RTK Query, server side fetching(Nextjs) for querying or mutating data. Each tool solves a slightly different problem, and knowing which one to use for a particular project makes all the difference.

In this article, we’ll take a detailed look at modern state management, data query and mutation in React. You’ll learn when each tool shines, how they fit together, and how to make the most of them in a modern React app.

Understanding React’s Core State Model
Context API: The Native Option
Zustand: Lightweight Yet Scalable
Redux Toolkit: Predictable and Enterprise-Ready
useEffect: The Misused Hook
TanStack Query
RTK Query
ServerSide Fetching
Patterns and Best Practices
Conclusion

1. Understanding React’s Core State Model

Before looking at the aforementioned contemporary tools, it’s worth revisiting the basics.

React’s design encourages predictable, unidirectional data flow. Each component has its own state, typically managed with hooks like useState and useReducer.

Usestate

const [name, setName] = useState("Nugar");

This works perfectly for local, isolated state such as toggling a modal or tracking form input.

For more complex scenarios, developers often use useReducer for clearer state transitions:

UseReducer

const initialState = { isOpen: false, modalType: null };

function reducer(state, action) {
  switch (action.type) {
    case "OPEN_MODAL": return { isOpen: true, modalType: action.payload };
    case "CLOSE_MODAL": return { isOpen: false, modalType: null };
    default: return state;
  }
}

const [state, dispatch] = useReducer(reducer, initialState);

The problem arises when different components need access to the same data. Manually passing props up and down the tree leads to “prop drilling,” which quickly becomes difficult to maintain. This is where global state solutions step in.

2. Context API: The Native Option

The Context API is React’s built-in way to share data globally across components without prop drilling. It’s simple, dependency-free, and ideal for small applications or simple global state.

// theme-context.tsx
import { createContext, useContext, useState } from "react";

const ThemeContext = createContext(null);

export const ThemeProvider = ({ children }) => {
  const [theme, setTheme] = useState("light");
  const toggleTheme = () => setTheme(t => (t === "light" ? "dark" : "light"));

  return (
    <ThemeContext.Provider value={{ theme, toggleTheme }}>
      {children}
    </ThemeContext.Provider>
  );
};

export const useTheme = () => useContext(ThemeContext);

Then in any component:

const { theme, toggleTheme } = useTheme();

When to Use

Small projects or simple global state
Shared values like theme, language, or authentication status

Limitations

Can trigger re-renders across all consuming components
Becomes hard to manage as the app grows
Not ideal for frequent or performance-sensitive updates

The Context API shines for lightweight scenarios, but once your application grows or requires complex state logic, a dedicated library becomes a better fit.

3. Zustand: Lightweight Yet Scalable

Zustand has become a favorite among developers for its simplicity and performance. It provides a minimal, intuitive API that lets you create global stores without providers or reducers. I frequently use Zustand nowadays for projects that require global state management due to its simplicity and ease of use.

import { create } from "zustand";

const useUserStore = create(set => ({
  user: null,
  setUser: user => set({ user }),
  logout: () => set({ user: null })
}));

Usage

const { user, setUser, logout } = useUserStore();

No boilerplate, no extra setup. Zustand uses shallow comparison to prevent unnecessary re-renders, keeping your app fast and efficient.

Why Developers Love It

Minimal API and easy learning curve
Excellent TypeScript support
Works great for UI and session state
Supports persistence, middlewares, and subscriptions

When to Use

Small to medium projects that need global state
Applications with local caching or session management

4. Redux Toolkit: Predictable and Enterprise-Ready

Redux has been around for years, and while it used to be associated with boilerplate and verbosity, Redux Toolkit (RTK) changed that. RTK provides structured, opinionated utilities that simplify reducers, actions, and store configuration.

import { configureStore, createSlice, PayloadAction } from "@reduxjs/toolkit";

interface AuthState {
  user: { name: string } | null;
}

const initialState: AuthState = { user: null };

const authSlice = createSlice({
  name: "auth",
  initialState,
  reducers: {
    login: (state, action: PayloadAction<{ name: string }>) => {
      state.user = action.payload;
    },
    logout: state => {
      state.user = null;
    },
  },
});

export const { login, logout } = authSlice.actions;
export const store = configureStore({ reducer: { auth: authSlice.reducer } });
export type RootState = ReturnType<typeof store.getState>;
export type AppDispatch = typeof store.dispatch;

Usage

import { useSelector, useDispatch } from "react-redux";
import { login, logout, RootState } from "./store";

export default function App() {
  const user = useSelector((state: RootState) => state.auth.user);
  const dispatch = useDispatch();

  return user ? (
    <button onClick={() => dispatch(logout())}>Logout</button>
  ) : (
    <button onClick={() => dispatch(login({ name: "Rahman" }))}>Login</button>
  );
}

5. useEffect: The Misused Hook

Before exploring modern data-fetching solutions, it’s important to talk about useEffect, a hook that was never designed for fetching or mutating data, yet became the default tool for it in most React apps.

When React Hooks were introduced, useEffect filled an essential gap in functional components. It allowed developers to perform side effects; actions that happen outside React’s rendering cycle. These effects include subscribing to events, updating the document title, managing timers, or synchronizing state with browser APIs.

In simple terms, useEffect lets your component “reach outside” React’s pure rendering world and interact with the environment.

useEffect(() => {
  document.title = `Hello, ${userName}`;
}, [userName]);

This is a perfect use case: the effect reacts to changes in userName and synchronizes the browser title accordingly.

However, over time, developers began using useEffect for something it wasn’t built for — data fetching and mutation.

useEffect(() => {
  async function loadUser() {
    const res = await fetch("/api/user");
    const data = await res.json();
    setUser(data);
  }
  loadUser();
}, []);

While this pattern works for small applications, it quickly becomes fragile as your app grows.

Why useEffect Is a Poor Fit for Data Operations

It Easily Re-Triggers Requests
It Doesn’t Handle Caching or Syncing
It Causes Race Conditions
It Adds Manual Overhead

These problems have even caused real-world incidents. Recently, Cloudflare experienced a large-scale performance issue that stemmed from an application repeatedly firing API calls due to misused React effects. The component’s re-renders multiplied outgoing requests, consuming massive internal bandwidth. The problem wasn’t React, it was a hook used for something beyond its purpose.

What useEffect Was Actually Meant For
The React team’s intention for useEffect has always been clear:

Setting up subscriptions or event listeners
Managing timers, intervals, or animations
Interacting with browser or third-party APIs
Cleaning up resources when a component unmounts

These are side effects, they are interactions that depend on or modify something outside of React’s data flow.

Fetching data, however, is a data flow operation, not a side effect. It belongs in a layer that manages caching, background refetching, synchronization, and invalidation. That’s far beyond what useEffect was built to handle.

Modern Tools Do It Differently
Libraries like React Query, RTK Query, and frameworks like Next.js have redefined how React handles data operations.

These tools aren’t built on top of useEffect. Instead, they use dedicated data layers that integrate deeply with React’s rendering engine, concurrent features, and Suspense. They know when to fetch, how to cache, and when to revalidate, all without you manually orchestrating it.

In modern React, useEffect should be reserved for what it was meant to do: handling external side effects at the component level. For data fetching, the ecosystem has evolved, and the right tools now exist to handle that responsibility cleanly and efficiently.

6. TanStack Query: Data Fetching Made Declarative

TanStack Query formerly known as React Query introduced a fundamental shift in how developers think about server data. Instead of manually managing loading, error, and caching logic, React Query abstracts those concerns behind a declarative API. It treats data as a cache that stays in sync with the server, not as temporary state inside your component.

TanStack Query revolves around two main concepts:

Queries for reading data (fetching)
Mutations for writing or updating data (creating, editing, deleting) Both are managed within a powerful caching layer that automatically keeps your UI in sync with your backend.

Query Example

import { useQuery } from "@tanstack/react-query";

function UserProfile() {
  const { data, isLoading, isError } = useQuery({
    queryKey: ["user"],
    queryFn: async () => {
      const res = await fetch("/api/user");
      if (!res.ok) throw new Error("Failed to fetch user");
      return res.json();
    },
  });

  if (isLoading) return <p>Loading...</p>;
  if (isError) return <p>Something went wrong.</p>;

  return <h2>Welcome back, {data.name}</h2>;
}

This hook handles fetching, caching, and background refetching automatically. When the queryKey changes, React Query knows it’s a different dataset and fetches accordingly.

Mutation Example

import { useMutation, useQueryClient } from "@tanstack/react-query";
function UpdateUser() {
  const queryClient = useQueryClient();

  const mutation = useMutation({
    mutationFn: async (user) => {
      const res = await fetch("/api/user", {
        method: "PUT",
        headers: { "Content-Type": "application/json" },
        body: JSON.stringify(user),
      });
      if (!res.ok) throw new Error("Failed to update user");
      return res.json();
    },
    onSuccess: () => {
      // Automatically refresh user data
      queryClient.invalidateQueries(["user"]);
    },
  });

  const handleUpdate = () => {
    mutation.mutate({ name: "Rahman Nugar" });
  };

  return (
    <button onClick={handleUpdate} disabled={mutation.isPending}>
      {mutation.isPending ? "Updating..." : "Update Profile"}
    </button>
  );
}

TanStack Query handles retries, optimistic updates, and cache synchronization under the hood, freeing you from manually tracking loading or error states.

Why It Matters

Queries cache data and refresh it only when needed.
Mutations update the server and sync local caches automatically.
Background updates ensure your data stays fresh without blocking UI rendering.

7. RTK Query: Redux-Powered Data Management

While TanStack Query is a standalone solution, RTK Query extends the Redux Toolkit ecosystem with an integrated data-fetching layer. It’s ideal if you already use Redux for state management but want modern, efficient data handling without extra libraries.

RTK Query provides similar declarative querying and mutation features but ties them directly into your Redux store.

Setting Up RTK Query

import { createApi, fetchBaseQuery } from "@reduxjs/toolkit/query/react";

export const userApi = createApi({
  reducerPath: "userApi",
  baseQuery: fetchBaseQuery({ baseUrl: "/api" }),
  endpoints: (builder) => ({
    getUser: builder.query({
      query: () => "/user",
    }),
    updateUser: builder.mutation({
      query: (user) => ({
        url: "/user",
        method: "PUT",
        body: user,
      }),
    }),
  }),
});

export const { useGetUserQuery, useUpdateUserMutation } = userApi;

Integrate it into your Redux store:

import { configureStore } from "@reduxjs/toolkit";
import { userApi } from "./userApi";

export const store = configureStore({
  reducer: {
    [userApi.reducerPath]: userApi.reducer,
  },
  middleware: (getDefaultMiddleware) =>
    getDefaultMiddleware().concat(userApi.middleware),
});

Using Queries and Mutations

function User() {
  const { data, isLoading } = useGetUserQuery();
  const [updateUser, { isLoading: isUpdating }] = useUpdateUserMutation();

  if (isLoading) return <p>Loading user...</p>;

  return (
    <div>
      <h2>{data.name}</h2>
      <button
        onClick={() => updateUser({ name: "Rahman Nugar" })}
        disabled={isUpdating}
      >
        {isUpdating ? "Updating..." : "Update"}
      </button>
    </div>
  );
}

RTK Query automatically caches responses, invalidates old data after mutations, and deduplicates concurrent requests while keeping data in Redux for predictable debugging and inspection.

When to Use RTK Query

You’re already using Redux Toolkit.
You want a single source of truth for both app and server state.
You need integrated caching and request lifecycle management.

8. ServerSide Fetching(Nextjs)

With frameworks like Next.js, data fetching moved beyond the client. Instead of fetching data after rendering, Next.js introduced ways to prefetch data on the server through getServerSideProps, getStaticProps, and, more recently, the Server Components model.

Server fetching shifts the data-fetching responsibility to the server layer, improving performance, SEO, and initial load times.

Example with Server Components
In the App Router (app/ directory), you can fetch data directly on the server without using useEffect or any client-side hooks:

// app/page.tsx
async function getUser() {
  const res = await fetch("https://api.example.com/user", {
    cache: "no-store",
  });
  return res.json();
}

export default async function Page() {
  const user = await getUser();

  return (
    <section>
      <h1>Welcome, {user.name}</h1>
    </section>
  );
}

Mutations in Next.js
With the new Server Actions, Next.js now supports secure, server-side mutations as well:

"use server";

export async function updateUser(data: { name: string }) {
  await fetch("https://api.example.com/user", {
    method: "PUT",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify(data),
  });
}

These actions can be directly called from client components using forms or event handlers, eliminating API route overhead while maintaining security and performance.

When to Use

Apps with strong SEO needs or public-facing content
Projects that rely on fast, server-rendered pages
Scenarios where data privacy and server security matter

9. Patterns and Best Practices

1. Separate UI State from Server State
Keep client-side UI logic (like modals or form inputs) separate from server-synced data.

2. Use useEffect Only for True Side Effects
Reserve it for browser interactions, subscriptions, or third-party integrations not data fetching.

3. Leverage Caching Layers
Tools like React Query and RTK Query prevent unnecessary requests and ensure consistent data.

4. Server-First Approach
In frameworks like Next.js, fetch data server-side whenever possible for better performance and SEO.

5. Handle Mutations with Invalidation
Always invalidate or update cached queries after a successful mutation to keep UI and server data aligned.

10. Conclusion

State management and data operations are essential parts of building efficient and scalable React applications. While React’s built-in tools like Context and hooks such as useState or useReducer can handle smaller projects, more complex applications often need advanced solutions to manage global state, server state, and API interactions efficiently.

For state management, libraries such as Redux Toolkit, Zustand provide robust and predictable ways to manage application-wide state. They help keep your logic organized and predictable, especially when multiple components need access to shared data or when actions in one part of the app affect another.

When it comes to data fetching and mutations, tools like Tanstack Query and RTK Query simplify handling asynchronous operations, caching, and synchronization between the client and server.

There are, of course, many other tools and technologies that address state management and data operations in React for example, libraries like Jotai, MobX, SWR, or even broader technologies like GraphQL that redefine how the client side communicate with the server side.

That being said, the tools covered here represent the most widely adopted solutions in modern React development and the ones I’ve personally worked with in real-world projects to deliver consistent, performant, and maintainable applications.

📆Byte-DatePicker: A Lightweight React Date Picker

Rahman Nugar — Sun, 03 Aug 2025 00:39:50 +0000

Lately, whenever I try to use a date picker in a project, I run into two main issues:

The default browser feels outdated, inaccessible, and not intuitive enough for modern UIs.
External UI libraries often come with bloated bundle sizes and tightly coupled components, making my app unnecessarily heavy.

While working on a project at my company, I needed a simple, flexible, and lightweight date picker that could be styled easily — and nothing quite fit. So, I built Byte-DatePicker.

✨ Introducing Byte-DatePicker

Byte-DatePicker is a reusable React component library tailored for date selection in forms and dashboards. Written in TypeScript, It allows full date selection (day, month, year) and ships with smooth animations, responsive layout, and minimal styling — making it easy to plug into any modern UI.

🔗 Check it out on npm

🧩 Key Features

🚀 Small bundle size – No unnecessary dependencies

📅 Full date selection – Ideal for forms, reports, billing, subscriptions, content scheduling, etc.

💅 Minimal styling – Easily customizable with your own CSS

⚛️ React 17, 18, 19 compatible

🧠 TypeScript support – Strong types and intellisense out of the box

npm install byte-datepicker
# or
yarn add byte-datepicker

Then in your component:

import ByteDatePicker from "byte-datepicker";
import "byte-datepicker/dist/index.css";

const App = () => {
  return (
    <div>
      <h2>Select a Month and Year</h2>
      <ByteDatePicker onChange={(date) => console.log(date)} />
    </div>
  );
};

Prop	Type	Default	Description
`value`	`Date	null`	`null`
`onChange`	`(date: Date) => void`	`undefined`	Callback when a date is selected
`minYear`	`number`	`currentYear - 10`	Minimum year selectable
`maxYear`	`number`	`currentYear + 10`	Maximum year selectable
`className`	`string`	`""`	Custom class name for styling

👨‍💻 Why You Might Use This
You want a focused datepicker, without a full UI library.

You're building something like a resume form, billing cycle selector, or historical filter.

You want a modern, accessible component with zero styling opinion unless you want to customize it.

💭 Final Thoughts

This is just the first version of byte-datepicker. If you use it and find it helpful (or want more features), I’d love your feedback.

🔗 See it on npm →

Let me know what you think or feel free to contribute! 👇

🚀 I finally built my first project on Electron Js: A Draggable Floating Webcam for Creators.

Rahman Nugar — Sat, 02 Aug 2025 18:37:29 +0000

Recently, I started a new job where one of the requirements was working with Electron.js — a framework I hadn’t touched before. Coming from a web development background (React, TypeScript, etc.), the idea of building desktop apps with web technologies felt both exciting and a bit daunting.

To speed up my learning and get comfortable with Electron’s ecosystem, I decided to build a side project: a floating, draggable webcam overlay for creators.

🎥Floating Webcam — A Lightweight Camera Overlay App

If you’ve ever recorded tutorials, walkthroughs, or gameplay, you know how tedious it can be to position and overlay your webcam footage during post-production. I wanted to eliminate that step entirely.

So I built Floating Webcam, a minimal desktop tool that lets you keep your webcam feed on top of other windows — no editing needed. Just launch the app, drag the camera feed where you want it, and start your screen recording software.

No overlays. No clutter. Just record.

🛠️ What It’s Built With
Electron.js – For creating a native-feeling cross-platform desktop app.

React – To structure the UI and manage component state.

TypeScript – For better DX and safer code.

TailwindCSS – For rapid and responsive styling.

Watch the demo on LinkedIn
Demo

You can view the full source code and try it yourself on GitHub:
GitHub

💡 Why I Built It

At work, I inherited an old Electron-based project that needed some serious improvements. Rather than dive straight into the legacy code, I figured the best way to understand how Electron works was to build something new and practical from the ground up.

Floating Webcam became the perfect sandbox — not too simple, not overly complex, and aligned with real-world use cases.

🔍 What I Learned About Electron

Before this project, my mental model was: "Electron just wraps a web app in a desktop shell."

But once I got into it, I quickly realized Electron has its own architecture and design considerations.

Here’s a breakdown of key concepts I picked up:

🧵 Main vs Renderer Process
Electron apps run two types of processes:

Main process – Manages the app’s lifecycle, windows, and system-level interactions.
Renderer process – Runs inside each window (like a browser tab) and handles the UI.

Understanding how they work together — and when to separate logic between them — was a foundational step.

🔐 Context Isolation + IPC
Because of security risks, Electron enforces context isolation between the main and renderer. So if you want to pass data (like media devices, window state, etc.), you need to use IPC (inter-process communication) via the contextBridge API.

I learned how to expose safe APIs from the main process to the renderer, which allowed React to control Electron-native behavior without direct access to Node.js.

🎥 Accessing Media Devices
Electron gives you access to the same Web APIs you’d use in the browser — like

navigator.mediaDevices.getUserMedia.

This meant I could handle webcam streams just as I would in a regular React app — but now within a persistent desktop environment.

👨‍💻 Final Thoughts
Electron can be intimidating at first, especially if you're coming from a web-only background. But once you get the hang of its architecture and build flow, it’s surprisingly powerful.

If you’ve ever wanted to turn a web app into a desktop app — or need native system access without learning a whole new language — Electron is absolutely worth exploring.

This project gave me the hands-on experience I needed to start contributing confidently to Electron-based projects at work.

DEV Community: Rahman Nugar

Owlyn: Building a Multimodal Agent Ecosystem for Live Technical Interviews and Real-Time Assistance #GeminiLiveAgentChallenge

Table of Contents

1. The Core Objectives

2. System Architecture

2.1 Electron Client Layer

2.2 Backend Orchestration Layer

2.3 Worker Agent Layer

2.4 Infrastructure and AI Layer

2.5 Cross-System Communication Flow

3. The Multi-Agent Protocol

Persona Customization: Defining the Interviewer

4. Live Workflows: Interview, Monitoring, and Assistant

A. The Interview Workspace

Support for Multiple Programming Languages

B. Monitoring Mode

C. Assistant Mode

D. Practice Mode

5. Recruitment Management: Dashboards and Talent Pools

The Recruitment Dashboard

Team Collaboration

Analysis and Reporting

The Talent Pool

6. Real-Time Multimodal Pipelines

7. Security: The Sentinel Mode

8. Engineering Decisions

9. Closing Thoughts and Future Roadmap

The Owlyn Team

Code Repository

Designing a Flight Search Engine: Architecture, Caching, and Trade-offs

Table of Contents

1. System Architecture

2. System Boundaries and Constraints

3. Data Flow and Responsibilities

4. Global Caching Strategy

5. Data Normalization and Contracts

6. Code Structure and Separation of Concerns

7. Client Responsibilities and State Management

8. Booking Flow Integration

9. Trade-offs and Limitations

10. Closing Thoughts

Suite 33: A business management platform for SMEs.

Table of Contents

1. Why Suite33 Was Built

2. Understanding the Challenges SMEs Face

3. Designing the Suite33 Experience

4. Getting Started: Onboarding and Setup

5. The Modules That Shape Suite33

6. Business Security and Roles

8. Lessons Learned While Building Suite33

8. Closing Thoughts

Contemporary State Management and Data Operations in React

Tools evolve, trends change.

Table of Contents

1. Understanding React’s Core State Model

2. Context API: The Native Option

3. Zustand: Lightweight Yet Scalable

4. Redux Toolkit: Predictable and Enterprise-Ready

5. useEffect: The Misused Hook

6. TanStack Query: Data Fetching Made Declarative

7. RTK Query: Redux-Powered Data Management

8. ServerSide Fetching(Nextjs)

9. Patterns and Best Practices

10. Conclusion

📆Byte-DatePicker: A Lightweight React Date Picker

✨ Introducing Byte-DatePicker

💭 Final Thoughts

🚀 I finally built my first project on Electron Js: A Draggable Floating Webcam for Creators.

🎥Floating Webcam — A Lightweight Camera Overlay App

💡 Why I Built It

🔍 What I Learned About Electron