DEV Community: Shpëtim Islami ⚡

Why I Built My Own WebSocket Service Instead of Paying for Pusher

Shpëtim Islami ⚡ — Wed, 01 Apr 2026 19:52:34 +0000

Real-time features look simple from the outside.

A chat message appears instantly. A dashboard updates without refresh. A notification badge increments in the corner. A "someone is typing..." indicator just works.

But once you try to build those features into a product, you run into a very different reality:

WebSocket connections need to stay alive reliably
Private channels need authentication
Presence needs user tracking
Fanout needs to work across multiple nodes
Webhooks need retries
Usage needs to be measured
Costs get weird as usage grows

At some point I realized I had two options:

Keep paying for a hosted real-time provider and accept the tradeoffs
Build the service I actually wanted

I picked option 2.

That decision turned into Apinator: a real-time messaging platform and Pusher-style alternative with public, private, and presence channels, multi-tenant isolation, usage metering, and SDKs for Node.js, Python, PHP, Go, and browser clients.

This post is the story of why I built it, what turned out to be harder than expected, and when building your own WebSocket infrastructure is absolutely the wrong idea.

The Original Problem

I didn’t start with the goal of "building a WebSocket company."

I started with a much more ordinary product need: I wanted reliable real-time features without handing over a core part of the stack to a black box I couldn’t control.

The usual hosted tools are good at getting you started. In many cases, they are the correct choice. You can ship quickly, wire up a client SDK, and move on.

But the deeper I got into real production requirements, the more the friction showed up:

I wanted predictable control over the infrastructure
I wanted multi-tenant behavior that matched my own product model
I wanted to understand exactly how auth, fanout, and presence behaved
I wanted better cost characteristics as usage increased
I wanted the option to self-host the core infrastructure

None of these problems are obvious in a simple demo. They show up later, when real traffic, retries, and operational edge cases start mattering.

That was the point where "just use a hosted provider" stopped feeling like a complete answer.

The Misleading Part About Real-Time Infrastructure

The misleading thing about WebSocket products is that the happy path is tiny.

If you reduce the problem enough, a WebSocket service is just:

{"event":"message-created","channel":"chat-room","data":"{\"text\":\"hello\"}"}

That part is easy.

The hard part is everything around it.

A real platform needs answers to questions like:

How do clients authenticate subscriptions to private channels?
How do presence channels track members across reconnects and multiple tabs?
How do you fan out events across multiple servers?
How do you verify webhook authenticity?
How do you enforce plan limits without turning the hot path into a bottleneck?
How do you expose useful SDKs without making every language feel like a second-class citizen?

This is where a lot of "simple WebSocket server" projects stop being simple.

Why I Didn’t Want a Thin Wrapper

I wasn’t interested in building a toy socket server that worked in development and fell apart under real product constraints.

If I was going to do this, it needed to cover the boring but important parts:

public channels
private channels with HMAC auth
presence channels with member tracking
webhook delivery
usage accounting
rate limiting
multi-tenant isolation
support for multiple regions

That immediately changed the shape of the system.

Instead of one process doing everything, I split the architecture into a control plane and a data plane.

At a high level:

The control plane handles accounts, app configuration and management APIs
The data plane handles WebSocket connections, event publishing, channel auth, and real-time fanout
Redis sits on the hot path for fanout, caching, counters, and rate limiting
PostgreSQL stays in the control plane where consistency matters more than latency

That separation ended up being one of the best decisions in the project.

The Architecture I Ended Up Building

Apinator is built in Go as a multi-tenant WebSocket system with distinct binaries for the control plane, data plane, migrations, and webhook worker.

The core pieces look like this:

api: account management, config, and internal APIs
realtime: the WebSocket data plane
worker: webhook delivery with retries
migrate: database migrations

The data plane has no direct PostgreSQL dependency. It resolves tenant configuration through Redis with an internal API fallback.

That matters because the data plane is the part that needs to stay lean. Every extra dependency in the critical path shows up under load.

A few specific decisions were especially important.

1. Redis for fanout, not just caching

I used Redis Pub/Sub for cross-node event fanout, plus ref-counted subscriptions so nodes only stay subscribed to channels that actually have connected clients.

Without something like that, horizontal scaling becomes fake. You can add more nodes, but events don’t reach all connected subscribers reliably.

2. HMAC auth for private and presence channels

Private and presence subscriptions need server-side authorization. That means the browser cannot be trusted to decide who can subscribe to what.

So the flow is:

The client asks to subscribe
Your backend authenticates the user
Your backend signs the channel subscription
The WebSocket service validates the signature

That sounds standard, because it is. But getting the ergonomics right across SDKs matters a lot.

3. Presence is more annoying than it looks

Presence is not "just a list of users online."

You have reconnects, multiple tabs, transport flapping, disconnect timing, and the question of when someone should count as present. If the same user has three tabs open, are they one member or three?

Those edge cases are where presence systems get messy fast.

4. Webhooks need a delivery model, not a POST request

It is easy to say "send a webhook when X happens."

It is harder to answer:

What if the destination is down?
What if it times out?
What if it returns 500 three times?
What if you need signature verification?

That pushed me toward a transactional outbox pattern and a dedicated worker with retry logic and backoff instead of "fire and hope."

5. Limits belong in the design early

This is one of the least glamorous parts, which is why it gets skipped.

But if you’re building a multi-tenant platform, usage accounting is not an add-on. It shapes the whole system.

You need to know what you are counting, where you are counting it, and how much consistency you actually need. If you leave that vague, you end up retrofitting it into the hottest code path later.

That is a bad place to discover you need atomic counters.

What Was Harder Than I Expected

A few things were clearly harder than I expected.

Connection lifecycle edge cases

Most bugs in real-time systems are not in the initial connect flow. They are in reconnects, dropped sockets, duplicate subscriptions, stale presence members, race conditions during auth, and weird timing windows when clients come and go quickly.

Keeping the SDKs consistent

It’s one thing to build the backend.

It’s another to make the developer experience feel coherent across Node.js, Python, PHP, Go, and browser clients. If each SDK has different naming, behavior, or auth assumptions, the platform feels unreliable even if the backend is correct.

Avoiding "accidental complexity"

There is always a temptation to keep adding platform features because you are already deep in infrastructure land.

I had to keep pulling the design back to the core question:

What does a developer actually need to publish an event, authenticate a channel, and trust the system in production?

If the answer didn’t support that, it probably didn’t belong in the first version.

What I’d Do Differently

If I were starting from scratch again, I would do a few things earlier:

Define operational metrics sooner
Write more failure-mode tests before polishing APIs
Be even stricter about keeping the hot path small
Treat SDK ergonomics as part of the product, not follow-up work

That last point matters more than it sounds.

Infrastructure products win partly on correctness, but they also win on how little cognitive load they add to the developer using them.

When You Should Not Build Your Own WebSocket Service

To be clear: most teams should not build this.

If your need is "I want chat, notifications, or presence working this week," use a hosted provider and move on.

Building real-time infrastructure is only rational if at least one of these is true:

real-time is central to your product
you need tighter control over behavior or deployment
your cost profile makes third-party pricing painful
you want self-hosting as a product or compliance requirement
you are willing to own the operational complexity

If none of that applies, don’t romanticize infrastructure work. It is very easy to turn months of engineering time into a more fragile version of something you could have bought.

Why I’m Still Glad I Built It

Even with all of that, I’m glad I built it.

Not because it was easy. It wasn’t.

Not because I think every existing provider is bad. I don’t.

I’m glad I built it because I wanted a real-time platform whose internals I understood, whose tradeoffs I chose deliberately, and whose developer experience matched the way I think real-time features should be integrated into modern apps.

That became Apinator.

Today it supports:

public, private, and presence channels
server-side event publishing
webhook verification
multi-tenant apps
usage metering and plan enforcement
SDKs for Node.js, Python, PHP, Go, and browser clients

It is the service I originally wanted to use.

If You’re Building Real-Time Features

If you are working on chat, live dashboards, collaborative UIs, notifications, or presence, the main lesson I learned is this:

Real-time is not hard because of WebSockets.

It is hard because of everything around WebSockets.

That’s the part the glossy demos skip.

If you want to see what that looks like as a product, you can check out Apinator.

If there’s interest, I can write a follow-up post breaking down the technical architecture in more detail, including channel auth, presence design, multi-node fanout, and webhook delivery.

Build a Real-Time Chat App with Next.js

Shpëtim Islami ⚡ — Tue, 17 Feb 2026 03:21:02 +0000

If you've ever used Websockets to add real-time features to a web app, you know how powerful WebSockets can be — and how quickly costs can spiral. Apinator is a drop-in alternative: a hosted real-time messaging platform with a Pusher-compatible SDK, private/presence channel support, and usage-based pricing that doesn't punish you for growing.

In this tutorial we'll build a fully working real-time chat room from scratch using Next.js 14 (App Router) and Apinator. By the end you'll have:

A live chat UI where messages appear instantly for all connected users
Private channel authentication (no anonymous broadcasting)
Presence indicators showing who's currently online
Clean, production-ready code you can extend for notifications, live cursors, or collaborative editing

What is Apinator?

Apinator provides hosted WebSocket infrastructure so you don't have to manage your own socket servers. You publish events from your backend; your frontend clients receive them in milliseconds across any number of connected users.

Key concepts:

Concept	Description
App	An isolated namespace with its own key/secret pair
Channel	A named pub/sub topic clients subscribe to
Public channel	Anyone can subscribe (e.g. `chat-room`)
Private channel	Requires server-side auth (prefix: `private-`)
Presence channel	Auth + online member list (prefix: `presence-`)
Event	A named message published to a channel

Prerequisites

Node.js 18+
A free apinator.io account
Basic familiarity with Next.js App Router

Step 1 — Create an Apinator App

Sign in to the Apinator console
Click New App, give it a name (e.g. nextjs-chat), choose a cluster (eu or us)
From the app's Keys page, copy:
- App ID
- Key (public)
- Secret (keep this server-side only)

Step 2 — Bootstrap the Next.js Project

npx create-next-app@latest realtime-chat --typescript --tailwind --app
cd realtime-chat

Install the Apinator SDKs:

npm install @apinator/client @apinator/server

@apinator/client — browser client (WebSocket, channel subscriptions)
@apinator/server — server-side client (trigger events, sign channel auth)

Add your credentials to .env.local:

# Public — safe to expose to the browser
NEXT_PUBLIC_APINATOR_KEY=your_key
NEXT_PUBLIC_APINATOR_CLUSTER=eu

# Private — server only
APINATOR_APP_ID=your_app_id
APINATOR_SECRET=your_secret

Step 3 — Server-Side: Channel Auth Endpoint

Private channels require your server to sign the subscription. Create the auth route:

// app/api/auth/channel/route.ts
import { NextRequest, NextResponse } from "next/server";
import { Apinator } from "@apinator/server";

const apinator = new Apinator({
  appId: process.env.APINATOR_APP_ID!,
  key: process.env.NEXT_PUBLIC_APINATOR_KEY!,
  secret: process.env.APINATOR_SECRET!,
  cluster: process.env.NEXT_PUBLIC_APINATOR_CLUSTER! as "eu" | "us",
});

export async function POST(req: NextRequest) {
  const { socket_id, channel_name, username } = await req.json();

  if (!socket_id || !channel_name) {
    return NextResponse.json({ error: "Missing params" }, { status: 400 });
  }

  // In a real app, verify the user's session here before signing
  const channelData =
    channel_name.startsWith("presence-")
      ? JSON.stringify({
          user_id: socket_id, // use a real user ID from your auth system
          user_info: { name: username ?? "Anonymous" },
        })
      : undefined;

  const auth = apinator.authenticateChannel(socket_id, channel_name, channelData);
  return NextResponse.json(auth);
}

Step 4 — Server-Side: Send Messages

Add an API route to receive new messages and broadcast them via Apinator:

// app/api/messages/route.ts
import { NextRequest, NextResponse } from "next/server";
import { Apinator } from "@apinator/server";

const apinator = new Apinator({
  appId: process.env.APINATOR_APP_ID!,
  key: process.env.NEXT_PUBLIC_APINATOR_KEY!,
  secret: process.env.APINATOR_SECRET!,
  cluster: process.env.NEXT_PUBLIC_APINATOR_CLUSTER! as "eu" | "us",
});

export async function POST(req: NextRequest) {
  const { text, username, socketId } = await req.json();

  if (!text?.trim()) {
    return NextResponse.json({ error: "Empty message" }, { status: 400 });
  }

  await apinator.trigger({
    name: "new-message",
    channel: "presence-chat-room",
    data: JSON.stringify({
      text: text.trim(),
      username: username ?? "Anonymous",
      timestamp: Date.now(),
    }),
    // Exclude the sender's own socket so they don't receive an echo
    socketId,
  });

  return NextResponse.json({ ok: true });
}

The socketId exclusion is optional but gives a snappier UX — the sender sees their message immediately from local state while everyone else receives it via WebSocket.

Step 5 — Client-Side: The Chat Hook

Create a custom hook that manages the Apinator connection and channel subscription:

// hooks/useChat.ts
"use client";

import { useEffect, useRef, useState, useCallback } from "react";
import { Apinator, type PresenceChannel } from "@apinator/client";

export type ChatMessage = {
  id: string;
  text: string;
  username: string;
  timestamp: number;
  self: boolean;
};

export type OnlineMember = {
  user_id: string;
  user_info: { name: string };
};

export function useChat(username: string) {
  const [messages, setMessages] = useState<ChatMessage[]>([]);
  const [members, setMembers] = useState<OnlineMember[]>([]);
  const [connected, setConnected] = useState(false);
  const clientRef = useRef<Apinator | null>(null);
  const socketIdRef = useRef<string | null>(null);

  useEffect(() => {
    const client = new Apinator({
      key: process.env.NEXT_PUBLIC_APINATOR_KEY!,
      cluster: process.env.NEXT_PUBLIC_APINATOR_CLUSTER! as "eu" | "us",
      authEndpoint: "/api/auth/channel",
      // Pass the username so the auth endpoint can include it in channel_data
      authHeaders: { "x-username": username },
    });

    client.connect();
    clientRef.current = client;

    client.bind("state_change", ({ current }: { current: string }) => {
      setConnected(current === "connected");
    });

    // Subscribe to a presence channel so we get the online member list
    const channel = client.subscribe("presence-chat-room") as PresenceChannel;

    channel.bind("realtime:subscription_succeeded", () => {
      const memberList = channel.getMembers() as OnlineMember[];
      setMembers(memberList);
    });

    channel.bind("realtime:member_added", (member: OnlineMember) => {
      setMembers((prev) => [...prev, member]);
    });

    channel.bind("realtime:member_removed", ({ user_id }: { user_id: string }) => {
      setMembers((prev) => prev.filter((m) => m.user_id !== user_id));
    });

    channel.bind("new-message", (data: Omit<ChatMessage, "id" | "self">) => {
      setMessages((prev) => [
        ...prev,
        {
          ...data,
          id: `${data.timestamp}-${Math.random()}`,
          self: false,
        },
      ]);
    });

    return () => {
      client.unsubscribe("presence-chat-room");
      client.disconnect();
    };
  }, [username]);

  const sendMessage = useCallback(
    async (text: string) => {
      if (!text.trim()) return;

      const socketId = clientRef.current?.socketId ?? undefined;

      // Optimistically add the message locally
      setMessages((prev) => [
        ...prev,
        {
          id: `${Date.now()}-self`,
          text,
          username,
          timestamp: Date.now(),
          self: true,
        },
      ]);

      await fetch("/api/messages", {
        method: "POST",
        headers: { "Content-Type": "application/json" },
        body: JSON.stringify({ text, username, socketId }),
      });
    },
    [username]
  );

  return { messages, members, connected, sendMessage };
}

Step 6 — Client-Side: Chat UI

// app/chat/page.tsx
"use client";

import { useState, useRef, useEffect, FormEvent } from "react";
import { useChat } from "@/hooks/useChat";

export default function ChatPage() {
  const [username] = useState(
    () => `User${Math.floor(Math.random() * 1000)}`
  );
  const { messages, members, connected, sendMessage } = useChat(username);
  const [input, setInput] = useState("");
  const bottomRef = useRef<HTMLDivElement>(null);

  useEffect(() => {
    bottomRef.current?.scrollIntoView({ behavior: "smooth" });
  }, [messages]);

  async function handleSubmit(e: FormEvent) {
    e.preventDefault();
    if (!input.trim()) return;
    await sendMessage(input);
    setInput("");
  }

  return (
    <div className="flex h-screen bg-gray-50">
      {/* Sidebar — online members */}
      <aside className="w-56 bg-white border-r p-4 flex flex-col gap-2">
        <h2 className="text-sm font-semibold text-gray-500 uppercase tracking-wide">
          Online — {members.length}
        </h2>
        {members.map((m) => (
          <div key={m.user_id} className="flex items-center gap-2">
            <span className="w-2 h-2 rounded-full bg-green-400" />
            <span className="text-sm text-gray-700">{m.user_info.name}</span>
          </div>
        ))}
      </aside>

      {/* Chat area */}
      <div className="flex-1 flex flex-col">
        {/* Header */}
        <header className="border-b px-6 py-3 bg-white flex items-center gap-3">
          <span className="font-semibold text-gray-800">#general</span>
          <span
            className={`text-xs px-2 py-0.5 rounded-full ${
              connected
                ? "bg-green-100 text-green-700"
                : "bg-yellow-100 text-yellow-700"
            }`}
          >
            {connected ? "Connected" : "Connecting…"}
          </span>
        </header>

        {/* Messages */}
        <div className="flex-1 overflow-y-auto px-6 py-4 flex flex-col gap-3">
          {messages.map((msg) => (
            <div
              key={msg.id}
              className={`flex flex-col ${msg.self ? "items-end" : "items-start"}`}
            >
              <span className="text-xs text-gray-400 mb-1">{msg.username}</span>
              <div
                className={`px-4 py-2 rounded-2xl text-sm max-w-xs ${
                  msg.self
                    ? "bg-blue-500 text-white rounded-tr-sm"
                    : "bg-white text-gray-800 shadow-sm rounded-tl-sm"
                }`}
              >
                {msg.text}
              </div>
            </div>
          ))}
          <div ref={bottomRef} />
        </div>

        {/* Input */}
        <form
          onSubmit={handleSubmit}
          className="border-t px-6 py-4 bg-white flex gap-3"
        >
          <input
            value={input}
            onChange={(e) => setInput(e.target.value)}
            placeholder="Type a message…"
            className="flex-1 rounded-full border px-4 py-2 text-sm outline-none focus:ring-2 focus:ring-blue-300"
          />
          <button
            type="submit"
            disabled={!input.trim() || !connected}
            className="bg-blue-500 text-white rounded-full px-5 py-2 text-sm font-medium disabled:opacity-40"
          >
            Send
          </button>
        </form>
      </div>
    </div>
  );
}

Step 7 — Fix the Auth Endpoint to Use Headers

Update the auth route to read the username from the request header:

// app/api/auth/channel/route.ts  (updated section)
const username = req.headers.get("x-username") ?? "Anonymous";

Run It

npm run dev

Open http://localhost:3000/chat in two browser tabs. Type a message in one — it appears instantly in the other.

How It Works (Architecture Overview)

Browser A                  Next.js Server            Apinator
   |                            |                        |
   |-- POST /api/messages ------>|                        |
   |                            |-- trigger(event) ------>|
   |                            |                        |
   |<-- WebSocket push ------------------------------------|
Browser B                                               |
   |<-- WebSocket push ------------------------------------|

User submits a message → hits your Next.js API route
API route calls apinator.trigger() to publish the event
Apinator fans out the event to all connected WebSocket clients subscribed to that channel
The sender's own socket is excluded (via socketId) to avoid double-rendering

What to Build Next

Private DMs — Create a channel per user pair: private-dm-{userId1}-{userId2}. The auth endpoint checks that the requesting user is one of the participants.

Typing indicators — Use Apinator's client events (client- prefix). These travel peer-to-peer through the server without hitting your API:

channel.trigger("client-typing", { username });
channel.bind("client-typing", ({ username }) => showTyping(username));

Notifications — Subscribe users to a private private-user-{id} channel on login. Trigger events from any backend service to push notifications in real time.

Webhook processing — Use client.verifyWebhook(headers, body) to securely receive delivery confirmations and channel lifecycle events from Apinator.

Closing Thoughts

Apinator gets you from zero to real-time in under an hour with a clean, well-typed SDK that feels right at home in a TypeScript/Next.js project. The same mental model (apps → channels → events) scales from a weekend project to production traffic without re-architecting.

How to implement Laravel CI/CD with Bitbucket and AWS

Shpëtim Islami ⚡ — Thu, 12 Mar 2020 00:13:25 +0000

If you never did CI/CD implementation of your Laravel project before, then start with Bitbucket pipelines because its easy.

If you did CI/CD implementation of Laravel before then use Bitbucket pipelines because it has a lot of free build time.

Now lets get into it..

Here in line 5 under branches we say when commit is pushed to master branch to run the following:

Create 2 zip files excluding the vendor folder, and they both run in parallel defined by the parallel tag on line 6.

Then again in line 19 we define 2 processes to run in parallel, they deploy to 2 different beanstalk environments. 1 is for web serving instance/s and the other is for the queue instance/s.

To use this you will need to:

Create 1 application in AWS Beanstalk with 2 environments (web and queue worker).
Create an S3 bucket
Obtain your AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY and AWS_DEFAULT_REGION

replace them with the placeholders and add this file called bitbucket-pipelines.yml into the root of your projects git repository.

If you followed this how to guide, when you push something to master this is how it looks like in Bitbucket:

The next step would be that you run unit tests before the deployment steps.

Have a happy deployment, cheers.