DEV Community: Ehan Siddique

Farmora: my Next.js shop stalled up to 6s a page, so I made it local-first

Ehan Siddique — Wed, 14 Oct 2026 12:56:25 +0000

What Farmora is

Farmora ("From Local Farms to Your Door") is a farm-to-door marketplace. Farmers list what they've harvested and customers buy straight from them. Every order is delivered within three days, with a live tracker. Behind the shop there's an admin side where the platform keeps a 10% commission on each sale.

Live demo: https://farmora-smoky.vercel.app
Code: https://github.com/Fehan999/Farmora

Fehan999 / Farmora

Farmora 🌱

From Local Farms to Your Door

Farmora is a farm-to-table marketplace I built with Next.js. Farmers list what they've harvested, customers buy it straight from them, and every order arrives within three days with a live tracker that follows it from the farm to the front door. Behind that there's an admin side where the platform keeps a 10% commission on each sale. It started as a portfolio project, but I wanted it to behave like a real shop: real sign-ups, a real database, photo uploads for farmers, and pages that still load when the backend is having a bad day.

Live demo: farmora-smoky.vercel.app

Try it

No sign-up and no passwords needed. Open the login page and:

Pick Customer or Farmer.
Click View demo account to jump straight in, or Create your own account if you'd rather start fresh.
Curious about the business side? Click View admin…

View on GitHub

I designed and built it on my own. It has 27 page routes plus 6 blog article pages, 40 products in 8 categories, 8 partner farms with full profiles, 12 sample customers and 18 sample orders. All of it is sample data. There are no real farms, customers or payments behind it.

There are three roles:

Customers search and filter the shop and fill a cart. Delivery is free over $50 and $4.99 otherwise. They can apply coupons and check out with a demo card or cash on delivery.
Farmers get a dashboard with gross sales, the 10% platform fee, net earnings, a 7-day earnings chart and a product editor with photo upload.
Admins see platform revenue, a sales table with CSV export, product moderation, user management and a contact inbox. They don't get a cart or "My Orders", because they aren't shoppers.

Why I built it

I wanted a portfolio project that behaves like a real shop, and a marketplace forces questions a single-vendor store never has to answer. Who can see which order? What counts as the platform's revenue? What does a farmer see that an admin doesn't? What happens when the backend is down?

The farm angle gave every product a source, too. Each item shows the farm it came from, and each farm has its own profile page.

Architecture

I kept the stack small on purpose:

Next.js 14.2 with the App Router and React 18, in plain JSX (no TypeScript)
Tailwind CSS 3
Firebase 10 for Authentication, Firestore and Analytics
Supabase Storage for farmer photo uploads
Pexels CDN for product photos
Vercel for hosting
Playwright and GitHub Actions for screenshots and image checks

Seed farms, products, orders and photo ids live in data/. Most of the code in this post is in lib/.

1. A data layer that never makes the page wait

In the first version, getProducts() started with await readCollection("products"), and the page sat on a loading state until that came back. Now every getter in lib/db.js answers immediately. It merges three sources by id: the seed data, the last Firestore snapshot cached in localStorage, and any changes made in this browser. Firestore only refreshes that data in the background.

Every Firestore call in db.js goes through a timeout, now 4 seconds instead of 6:

const withTimeout = (p, ms = 4000) =>
  Promise.race([p, new Promise((_, rej) => setTimeout(() => rej(Object.assign(new Error("timeout"), { code: "timeout" })), ms))]);

remote() returns whatever is cached right now. If that cache is more than a minute old, it also starts a refresh. refresh() does the fetch, but skips it when Firestore is already known to be down, when the collection is locked, or when a request for that collection is already in flight:

function refresh(name) {
  if (!isBrowser || remoteDown || deniedCollections.has(name) || inflight.has(name)) return;
  const job = (async () => {
    try {
      const { db, sdk } = await getDb();
      const snap = await withTimeout(sdk.getDocs(sdk.collection(db, name)));
      const data = snap.docs.map((d) => ({ id: d.id, ...d.data() }));
      memory.set(name, { data, at: Date.now() });
      local.set(CACHE_PREFIX + name, data);
      notify();
    } catch (err) {
      markFailure(name, err);
    } finally {
      inflight.delete(name);
    }
  })();
  inflight.set(name, job);
}

function remote(name) {
  if (!isBrowser) return [];
  let entry = memory.get(name);
  if (!entry) {
    entry = { data: local.get(CACHE_PREFIX + name), at: 0 };
    memory.set(name, entry);
  }
  if (Date.now() - entry.at > REMOTE_TTL) refresh(name);
  return entry.data;
}

getProducts() merges the three sources in one line:

let all = mergeById(PRODUCTS, remote("products"), local.get("farmora_products"))

Failures go one of two ways. A permission-denied on one collection keeps only that collection local. Anything else, like a timeout or a disabled API, marks Firestore as down for the rest of the session, so no other page waits out the same four seconds:

function markFailure(name, err) {
  const code = err?.code || "";
  if (code === "permission-denied") {
    deniedCollections.add(name);
    return;
  }
  remoteDown = true;
  try { sessionStorage.setItem(STATUS_KEY, "1"); } catch {}
}

When fresh data arrives, notify() fires a window event:

function notify() {
  if (isBrowser) window.dispatchEvent(new Event("farmora:data"));
}

On the React side, components/useData.js listens for that event and re-runs the page's loader in silent mode, so the page updates without a spinner. A request counter drops the result of an older run that finishes late:

const run = useCallback(async (silent) => {
  const request = ++requestRef.current;
  if (!silent) setLoading(true);
  const result = await loaderRef.current();
  if (request !== requestRef.current) return;
  setData(result);
  setLoading(false);
}, deps);
...
useEffect(() => {
  const onChange = () => run(true);
  window.addEventListener("farmora:data", onChange);
  return () => window.removeEventListener("farmora:data", onChange);
}, [run]);

The home page, product pages and farm profiles pass seed data to useData as the initial value, so their first render already has content. Writes follow the same pattern. They're saved to localStorage first, then sent to Firestore in the background.

2. Loading Firebase when the browser is idle

The other cost was bundle size. The first lib/firebase.js imported firebase/auth and firebase/firestore at the top of the file, so every page shipped the SDK whether it used it or not. In the build output, that was about half of the shared JavaScript on every page.

Now each service is a cached promise around a dynamic import():

export function getDb() {
  if (!dbPromise) {
    dbPromise = Promise.all([getFirebaseApp(), import("firebase/firestore")]).then(([app, sdk]) => ({
      db: sdk.getFirestore(app),
      sdk,
    }));
  }
  return dbPromise;
}

The auth listener in context/AuthContext.jsx doesn't start until the browser is idle:

const idle = window.requestIdleCallback || ((fn) => setTimeout(fn, 200));
idle(start);

start prefetches the products, users and orders collections, starts Analytics and subscribes to onAuthStateChanged. The saved session in localStorage is read before any of that, so a returning user sees their name in the navbar straight away.

Shared first-load JS per page went from about 215 KB to about 106 KB.

Supabase got the same treatment. getSupabase() in lib/supabase.js is a lazy import("@supabase/supabase-js"), so the client only downloads when a farmer uploads a photo.

3. Commission math in one place

The business rule is short. Farmora keeps 10% of the product subtotal (price × quantity) of every order that wasn't cancelled. Delivery fees and tax don't count. An order with $42.00 of produce earns the platform $4.20 and the farmer $37.80.

My first admin dashboard got this wrong. Its "Total revenue" card added up full order totals, delivery and tax included. The platform never keeps that money, so the biggest number on the page was misleading.

Now the rate lives in one constant in lib/format.js:

export const COMMISSION_RATE = 0.1;
export const itemsSubtotal = (items = []) => items.reduce((s, i) => s + i.price * i.qty, 0);
export const commissionOf = (amount) => amount * COMMISSION_RATE;

And lib/stats.js builds every order-level number from it:

export const FEE_PCT = Math.round(COMMISSION_RATE * 100);
export const PAYOUT_PCT = 100 - FEE_PCT;

export const isActiveOrder = (o) => o.status !== "cancelled";
export const orderGross = (o) => itemsSubtotal(o.items || []);
export const orderCommission = (o) => commissionOf(orderGross(o));
export const orderPayout = (o) => orderGross(o) - orderCommission(o);

The admin overview, the 7-day commission chart, commission by category, the Sales table, its CSV export and the farmer dashboard all read from these two files, so the numbers always agree. Even the labels use FEE_PCT. Change the rate and the "Commission (10%)" column header changes with it.

The admin side still shows sales volume and farmer payouts, labelled as context so nobody mistakes them for revenue.

4. A delivery tracker with no background job

Every order moves through five stages over 72 hours. I didn't want a cron job or a cloud function moving statuses along, so lib/delivery.js works out the stage from the order's timestamp:

export const DELIVERY_HOURS = 72;

export const STAGES = [
  { key: "placed", label: "Order Placed", at: 0, icon: "📝" },
  { key: "packed", label: "Packed at Farm", at: 6, icon: "📦" },
  { key: "shipped", label: "Shipped", at: 24, icon: "🚚" },
  { key: "out", label: "Out for Delivery", at: 60, icon: "🛵" },
  { key: "delivered", label: "Delivered", at: 72, icon: "🏡" },
];

export function deliveryStatus(order, now = Date.now()) {
  ...
  const created = new Date(order.createdAt).getTime();
  const hours = Math.max(0, (now - created) / 36e5);
  const percent = Math.min(100, (hours / DELIVERY_HOURS) * 100);
  let stageIndex = 0;
  STAGES.forEach((s, i) => { if (hours >= s.at) stageIndex = i; });
  ...
}

The DeliveryTracker component updates now every 30 seconds, which moves the progress bar and the countdown.

Because it's plain math on a timestamp, no server has to keep it current. Sample orders work too, since the seed creates them relative to the current time. And the public /track page can show any order's progress from its order number, with no login. Customers can cancel until the order ships, and each order has a printable invoice.

The trade-off is that a stage isn't a real event. A real delivery system would need scans from the farm and the courier, and the timestamp math would only be the estimate shown until those scans arrive.

5. Images: srcset, fallbacks, and a workflow that checks every photo

The first version used placeholder images from a random-image service. They were slow and often showed the wrong food, so I replaced them with 125 curated Pexels photos.

data/photos.js stores the Pexels ids. lib/images.js builds a srcset from each URL, so a phone never downloads a desktop-sized photo:

const WIDTHS = [320, 480, 640, 960, 1280];
...
export function srcSetFor(src) {
  if (!isPexels(src) || !/[?&]w=\d+/.test(src)) return undefined;
  return WIDTHS.map((w) => `${resize(src, w)} ${w}w`).join(", ");
}

SafeImage wraps every product photo. It lazy-loads unless the image is marked priority, which the hero images are. When a photo fails, it falls back in two steps: first to an optional fallbackSrc, then to an inline SVG placeholder.

function onError() {
  setStage((s) => {
    const from = s === 0 && !src ? 1 : s;
    return from === 0 && fallbackSrc ? 1 : 2;
  });
}

Fallbacks hide broken images from me as well as from visitors. So I added a GitHub Action that builds the site, starts it and runs scripts/screenshots.mjs with Playwright.

The script screenshots every page, with the right demo session in place where a page needs one. It also requests every photo URL in data/photos.js. A photo passes only on a 200 response whose content type, if there is one, is an image:

entry.ok = entry.status === 200 && (!entry.contentType || entry.contentType.startsWith("image/"));

The results go to image-report.json. The script also renders contact sheets: grids of every photo, each captioned with the product or page it belongs to, with failures outlined in red. The workflow uploads all of it as an artifact and pushes the screenshots to a separate screenshots branch.

The URL check caught 10 broken photo URLs.

The contact sheets caught something a status code never will: several photos that loaded fine but didn't match their product. When I couldn't find a matching photo, I renamed the product rather than show a misleading picture. "Rainbow Carrots" became "Farm Fresh Carrots".

6. SEO with JSON-LD and generated OG images

A pageMeta() helper in lib/seo.js gives each public page its own title, description, canonical URL and Open Graph/Twitter tags.

The root layout adds a JSON-LD graph with WebSite (including a SearchAction that points at /shop?q=), Organization, Person for me as the author, and SoftwareSourceCode linking to the repo.

Product pages get a Product graph with offers, price, stock, delivery time and rating, plus a breadcrumb list. The product page itself is a client component, so the JSON-LD goes in a server layout that looks the product up in the seed data:

export default function ProductLayout({ children, params }) {
  const { product, farmer, category } = lookup(params.id);
  return (
    <>
      {product && <script type="application/ld+json" dangerouslySetInnerHTML={{ __html: toJsonLd(productJsonLd(product, farmer, category)) }} />}
      {children}
    </>
  );
}

toJsonLd escapes <, so a product description can never close the script tag early:

export const toJsonLd = (data) => JSON.stringify(data).replace(/</g, "\\u003c");

Product pages start from seed data, so the h1, price and description are in the server-rendered HTML too. Blog articles get BlogPosting data. app/sitemap.js lists every product, farm and blog post, and app/robots.js tells crawlers to skip the cart, checkout, orders, account, wishlist and dashboards. There's also a web manifest and a humans.txt.

The share image is generated with next/og. app/opengraph-image.jsx returns a 1200×630 ImageResponse with the logo, the tagline, my name and the stack. There's no separate design file to keep in sync with the site.

7. Demo accounts for visitors

Nobody reviewing a portfolio wants to sign up just to see a dashboard. The login page asks one question: Customer or Farmer? Then you can click "View demo customer account" (or the farmer version), or create your own account with Firebase email/password. A separate "View admin demo" option opens the business side.

The demo login doesn't wait on Firebase. It writes a session and tells the auth listener to ignore Firebase for it:

async function demoLogin(role) {
  const acc = DEMO_ACCOUNTS[role];
  const session = {
    uid: `demo-${role}`, id: `demo-${role}`, email: acc.email, name: acc.name,
    role: acc.role, farmerId: acc.farmerId || `demo-${role}`, demo: true,
  };
  ignoreFirebase.current = true;
  setUser(session);
  ...
  return session;
}

The demo button also prefetches its destination route as soon as it renders.

The demo farmer is Robert Hayes from Green Valley Farm. His dashboard opens with products, orders and earnings already in it.

How I tested it

Besides the screenshot workflow, I crawled every route with Playwright at desktop and mobile widths. No route had page errors or horizontal overflow. I checked 79 internal links and ran the main flows end to end: each demo login, checkout through to the tracker, and the admin access rules. The layout holds up on phones down to 390 px wide.

Lessons learned

A timeout doesn't help if the page still waits for it. The first version had a timeout and a fallback to sample data. Every page still sat through six seconds before it got to use that fallback. Rendering from local data first, and treating the network as an update, is what fixed it.

Read the build output before optimizing. I only found out Firebase was half of every page's JavaScript because I looked at the numbers. Moving it behind dynamic imports was a small change with a big result.

Write down what "revenue" means before building the dashboard. My first admin overview led with the wrong number because I hadn't defined what the platform keeps. One constant and a few small helpers fixed it.

A 200 status doesn't mean the image is right. The HTTP check found the broken URLs. Only the contact sheets showed me the photos of the wrong food.

Make the demo the front door. For a portfolio project, a one-click demo account matters more than any feature hidden behind a sign-up form.

Limitations and what's next

Checkout is a demo. No real payments happen, and the test card 4242 4242 4242 4242 charges nothing.

Next on my list:

Real payments with Stripe
Moving the background sync to Firestore real-time listeners, and tightening the security rules
Delivery slots per farm, instead of one 72-hour timeline for everyone
A proper end-to-end test suite (the screenshot script already does half the clicking)

Try it

Open the login page, pick a role and click the demo button.

A few other things to try:

Track a sample order without signing in at /track. Try ORD-10241.
Use the coupons FRESH10, FARMORA20 and WELCOME5 at checkout.

If something breaks, or you'd have built the data layer differently, leave a comment here or open an issue on GitHub. I'd like to hear it.

7 Real Problems I Faced While Building a Real-Time Chat Application

Ehan Siddique — Sat, 10 Oct 2026 05:31:56 +0000

Building a real-time chat application sounds pretty straightforward at first.

You create a login system, add a message input, connect a database, and display messages on the screen. That's basically it, right?

Well, that's what I thought when I started working on ChatLoop, my real-time messaging application built with React, Firebase, and WebRTC.

I wanted to create something more than a basic messaging demo. My goal was to build an application where users could connect with friends, exchange messages instantly, share files, make voice and video calls, and enjoy features you normally find in modern messaging platforms.

As development progressed, I added message reactions, typing indicators, read receipts, online status, voice messages, disappearing messages, and even an AI-powered chat assistant.

But behind those features were problems I hadn't fully anticipated.

Some bugs appeared only when two users were online simultaneously. Others involved network timing, browser restrictions, database synchronization, or React's component lifecycle.

Here are seven real challenges I faced while developing ChatLoop, how I approached them, and what they taught me about building real-world applications.

1. Managing Real-Time Messages Without Duplicates or Unexpected Updates

The first challenge was making real-time messaging reliable.

I used Firebase Firestore because its real-time listeners allow an application to receive database updates without constantly requesting new data.

At first, it seemed simple. Whenever someone sent a message, Firestore would update, and the conversation would immediately display the new message.

However, problems started appearing as the application became more complex.

Sometimes, changing between conversations created unexpected updates. I also had to deal with listener cleanup and situations where asynchronous updates could arrive after a component had changed.

The problem wasn't Firestore itself. It was how I managed real-time subscriptions inside React.

How I approached the problem

I focused on managing the lifecycle of every Firestore listener.

When a user opened a conversation, the application subscribed to the relevant messages. When they switched conversations or left the page, the previous subscription needed to be removed.

React's useEffect cleanup mechanism became particularly important.

I also had to think carefully about how messages were ordered and how incoming data updated the interface.

A real-time listener shouldn't automatically mean adding every received message to an existing array. Firestore snapshots need to be handled according to whether they represent the current dataset or individual changes.

What I learned: Real-time applications require more than fast database updates. They need proper subscription management, predictable state updates, and careful handling of asynchronous events.

2. Preventing Duplicate Conversations Between Two Users

Another interesting challenge involved managing private conversations.

ChatLoop includes a friend-request system where users can send, accept, reject, or cancel friend requests. Once two users become friends, they can start a private conversation.

But that introduces a question:

What happens if both users try to start the same conversation?

Imagine User A opens a chat with User B. Meanwhile, User B opens a chat with User A.

Without a consistent conversation identifier, the application could accidentally create two different chat threads for the same pair of users.

That would make message history, unread counts, and conversation management unnecessarily complicated.

How I solved it

I used a deterministic conversation ID based on the two users' identifiers.

Instead of generating a random ID every time someone opened a conversation, the application created a consistent ID from the same pair of users.

For example, the identifiers could be sorted before being combined:

User A + User B → Same conversation ID
User B + User A → Same conversation ID

The order of the users no longer mattered.

This made it easier to locate an existing conversation and associate its messages with the correct chat.

Of course, a predictable ID alone doesn't replace proper database access rules. Users should still only be able to access conversations they're authorized to view.

What I learned: Good data modeling can prevent entire categories of bugs before they happen.

Sometimes, solving a complicated UI problem starts with designing a better database structure.

3. Making Unread Messages and Read Receipts Work Correctly

Unread message counts seem like a tiny feature.

You receive a message, the unread counter increases, and when you open the conversation, the counter disappears.

Simple.

But implementing this correctly in a real-time environment turned out to be more challenging than I expected.

Consider these situations:

A user receives multiple messages while viewing another conversation.
The user opens a conversation while new messages are still arriving.
Two browser sessions are active for the same account.
A sender expects to see whether the recipient has read a message.

Suddenly, the application needs to keep track of more than just message content.

It needs to understand the relationship between messages, recipients, active conversations, and read status.

How I approached the problem

I worked with conversation-level unread information and message status updates.

When a message arrived, ChatLoop needed to determine whether it should count as unread for the recipient.

Opening a conversation also needed to update the relevant read state without incorrectly changing the sender's information.

I implemented visual indicators for message status, including read indicators, so users could better understand what was happening.

One important lesson was that delivering a message and reading a message are two different events.

A message existing in Firestore doesn't necessarily mean the recipient has seen it.

What I learned: Small features can require surprisingly careful state management, especially when multiple users interact with the same data.

4. Building Accurate Online Status and Typing Indicators

I wanted ChatLoop to feel like a real messaging platform rather than a static web application.

That meant showing when someone was online, when they were last active, and when they were typing.

These features make conversations feel more natural, but they also introduce a different kind of real-time problem.

For example, when should the application show someone as offline?

What happens if they close their browser without logging out?

What happens if their internet connection suddenly disappears?

A basic online/offline boolean cannot reliably answer all these questions.

How I approached the problem

For online presence, I worked with user activity and last-seen timestamps, using Firebase server timestamps where appropriate.

I also implemented typing information that could be displayed to the other participant.

Typing indicators need to be temporary. Otherwise, someone could stop typing, leave the conversation, and still appear to be typing indefinitely.

This required thinking about when typing state should begin, when it should stop, and how the interface should respond to changes.

Presence tracking has its own limitations, too. A last-seen timestamp is useful, but truly reliable online presence requires accounting for disconnects and inactive sessions.

What I learned: Real-time user experience isn't just about displaying fresh information. It's also about knowing when information is no longer valid.

5. Getting WebRTC Voice and Video Calls to Connect

This was one of the most challenging parts of building ChatLoop.

Text messaging was one thing. Real-time audio and video communication introduced an entirely different set of problems.

I used WebRTC for peer-to-peer media communication and Firebase Firestore for signaling.

WebRTC allows browsers to establish connections for real-time audio and video, but creating that connection involves several steps.

The calling user generates an offer, the receiving user responds with an answer, and both sides exchange ICE candidates to discover a working network connection.

It sounds manageable when explained in a few sentences.

In practice, timing matters enormously.

The ICE candidate problem

One issue I encountered involved ICE candidates arriving before the receiving peer connection was ready to process them.

This created connection failures that were difficult to reproduce consistently.

Sometimes a call would connect successfully. Other times, the connection would fail even though the same general process had worked before.

After investigating the signaling flow, I realized I needed to manage the order in which candidates were handled.

How I solved it

I introduced an ICE candidate queue.

Instead of trying to process every candidate immediately, the application could temporarily store candidates that arrived too early.

Once the remote session description was ready, the queued candidates could be processed.

I also worked with STUN and TURN server configuration to help establish connections across different network conditions.

TURN support is especially important because direct peer-to-peer connectivity isn't always possible.

What I learned: In asynchronous systems, having the correct data isn't enough. The data also needs to arrive—or be processed—at the correct stage.

WebRTC taught me a lot about signaling, network communication, race conditions, and error handling.

6. Fixing Audio Playback and Handling Browser Restrictions

After working through WebRTC connection problems, I discovered another issue.

A call could appear connected, but the remote audio wouldn't always play as expected.

From a user's perspective, that feels like a broken call.

From a developer's perspective, the connection itself might actually be working.

This was particularly confusing because I had to distinguish between a networking problem, a media-stream problem, and a browser playback problem.

Modern browsers place restrictions on automatic media playback, especially when audio is involved.

That means receiving a remote stream doesn't guarantee that the browser will immediately play it.

How I approached the problem

I reviewed how remote media streams were attached to media elements and how playback was initiated.

I also handled audio and video call states more carefully, including what should happen when a user accepts, minimizes, or ends a call.

The goal was to make the interface accurately reflect the actual call state.

A call shouldn't appear fully functional if the application hasn't properly initialized its media handling.

I also learned that media elements need careful lifecycle management. Streams and tracks should be cleaned up when a call ends so that resources aren't left running unnecessarily.

What I learned: A successful network connection doesn't automatically mean a successful user experience.

You have to consider how browsers handle permissions, playback, device access, and media cleanup.

7. Handling File Uploads and Firebase Storage CORS Errors

ChatLoop supports more than text messages.

I wanted users to exchange attachments and voice messages as part of normal conversations.

For file handling, I used Firebase Storage.

However, while developing the attachment features, I encountered CORS-related problems.

CORS, or Cross-Origin Resource Sharing, is a browser security mechanism that controls whether web applications can access resources from different origins.

An upload or resource request can fail when the required cross-origin permissions aren't configured correctly.

At first, these errors can be frustrating because the application code might look perfectly reasonable.

The problem may actually involve the interaction between the browser, storage service, and hosting configuration.

How I approached the problem

I investigated the storage requests and reviewed the configuration needed for the application's origin.

After addressing the relevant configuration issues, I continued working on the attachment experience.

But the experience also taught me that successful uploads are only part of the problem.

A production-ready file-sharing system needs to consider:

File size and type validation
Upload progress and error messages
Storage access permissions
Secure file retrieval
Failed or interrupted uploads

Uploading a file is easy to demonstrate in a tutorial. Building an experience that users can depend on requires more planning.

What I learned: Frontend development doesn't stop at writing React components. Understanding browser security, cloud configuration, and access control is equally important.

What Building ChatLoop Taught Me About Real-World Development

Before building ChatLoop, I already had experience working with React, JavaScript, and modern frontend tools.

But this project pushed me to think differently.

I wasn't simply developing individual features anymore. I was connecting several systems that needed to work together.

React managed the user interface. Firebase handled authentication, data, and storage. WebRTC enabled real-time calls. And the application needed to keep all those pieces synchronized.

Every time I added a feature, I had to consider how it would affect the existing application.

Adding message reactions affected message rendering.

Adding voice messages introduced media permissions and file handling.

Adding calling features introduced connection states, signaling, and cleanup.

Even a simple feature like showing whether a friend was online raised questions about connection reliability.

I also integrated an AI chat feature using Google's Gemini API, which introduced another area to think about: connecting AI services to an existing application safely and predictably.

One of the biggest lessons was that building software isn't just about making features work once. It's about making them work consistently under different conditions.

Tutorials are useful for learning technologies, but real projects force you to understand how those technologies behave together.

My Advice to Developers Building Their First Real-Time Application

If you're planning to build a real-time chat application using React, Firebase, or WebRTC, here's what I'd recommend based on my experience.

Start with the data model. Think about users, friendships, conversations, messages, and permissions before creating a complicated interface.

Keep real-time listeners under control. Make sure subscriptions are cleaned up when they're no longer needed.

Test with multiple accounts. A chat application might work perfectly when you're testing alone, but behave differently when two users are sending messages at the same time.

Expect asynchronous problems. Database updates, network responses, and WebRTC signaling don't always happen in the order you expect.

Treat loading and error states as real features. Users should understand what's happening when something is connecting, uploading, or failing.

Don't ignore security. Authentication alone isn't enough. Database rules, storage permissions, and server-side API handling deserve attention.

Focus on reliability before adding more features. A basic messaging application that works consistently is more valuable than a feature-rich application with unpredictable behavior.

Final Thoughts

Building ChatLoop has been one of my most valuable learning experiences as a developer.

It gave me the opportunity to work with real-time databases, authentication, media communication, cloud storage, application state, and AI integration in a single project.

Some problems took longer to understand than I expected. Others taught me concepts that I probably wouldn't have explored through tutorials alone.

And that's what I enjoy most about building projects.

Every challenging bug is an opportunity to understand something more deeply.

If you're working on your own real-time application, don't be discouraged when features become more complicated than they initially seemed. Those difficult parts are often where the most useful learning happens.

Want to explore ChatLoop?

Live Application: https://chatloop-mu.vercel.app/

I'm Ehan Siddique, a full-stack web developer working with React, Next.js, Node.js, Firebase, and modern web technologies.

I share development experiences, technical lessons, and projects on my website:

https://ehansiddique.com

Thanks for reading!

I Built a Real-Time Chat App with React, Firebase, WebRTC & Gemini AI — Here’s What I Learned

Ehan Siddique — Mon, 28 Sep 2026 13:11:59 +0000

Building a chat UI is easy.

Building a chat application that actually behaves like the messaging apps we use every day is a completely different challenge.

I’m Ehan Siddique, a full-stack web developer, and recently I built ChatLoop, one of my biggest personal projects so far.

ChatLoop started as an idea for a simple real-time messaging application, but I kept asking myself:

What would I need to build if this were a real communication product instead of just another portfolio project?

That question changed the entire project.

I ended up building real-time messaging, reactions, read receipts, voice notes, file sharing, presence tracking, audio/video calls, screen sharing, friend requests, an AI assistant, reporting and moderation, account suspensions, and a complete admin dashboard.

In this article, I want to share how I approached the project, some of the engineering decisions behind it, and what I learned while building it.

What is ChatLoop?

ChatLoop is a real-time communication web application built primarily with:

React 18
Vite
Tailwind CSS
Firebase Authentication
Cloud Firestore
Supabase Storage
WebRTC
Google Gemini API
Framer Motion

The goal wasn't simply to let two users send messages.

I wanted the application to handle many of the smaller details that make a messaging product actually feel complete.

That includes things like:

typing indicators
read receipts
message reactions
unread counters
voice messages
online/away/last-seen status
audio and video calls
missed and rejected call states
screen sharing
user reporting
account suspension
admin announcements
AI conversations

And importantly, these features needed to work together.

1. Real-Time Messaging Was More Than `onSnapshot()`

Firebase makes listening for real-time data surprisingly simple.

But displaying messages in real time is only one part of building a messaging system.

Every conversation in ChatLoop needs information such as:

participants
lastMessage
lastMessageTime
lastMessageSender
unreadCounts

while the actual messages are stored separately.

A simplified version of the structure looks like:

chats/{chatId}

messages/{chatId}/messages/{messageId}

When someone sends a message, ChatLoop doesn't only create the message.

It also updates the conversation metadata.

I handle those operations together in a batch.

Conceptually:

writeBatch(db)

// Create message
// Update last message
// Update timestamp
// Update sender
// Increment receiver unread count

batch.commit()

Why?

Imagine the message succeeds but updating lastMessage fails.

The receiver could have a new message inside the conversation while their sidebar still displays the previous one.

Keeping related operations together prevents that inconsistent state.

Firestore also applies local writes before receiving confirmation from the server.

That allowed me to make a newly sent message appear immediately while displaying a small pending state until the server confirms it.

That tiny detail makes messaging feel much faster.

2. I Didn't Want Hundreds of Unnecessary Listeners

Real-time applications can become expensive and complicated when everything becomes a listener.

Initially, it is tempting to listen to everything:

Conversation A messages
Conversation B messages
Conversation C messages
Conversation D messages
...

But the dashboard doesn't actually need every message from every conversation.

It mainly needs conversation metadata.

So ChatLoop's dashboard listens to chat documents.

When lastMessageTime changes and another user was the sender, the application knows that a new message arrived.

It can then:

update the conversation preview
update unread counts
play a notification sound
show a desktop notification when appropriate

Only the currently opened conversation needs its messages actively displayed.

This taught me an important lesson:

Real-time doesn't mean everything needs to be real-time.

You still need to think about what data the UI actually needs.

3. Building User Presence Was Surprisingly Interesting

I wanted ChatLoop to display:

Online
Away
Last seen...
Offline

A simple solution would be:

online: true

when the application opens and:

online: false

when it closes.

Unfortunately, browsers aren't that reliable.

What happens if:

the browser crashes?
the laptop loses internet?
the phone kills the browser?
the user closes the process unexpectedly?

The application might never get the chance to write:

online: false

So ChatLoop uses a heartbeat system.

The application periodically updates the user's presence.

If an online status becomes older than the allowed threshold, ChatLoop treats that user as offline.

I also listen for tab visibility.

When the tab becomes hidden:

online → away

and when the user returns:

away → online

There is also a privacy setting allowing users to hide their active status.

It seems like a small feature, but building it taught me a lot about how unreliable client state can be.

4. Then I Added WebRTC Calls

This was probably one of the most interesting parts of the project.

ChatLoop supports:

audio calls
video calls
microphone mute/unmute
camera controls
screen sharing
missed calls
rejected calls
reconnect attempts

WebRTC handles the actual peer-to-peer communication.

But two browsers still need a way to find each other and exchange connection information.

For that, I use Firestore as the signalling layer.

The basic process looks like this:

Caller
   ↓
Create call
   ↓
Create WebRTC offer
   ↓
Store signalling data in Firestore
   ↓
Receiver
   ↓
Create WebRTC answer
   ↓
Exchange ICE candidates
   ↓
Peer-to-peer connection

The call itself has lifecycle states such as:

calling
   ↓
active
   ↓
ended

and additional final states:

missed
rejected

5. Race Conditions Matter

One interesting problem happens when both users hang up almost simultaneously.

Both clients could potentially try to write the final call state and create the same "call ended" event.

I solved this using a transaction for final call states.

That way, only one final call event wins.

This was one of those situations where building the feature teaches you more than reading about the concept.

You start noticing race conditions because suddenly there are two real clients modifying the same state.

6. Opening the Call Screen Immediately

I didn't want this:

Click call
↓
Wait
↓
Wait for Firestore
↓
Open calling UI

It feels slow.

Instead, the call ID can be generated on the client.

The calling screen can therefore open immediately while the Firestore document is being created in the background.

This makes the experience feel significantly more responsive.

However, it creates another problem.

What if the caller hangs up before the Firestore write finishes?

The other person's device could potentially receive the call afterward and keep ringing.

So the hang-up flow needs to account for the initial call write before completing cleanup.

These are the kinds of problems I didn't think much about before building a calling system.

7. Network Changes Are Another Problem

WebRTC connections aren't always stable.

Users can move between:

Wi-Fi → mobile data
mobile data → Wi-Fi

or temporarily lose connectivity.

My WebRTC service handles an ICE restart attempt when the network changes before completely giving up on the connection.

I also learned why TURN servers matter.

Peer-to-peer WebRTC connections don't always work directly between restrictive networks.

For production-level reliability, a TURN server becomes important.

8. Voice Notes and File Uploads

ChatLoop also supports voice messages.

Users can record a message directly from the chat input and send it like a normal message.

I wanted voice notes to feel like an actual messaging feature instead of just displaying an HTML audio element, so the player includes a waveform-style interface.

Users can also send:

images
documents
screenshots

and can drag files into the chat or paste screenshots directly.

I use Supabase Storage for these uploads while Firestore stores the related message information.

This gave me a useful separation:

Firestore
→ application/message data

Supabase
→ actual uploaded files

9. Friend Requests Became Their Own System

Users can discover other people using:

name
username
four-digit ID

Then they can:

Send request
Accept
Decline
Cancel
Remove friend

The user document's friend list is ultimately the source of truth.

When a friend request is accepted, I update the request and both users' friend lists together.

Again, atomic operations become important.

You don't want:

User A says B is their friend

but

User B doesn't have A

because one database write failed.

10. I Added Gemini AI as Another Conversation

I also wanted ChatLoop to include an AI assistant.

Instead of making it feel like a completely separate feature, ChatLoop AI appears directly in the chat list.

Each user has their own AI conversation history.

The structure is roughly:

aiChats/{uid}/messages/{id}

When requesting a response, recent messages are provided as context to Gemini.

I don't send the user's entire lifetime conversation every time.

The service uses the most recent messages as context.

I also implemented a fallback model.

If the main Gemini model becomes overloaded, the application can attempt to use a lighter model instead.

One decision I particularly like is how errors are handled.

Instead of silently failing, an error can become part of the conversation so the user understands what happened.

11. Markdown Without `dangerouslySetInnerHTML`

AI responses often contain Markdown.

I wanted ChatLoop AI to render those responses nicely, but I didn't want to simply inject arbitrary HTML into the application.

So the Markdown rendering system doesn't rely on:

dangerouslySetInnerHTML

It's a small implementation detail, but security decisions like this become increasingly important once your application starts displaying generated or user-controlled content.

12. Building the Admin Panel Changed the Project

This was one of the biggest differences between ChatLoop and some of my earlier projects.

I started thinking:

If real users were using this application, how would I actually manage it?

That resulted in a complete /admin interface.

The dashboard displays information including:

total users
users currently online
active users
registrations
conversations
messages
friendships
reports
suspended users

Administrators can:

search users
edit selected profile information
suspend users
remove suspensions
review reports
dismiss reports
delete reported messages
publish announcements

13. I Also Built a Read-Only Guest Admin

I wanted people visiting my portfolio or GitHub repository to actually see the administration system.

But obviously I couldn't give random visitors admin privileges.

So I created a guest administrator.

The guest can view the real dashboard but cannot perform administrative actions.

And importantly, this isn't just:

if (guest) {
  disableButton()
}

The Firestore security rules also prevent guest writes.

That distinction is important.

14. The UI Is Not Security

This was probably one of the most valuable security lessons from this project.

ChatLoop doesn't have a traditional custom backend server.

That means Firestore Security Rules effectively become part of the backend security layer.

The rules enforce things such as:

Users can only modify permitted profile fields.

Only conversation participants can access private chats.

Only conversation participants can access messages.

Suspended users cannot send messages.

Suspended users cannot initiate calls.

Suspended users cannot send friend requests.

Guest administrators cannot modify admin data.

The frontend can hide a button.

But someone can modify frontend JavaScript.

They cannot simply override properly configured Firestore rules from the browser.

My rule became:

UI permissions determine what the user sees. Security rules determine what the user is actually allowed to do.

15. Reporting and Suspensions

I also wanted to explore moderation.

Users can report individual messages or entire accounts.

A message report can preserve information about the reported message so an administrator has context when reviewing it.

Administrators can then take actions such as removing the reported message or suspending the user.

Suspension also needed to affect the rest of the application.

When someone is suspended:

They see a suspension screen.

Friends see "Account suspended."

Messaging becomes unavailable.

Calling becomes unavailable.

Friend requests become unavailable.

And again, Firestore rules enforce those restrictions.

16. Admin Announcements

Admins can publish announcements that appear to users like notifications.

But I didn't want the same announcement to appear every time someone refreshed the application.

So ChatLoop creates a small version identifier based on the announcement content.

Once a user sees it, that version is stored.

If the administrator changes the announcement, the version changes and users receive the updated announcement.

It's a relatively small feature, but I enjoyed solving it.

17. Organizing the Codebase

As the application grew, architecture became increasingly important.

One rule I adopted was:

Components should not directly contain Firestore implementation logic.

Instead, Firebase-related functionality lives inside dedicated files.

A simplified structure looks like:

src/

components/
  auth/
  chat/
  admin/
  common/

firebase/
  messaging
  users
  friends
  reports
  admin

service/
  presence
  WebRTC

hooks/

utils/

So if a component needs to send a message, it calls a function from the relevant Firebase service rather than implementing database operations directly inside the component.

That made the project significantly easier to reason about as it grew.

18. Some Things I Would Change at Larger Scale

ChatLoop isn't perfect.

There are several things I would approach differently if I were scaling it to a very large user base.

User search

The current friend search can load users and filter them client-side.

That's acceptable for a relatively small number of users.

It would not be my solution for hundreds of thousands or millions of accounts.

At that point, I'd move search to a proper indexing/search solution.

TURN infrastructure

WebRTC connections can fail when users are behind restrictive NATs or networks.

A production deployment should have reliable TURN infrastructure.

Group conversations

ChatLoop currently focuses on one-to-one communication.

Group messaging and group calling would require additional architecture.

19. What I Learned

ChatLoop taught me much more than simply how to build a chat interface.

I had to think about:

Real-time architecture

What actually needs a listener and what doesn't?

Consistency

What happens when one write succeeds and another fails?

Race conditions

What happens when two clients update the same state simultaneously?

Presence

How do you know someone is really online?

Networking

What happens when a WebRTC connection fails or the network changes?

Security

What prevents someone from bypassing the frontend?

Moderation

How would administrators handle abusive users?

Performance

How much data should remain live at once?

How do you make operations feel immediate even when network requests are happening?

Those questions made this project much more valuable to me than simply creating another CRUD application.

Final Thoughts

ChatLoop started as a personal project.

But it became an opportunity for me to explore several areas of modern web development inside one application:

React
+
Firebase
+
Real-Time Data
+
WebRTC
+
Supabase
+
Gemini AI
+
Security
+
Moderation
+
Admin Tools

There are still many things I want to improve, and that's part of why I enjoy building projects like this.

Every new feature creates another engineering problem to solve.

I'm Ehan Siddique, and I build full-stack web applications while continuing to explore real-time systems, React, Next.js, Firebase and modern web technologies.

If you'd like to explore ChatLoop, you can find the project, source code and a more detailed case study through my portfolio and GitHub.

Portfolio: https://ehansiddique.com/projects/chatloop

GitHub: https://github.com/Fehan999/Chat-Loop
Live Link: https://chatloop-mu.vercel.app

If you're working on a real-time application yourself, I'd also be interested to hear what architecture and technologies you're using.

AI Won't Replace Web Developers—But Developers Who Use AI May Replace Those Who Don't

Ehan Siddique — Thu, 24 Sep 2026 22:53:38 +0000

The use of artificial intelligence in web development does not signal a threat to the job but a chance for renewal.What this means for web developers is that AI will not take their place but those who don't keep with it may be replaced!

Several years ago, writing the code with AI was seen as a futuristic concept.

To-day, AI can create a react component, explain error codes, write SQL queries, build APIs, or suggest UI designs to help developers resolve issues in just seconds.

Of course, many devs are wondering:

“Will AI take the place of web developers?”

My answer is:

Palpitations aside, AI likely won't overtake web developers as of yet. However, web developers who can harness the power of AI may have the upper hand over those resisting its uptake.

But that's a whole another story.

AI affects the actions of developers, as well.AI also impacts what developers do.

AI is emerging as yet another tool in a developer's kit.

Just as developers do:

VS Code
Git
Stack Overflow
npm
Documentation
Browser DevTools

These days, AI can assist with a lot of the development procedure.

An AI developer can request the AI to:

Describe a little known fault

Generate a basic component
Create boilerplate code
Suggest improvements
Write tests
Explain documentation
Find potential bugs
Refactor repetitive code
Generate SQL queries
Create API examples

This doesn't mean the developer is no longer needed.

It means that the developer can focus on actual problem and not repetitive tasks.

But There's a Problem

AI can write code.

But, this does not imply that AI is always capable of writing the proper code.

It's here that developers still have a role to play.

Suppose you call the AI and say: "Create a system to handle payments".

It may output code which is then perfectly normal.

But is it secure?

Does it provide for failed payments?

If one of the users refreshes the page?

Does the request contain a message where it can be meddled with?

Is it possible for sensitive credentials to be disclosed?

Is it up-to-date with the payment provider's latest requirements?

These are NOT just coding questions.

These are engineering / business questions.

It is the developer's responsibility to know what the system should do and how to ensure that it performs its duties properly.

It is significant that the Skill is no longer “Writing Code”, but is “Solving Problems”.

Perhaps the largest change AI is making in development is this.

Knowledge of Coding used to provide a tremendous competitive edge.

It's still important.

However, more and more, the developers must also understand:

What should I construct?

Why needs to I construct it in this method?

What are some potential issues?

How to scale this system up?

How should the users interact with it?

How can I be sure the AI-generated code is correct?

The increasingly valuable competencies of good questioning, understanding systems, testing solutions, and making technical decisions are all essential.

You can make a good developer faster with AI.AI can help make a good developer faster.

Now consider two developers.

Developer A is against AI.

Developer B is familiar with the use of AI and has also a solid understanding of programming basics.

Provide the same project to both the developers.

Developer B could rely on AI to generate boilerplate rapidly, analyze errors, experiment with various solutions and automate repetitive tasks.

But, he/she still reviews the code, tests it and gives feedback, asks for changes, and makes final decisions, which is Developer B.

That's the true power.

AI isn't necessarily replacing the developer.

It's putting more money in the hands of the developer.

However, don't become reliant on AI.

But, there's another way of thinking about this.

If you don't comprehend the code AI produces, you're not really in control of your project.

It just has to be hoped that the code produced is functional.

That's dangerous.

However, a developer needs to know basic concepts like:

JavaScript
HTML/CSS
APIs
Databases
Authentication
Git
HTTP
Security
Debugging
Software architecture

It's not necessary to memorise all codes.

However, it is important to understand what the code is doing and why it works.

The coming developer will not be “AI vs Developer”.

I don't see the future on:

AI → replaces developers

I believe it's more like:

Developer + AI = Improved developers process.

AI can do more of the repetitive aspects.

For developers, they can now better concentrate on:

Architecture
User experience
Business logic
Security
Performance
Problem solving
Communication
Product decisions

This doesn't debase the very value of developers.

It alters their value's origin.

So what does this mean for developers?

Don't panic.

AI shouldn't be overlooked, either.

Know how to use it.

Start small.

When you encounter an error that you don't understand, explain it using AI.

Request it to evaluate a function.

Make use of it for creating test cases.

Seek other solutions to a problem.

Apply it to comprehend documentation.

Then verify everything.

It must not be the objective:

“Let the Artificial Intelligence construct everything for me”.

The goal should be:

“How might AI assist me in enhancing my coding capabilities and improving productivity?”

The difficulty in comprehending the impact of the novel.The challenge of understanding the novel.

I think that the people who will get the biggest return in using AI will not be the ones the most frantically using all the AI tools.

They will be the developers that mix:

Strong fundamentals + AI skills + problem-solving + knowledge of the business.

It is a far greater combination compared to any one AI tool.

The transformation of web development due to AI is in full effect.

However, technology always-always change development.

Those who adapt will have a chance to be faster, more productive and more valuable developers.

Thus, rather than Asking:

“Will AI take my job?”

Perhaps a more pertinent question is:

“How to harness the power of AI and become an irreplaceable developer?”

What are your views?

Will AI ever take over certain aspects of web development or just alter the way developers function?

I would be very happy to have your comments at the end of the post.

JWT Refresh Tokens: How They Make Login Systems Safer and More Practical

Ehan Siddique — Wed, 23 Sep 2026 04:20:34 +0000

When building a modern web application, authentication is one of the first things we need to think about.

A simple login system sounds easy:

User enters email and password → server checks them → user is logged in.

But what happens after the login?

How does the website remember that the user is authenticated? How long should the login remain valid? What happens if an authentication token gets stolen?

This is where JWT access tokens and refresh tokens become useful.

What is a JWT?

JWT stands for JSON Web Token.

It is a compact token that can be used to represent authenticated information between a client and a server.

After a successful login, the server can generate an access token:

User → Login
↓
Server verifies credentials
↓
Server generates JWT
↓
Client receives token

The client can then send the access token with requests to protected APIs.

For example:

Authorization: Bearer

The server verifies the token and decides whether the request is authenticated.

So what's the problem with a normal JWT?

The main problem is token lifetime.

Imagine giving a user an access token that remains valid for 30 days.

That's convenient, but it creates a security problem.

If someone steals that token, they may be able to use it until it expires.

On the other hand, if we make the access token expire after 5 or 10 minutes, security improves, but users would constantly have to log in again.

That's not a great user experience.

This is where the refresh token comes in.

What is a Refresh Token?

A refresh token is a longer-lived credential that can be used to obtain a new access token without asking the user to log in again.

Instead of having one token do everything, we separate the responsibilities:

Access Token

Short-lived
Used for API requests
Expires quickly

Refresh Token

Longer-lived
Used to obtain new access tokens
Should be protected carefully
Usually isn't sent with every API request

The basic idea looks like this:

            LOGIN
              │
              ▼
      ┌─────────────────┐
      │ Server verifies │
      │   credentials   │
      └────────┬────────┘
               │
        ┌──────┴──────┐
        ▼             ▼
  Access Token   Refresh Token
   Short-lived    Long-lived
        │             │
        ▼             │
   API Requests       │
                      │
                Access token
                   expires
                      │
                      ▼
              Refresh request
                      │
                      ▼
              New access token

The user doesn't need to enter their password again.

Why Not Just Use a Long-Lived JWT?

This is one of the biggest reasons refresh tokens exist.

Suppose your access token is valid for 30 days.

If it gets stolen, the attacker may have a usable credential for a long period.

Instead, you could make the access token short-lived:

Access Token → 10–15 minutes
Refresh Token → days/weeks

Now, even if an access token is compromised, its useful lifetime is much shorter.

The refresh token is more sensitive, so it needs stronger protection and should be handled carefully.

How the Login Flow Works

Let's imagine a user logs into an application.

Step 1 — User submits credentials
POST /api/login
{
"email": "user@example.com",
"password": "password"
}

The server verifies the credentials.

Step 2 — Server generates tokens

If authentication succeeds:

Access Token
+
Refresh Token

The access token is used for normal API requests.

The refresh token is kept in a safer storage mechanism, commonly an HttpOnly, Secure cookie for browser applications.

Step 3 — User accesses protected resources

The client sends the access token:

GET /api/profile

Authorization: Bearer

The server verifies it.

If valid:

200 OK
Step 4 — Access token expires

Eventually:

Access Token → EXPIRED

Instead of showing the login page immediately, the application can use the refresh token.

Step 5 — Refresh the session

The client sends a request such as:

POST /api/refresh

The server validates the refresh token.

If everything is valid, it issues a new access token.

Old Access Token → Expired

Refresh Token
↓
Server validates
↓
New Access Token

The user can continue using the website without logging in again.

Why This Matters for Website Owners

For website owners and developers, refresh tokens aren't just about making authentication more complicated.

They can provide a better balance between security and user experience.

Shorter exposure for access tokens

Access tokens can have short lifetimes.

This reduces the period during which a stolen access token remains usable.

Better user experience

Users don't have to repeatedly enter their passwords.

They can remain signed in while the application silently obtains new access tokens.

Better session control

A properly designed refresh-token system can allow the server to revoke sessions.

For example:

User clicks "Log out from all devices"

↓

Server invalidates refresh tokens

↓

Existing sessions can no longer
refresh themselves

This is much more useful than simply waiting for a long-lived token to expire.

Device/session management

A website can maintain separate sessions for different devices.

For example:

Chrome - Malaysia
iPhone - Malaysia
Laptop - Bangladesh

Each session can have its own refresh token.

If one device is lost, its session can be revoked without necessarily logging the user out everywhere.

Access Token vs Refresh Token
Feature Access Token Refresh Token
Main purpose Access APIs Obtain new access tokens
Lifetime Short Longer
Sent with API requests Usually yes Usually no
Security sensitivity High Very high
Can be revoked server-side Depends on design Commonly
Should be exposed to JavaScript Minimize exposure Prefer HttpOnly cookie

The exact implementation depends on the application's architecture and threat model.

Important Security Practices

JWT itself doesn't automatically make an authentication system secure.

The implementation matters.

Use HTTPS

Never send authentication credentials or tokens over an unencrypted HTTP connection.

Use HTTPS/TLS in production.

Keep access tokens short-lived

Don't make an access token valid for an unnecessarily long period.

A short lifetime limits the damage from token theft.

Protect refresh tokens

For browser-based applications, an HttpOnly + Secure cookie is commonly used.

HttpOnly helps prevent JavaScript from directly reading the cookie.

Secure ensures the cookie is sent only over HTTPS.

Depending on the application, SameSite settings should also be configured appropriately.

Consider refresh-token rotation

Instead of reusing the exact same refresh token forever, the server can issue a new refresh token whenever one is successfully used.

The previous token can then be invalidated.

This is known as refresh-token rotation.

It can help detect and limit certain replay attacks.

Never store passwords inside JWTs

A JWT should never contain the user's password.

Passwords should be stored using an appropriate password hashing algorithm such as Argon2id or bcrypt.

Validate tokens properly

The server should verify important JWT properties such as:

Signature
Expiration
Issuer
Audience
Algorithm

The exact checks depend on the authentication architecture.

What Happens When a User Logs Out?

A common mistake is thinking:

"Deleting the JWT from the browser means the session is completely gone."

Not necessarily.

If a refresh token remains valid on the server, it may still be possible to create another access token.

A stronger logout design can invalidate the user's refresh session.

For example:

Logout
↓
Delete/clear client session
↓
Revoke refresh token
↓
Future refresh attempts fail

This gives the server more control over active sessions.

JWT Is Not a Complete Authentication System

This is probably the most important point.

JWT is simply a token format.

Using JWT doesn't automatically mean an application has secure authentication.

A secure authentication system also needs to consider:

Password hashing
HTTPS
Token expiration
Secure cookie configuration
CSRF protection where applicable
XSS protection
Refresh-token rotation
Session revocation
Rate limiting
Account recovery
Multi-factor authentication
Proper server-side authorization

JWT is one part of the system, not the entire system.

A Simple Mental Model

I like to think about it this way:

Access token = temporary access pass

Refresh token = credential used to obtain another temporary pass

For example:

The user experiences one continuous session, while the application can keep the actual API credential short-lived.

Final Thoughts

When building a modern application, authentication is not just about making the login button work.

It's about deciding:

How long should a session last?

What happens if a token is stolen?

How can a user stay logged in without keeping a powerful credential valid forever?

Refresh tokens provide one way to solve this problem.

Used correctly, the combination of short-lived access tokens + carefully protected refresh tokens + proper session management can give developers a practical balance between security and user experience.

But the important part is not simply adding JWT.

The real security comes from designing the entire authentication flow carefully.

So what should it be – WordPress or custom code? 19 questions every business owner needs to answer - The truth.

Ehan Siddique — Thu, 20 Aug 2026 17:09:36 +0000

“WordPress or custom coded?”
*
It is amongst the most recurrent queries businessmen usually ask while launching a new web page.

Plus, everyone will most likely say something completely different.

Some will tell you:

“WordPress is BASIC and OLD.”

Others will say:

“No, it is not necessary to make custom development – you can use WordPress.”

The reality is, however, that:

There is no right or wrong answer.

This will entirely rely on your business, objectives, budget and the true scope of functionality that you need your website to have.

What once started out as a “cheap website” is now considered by many as the most powerful blogging platform available online.

WordPress is not so easy to comprehend as people perceive it.

Yes, it can (affordably) be used to create web sites rapidly. Doesn't imply it implies that WordPress sites are low quality though.

The best-developed WordPress website can be:

Fast
Secure
SEO-friendly
Mobile-friendly
Easy to manage
Highly customizable

WordPress can be a great option for businesses because of its properties, such as a company website, portfolio, blog, landing page or online shop.

Its great benefit is content management.

Update pages, publish blogs, add products, change images and manage content without having to rely on a developer for each and every little bit of change.

That is very spacious to lots of businesses.

But what about web sites that are programmed in a custom code?

With custom development, the web or app will have a great deal of control over the websites or apps operation.

You don't have to conform to a pre-existing CMS and plugin community - instead, its own system can be tailored to suit your business.

This comes in handy when creating something more elaborate like:

SaaS platforms
Marketplaces
Customer portals
Advanced dashboards
Booking platforms
Complex business systems
Real-time applications

Standard WordPress tools may not work efficiently to suit unique functionality or workflow that your website has; in such instances, custom development may prove a better option.

What About Which one is Better?

There is the response that not many engineers don't want to have:

It depends.

With a website that needs a menu, location, contact info and restaurant bookings and has a blog, an expensive fully bespoke website may not be a feasible option for the restaurant owner.

WordPress can provide you with all you require.

However, in the case of an application that lots of users will be using each of whom will be creating accounts and developing business logic, managing dashboards and transactions, and interacting with other accounts, custom development might be the more intelligent option.

The object is NOT to pick a new high tech solution.

The objective is to select the technology that will be able to effectively solve your company's problems.

The 3 Biggest Myths

The fact that WordPress does not have good reputation for its performance.“WordPress is always slow.”

Not true.

Just as a poorly-constructed custom site can be slow, so, too, can a poorly-constructed WordPress site.

Things like hosting, image optimization, code quality, database configuration, plugins and caching, and third-party scripts, are among the factors that impact performance.

The most important thing to understand, and doing so will help your decision, is that “WordPress” or “custom” are not the things that matter most, GOOD DEVELOPMENT does.

“The second myth is that ‘Custom code is always more secure'”.

Not automatically.

Even with custom applications, these can be vulnerable to security issues if not managed properly – including authentication, API, database, permissions and/or dependencies.

Proper updating, secure plugins, robust authentication, backups and monitoring are also required for WordPress.

Security is not simply a choice of technology, it is a part of development and maintenance.

Myth #3: “Custom code is always more professional.”

However, a custom-coded site does not necessarily mean that it is better and, therefore, worth the time or money.

Use of WordPress isn't a compromise if it's getting the job done in solving your business needs.

Indeed, it isn't necessarily the more complex option if it achieves what you're after which is more professional.

People often focus just on the up-front development charges and not what the long-term consequences are.

The first error done by business entities is their taking just the starting price.

For example:

WordPress: Lower up-front development expenses.

Complexity: Custom means that more money will be required for the initial development.

However, there's more to that.

If that's the case, you must factor in also:

Hosting
Maintenance
Security
Updates
Future features
Developer support
Scalability

A website that is continually needing repairs and is cheap isn't necessarily cheap.

You don't want to have a costly custom-built system with components that you never utilize either.

Consider lifetime costs, rather than just development costs.

What should your company opt for?

If you are in need of, WordPress might be better suited for you:

✅ A company website

✅ A portfolio

✅ A blog

✅ A landing page

A website that's based on providing a service.

Online shop – with small to medium size clientele – = ✅

✅ Easy content management

🏃 A fast start, in comparison to the other projects.

If you need things such as: then it may be better to opt for tailor-made development:

✅ A SaaS product

✅ A complex marketplace

✅ Advanced dashboards

✅ Unique business workflows

✅ Complex integrations

✅ Real-time functionality

✅ Positive use cases to showcase the fit with the operation or industry of your interest

✅ A system in need of a full system control with the architecture.

Occasionally you may be able to select more than one.

The Hybrid Approach

It's one of the elements that many businesses might not have considered.

You can also utilize WordPress for your marketing site and website and use a customized made application for complicated features.

For example:

yourbusiness.com → WordPress

app.yourbusiness.com → Custom application

This helps marketers quickly make changes to the website content and the development team to create website-specific functions.

At times, this is the most convenient alternative.

In this video, you'll learn the questions you need to ask before hiring a developer.This video is about the questions you should ask prior to hiring a developer.

Avoid beginning with questions:

“Let's figure out is it better to use WordPress or to pay attention to custom code?”

Decide upon the following question starters:

What are the requirements of my business?

Avoid paying for features that you don't need to use.

Who will handle maintenance of the Web site?

When frequent updates to content are a regular occurrence for your team, ease-of-management is key.

**3. What is the anticipated increase in the size of the business?

The technology you select is for the future, so your future needs should be taken into consideration.

What are maintenance fees going to be?

Inquire about updates, hosting, security and backups and ongoing support.

5: Does the site have potential to expand as my company expands?

You shouldn't be stuck with a website that will not do the job when your enterprise grows.

The Bottom Line

“WordPress isn't necessarily bad.”

This doesn't mean that custom code has to be better.

Especially, because the most costly web page does not always necessarily mean the best!

The top Web page will be the one that:

Helps to solve your business problem
Provides a nice customer experience
Performs reliably
Does not need extensive cleaning up.
Can be adapted to suit a business's needs and scale of operations as it grows
Fits your budget

Therefore, before selecting any technology know what your business needs are.

Do not create an internet site due to the fact that a developer claims the site is “better” doing his or her intervention.

Create a website for your business that it really requires.

Would you opt for WordPress, or is it completely developed? Or is it a mix of the two?

If you have any comments feel free to write me.

DEV Community: Ehan Siddique

Farmora: my Next.js shop stalled up to 6s a page, so I made it local-first

What Farmora is

Fehan999 / Farmora

Farmora 🌱

Try it

Why I built it

Architecture

1. A data layer that never makes the page wait

2. Loading Firebase when the browser is idle

3. Commission math in one place

4. A delivery tracker with no background job

5. Images: srcset, fallbacks, and a workflow that checks every photo

6. SEO with JSON-LD and generated OG images

7. Demo accounts for visitors

How I tested it

Lessons learned

Limitations and what's next

Try it

7 Real Problems I Faced While Building a Real-Time Chat Application

1. Managing Real-Time Messages Without Duplicates or Unexpected Updates

How I approached the problem

2. Preventing Duplicate Conversations Between Two Users

How I solved it

3. Making Unread Messages and Read Receipts Work Correctly

How I approached the problem

4. Building Accurate Online Status and Typing Indicators

How I approached the problem

5. Getting WebRTC Voice and Video Calls to Connect

The ICE candidate problem

How I solved it

6. Fixing Audio Playback and Handling Browser Restrictions

How I approached the problem

7. Handling File Uploads and Firebase Storage CORS Errors

How I approached the problem

What Building ChatLoop Taught Me About Real-World Development

My Advice to Developers Building Their First Real-Time Application

Final Thoughts

I Built a Real-Time Chat App with React, Firebase, WebRTC & Gemini AI — Here’s What I Learned

What is ChatLoop?

1. Real-Time Messaging Was More Than onSnapshot()

2. I Didn't Want Hundreds of Unnecessary Listeners

3. Building User Presence Was Surprisingly Interesting

4. Then I Added WebRTC Calls

5. Race Conditions Matter

6. Opening the Call Screen Immediately

7. Network Changes Are Another Problem

8. Voice Notes and File Uploads

9. Friend Requests Became Their Own System

10. I Added Gemini AI as Another Conversation

11. Markdown Without dangerouslySetInnerHTML

12. Building the Admin Panel Changed the Project

13. I Also Built a Read-Only Guest Admin

14. The UI Is Not Security

15. Reporting and Suspensions

16. Admin Announcements

17. Organizing the Codebase

18. Some Things I Would Change at Larger Scale

User search

TURN infrastructure

Group conversations

19. What I Learned

Final Thoughts

AI Won't Replace Web Developers—But Developers Who Use AI May Replace Those Who Don't

But There's a Problem

JWT Refresh Tokens: How They Make Login Systems Safer and More Practical

So what should it be – WordPress or custom code? 19 questions every business owner needs to answer - The truth.

The 3 Biggest Myths

The Hybrid Approach

5: Does the site have potential to expand as my company expands?

The Bottom Line

1. Real-Time Messaging Was More Than `onSnapshot()`

11. Markdown Without `dangerouslySetInnerHTML`