Forem: Deepraj Baidya

Build your own Posthog - PART 2

Deepraj Baidya — Thu, 04 Sep 2025 13:53:55 +0000

Welcome to Part 2 of this series. In this installment, we'll dive deep into the infrastructure setup, Docker containerization, and the critical API Gateway implementation that serves as the backbone of our analytics system. We'll walk through the complete file structure and explain every component in detail.

Now before we start I gotta tell you what exactly is an API-Gateway and why it is required in this project.

What ?

An *API Gatewa*y is a server that acts as an intermediary layer between client applications and backend services. Think of it as a "traffic controller" or "front door" that sits between clients (like mobile apps, web applications, or third-party integrations) and internal microservices.

Why ?

In SmolHog's architecture, the API Gateway serves as the single entry point for all analytics requests, handling the complexity of routing requests to appropriate backend services while providing essential cross-cutting functionalities like:

Centalized Requests : Without an API Gateway,the Dashboard & the Flutter SDK would need to know about multiple backend services and their individual endpoints.
Cross-Origin Resource Sharing (CORS) Management : Handles browser security restrictions in one place, allowing web-based analytics dashboard and Flutter web apps to make cross-origin requests safely.
Request / Response Logging : Track response times for all requests

Now that we have a good idea of what an API Gateway really is, let's now move forward and setup our project.

Project Structure :

We've opted for a well-organized monorepo structure that separates concerns while making it easy for development workflows. Let's examine the complete directory structure:

.
├── docker-compose.yml
├── Makefile
├── infra
│   ├── backend
│   │   ├── api-gateway
│   │   ├── event-processor  
│   │   └── workers
│   └── frontend
│       ├── app
│       └── node_modules
├── migrations
└── smolhog_flutter
    ├── example
    └── lib

Setting up our Docker Images :

SmolHog depends on various different tools like PostgreSQL & RabbitMQ and to have them integrated with our project we will use Docker and set up the images.

The docker-compose.yml file is the orchestration masterpiece that brings together all our services. Let's break it down section by section:

docker-compose.yml

postgres:
  image: postgres:latest
  environment:
    POSTGRES_DB: smolhog_analytics
    POSTGRES_USER: user
    POSTGRES_PASSWORD: password
  ports:
    - "5432:5432"
  volumes:
    - postgres_data:/var/lib/postgresql/data
    - ./migrations:/docker-entrypoint-initdb.d/
  networks:
    - smolhog-network

rabbitmq:
  image: rabbitmq:4.0-management
  ports:
    - "5672:5672"    # AMQP protocol port
    - "15672:15672"  # Management UI port
  networks:
    - smolhog-network

volumes:
  postgres_data

networks:
  smolhog-network:
    driver: bridge

./migrations:/docker-entrypoint-initdb.d/ automatically runs SQL migration scripts when the container first starts, perfect for setting up event tables, indexes, and initial schema
postgres_data creates a Docker-managed volume that persists independently of container lifecycles. This means the analytics data remains intact even during development container rebuilds.
smolhog-network creates an isolated bridge network where all SmolHog services can communicate using service names as hostnames.
RabbitMQ 4.0 with management plugin provides both messaging capabilities and a web-based monitoring interface

It's time to create our API-Gateway, for this we'll use Typescript and Express.js

API Gateway :

Install the required dependencies using any of your favourite JavaScript/TypeScript runtimes and configure the dependencies like this.

infra/backend/api-gateway/index.ts is where we're writing the code for our API Gateway.

import cors from 'cors';
import express from "express";
import { createProxyMiddleware } from 'http-proxy-middleware';

const app = express();
const PORT = process.env.PORT || 3001;
const API_URL = process.env.EVENT_PROCESSOR_URL || 'http://localhost:8000';

Adding the CORS Configuration

app.use(cors({
    origin: '*',
    methods: ['GET', 'POST', "OPTIONS"],
    allowedHeaders: ['Content-Type', 'Authorization']
}));

Proxy Helper creates reusable proxy configuration with error handling and request/response logging.

app.use(express.json());

app.get('/', (req, res) => {
    res.json({ message: "Welcome to SmolHog API Gateway" });
});

const createProxyOptions = (pathRewrite: { [key: string]: string }) => ({
    target: API_URL,
    changeOrigin: true,
    pathRewrite,
    onError: (err: Error, req: express.Request, res: express.Response) => {
        console.error('Proxy Error:', err.message);
        console.error('Target URL:', API_URL);
        console.error('Request URL:', req.url);
        res.status(500).json({ error: 'Proxy error', message: err.message });
    },
    onProxyReq: (proxyReq: any, req: express.Request, res: express.Response) => {
        Object.keys(req.headers).forEach(key => {
            proxyReq.setHeader(key, req.headers[key]);
        });
        console.log(`Proxying ${req.method} ${req.url} to ${API_URL}${proxyReq.path}`);
    }
});

Request Logging Middleware to log the incoming requests and outgoing responses for us to be able to track and monitor the Service.


app.use((req, res, next) => {
    const startTime = Date.now();

    console.log(`[${new Date().toISOString()}] ${req.method} ${req.url}`);
    console.log(`Headers: ${JSON.stringify(req.headers, null, 2)}`);
    console.log(`Query: ${JSON.stringify(req.query, null, 2)}`);
    if (req.body && Object.keys(req.body).length > 0) {
        console.log(`Body: ${JSON.stringify(req.body, null, 2)}`);
    }

    const originalEnd = res.end;
    res.end = function (chunk, encoding, cb) {
        const duration = Date.now() - startTime;
        console.log(`[${new Date().toISOString()}] ${req.method} ${req.url} - ${res.statusCode} - ${duration}ms`);

        if (res.statusCode >= 400) {
            console.error(`Error Response: Status ${res.statusCode}`);
            if (chunk) {
                console.error(`Error Body: ${chunk.toString()}`);
            }
        }

        return originalEnd.call(this, chunk, encoding, cb);
    };

    next();
});

Now we'll be adding the last part(code) of our API Gateway, which is mapping ports and configuring the routing. Our Event Processor has 3 routes /events, /analytics/events and analytics/stats , we're gonna map them to /api/* so that when someone hits the API Gateway's api endpoint we can redirect the request to our original Event Processor's endpoint.

app.use('/api/events', createProxyMiddleware(createProxyOptions({
    '^/': '/events'
})));

app.use('/api/analytics/events', createProxyMiddleware(createProxyOptions({
    '^/': '/analytics/events'
})));

app.use('/api/analytics/stats', createProxyMiddleware(createProxyOptions({
    '^/': '/analytics/stats'
})));

app.listen(PORT, () => {
    console.log(`SmolHog Gateway listening on http://localhost:${PORT}`);
    console.log(`Proxying requests to: ${API_URL}`);
});

We've completed the creation of our API Gateway and now it's time to containerise it, for this we'll create a Dockerfile in our infra/backend/api-gateway directory.

infra/backend/api-gateway/Dockerfile

FROM oven/bun:1.2.18-alpine AS base
WORKDIR /app
COPY package*.json ./
RUN bun install

FROM base
COPY . .
EXPOSE 3001
CMD ["bun", "run", "dev"]

And finally we'll add the api-gateway service to our docker-compose.yml file present at the very front, so that we can spawn every service at once with just one single command.

docker-compose.yml

postgres:
  image: postgres:latest
  environment:
    POSTGRES_DB: smolhog_analytics
    POSTGRES_USER: user
    POSTGRES_PASSWORD: password
  ports:
    - "5432:5432"
  volumes:
    - postgres_data:/var/lib/postgresql/data
    - ./migrations:/docker-entrypoint-initdb.d/
  networks:
    - smolhog-network

rabbitmq:
  image: rabbitmq:4.0-management
  ports:
    - "5672:5672"    # AMQP protocol port
    - "15672:15672"  # Management UI port
  networks:
    - smolhog-network

  api-gateway:
    build:
      context: ./infra/backend/api-gateway
    ports:
      - "3001:3001"
    volumes:
      - ./infra/backend/api-gateway:/app
      - /app/node_modules
    environment:
      - EVENT_PROCESSOR_URL=http://event-processor:8000
    depends_on:
      - event-processor
    networks:
      - smolhog-network

volumes:
  postgres_data

networks:
  smolhog-network:
    driver: bridge

As you can tell our API Gateway service depends on the Event Processor, which we'll configure in the next part of this blog.

Production Ready VPS in Minutes

Deepraj Baidya — Fri, 29 Aug 2025 09:47:48 +0000

When deploying a Virtual Private Server (VPS) for production use, security should be your top priority. A freshly provisioned server comes with default configurations that prioritize accessibility over security—fine for development, but dangerous in production environments. This guide walks you through essential hardening steps that transform your VPS from vulnerable to production-ready.

Before everything else we need a VPS, for which we will be using DigitalOcean, here's a quick tutorial on how to create a Droplet on DigitalOcean.

Now let's get into securing and making our VPS Production ready.

1. Initial System Updates

sudo apt update && sudo apt upgrade -y
shutdown now -r

Why this matters:

Fresh server images often contain outdated packages with known vulnerabilities. The first line updates your package lists and upgrades all installed packages to their latest versions. The immediate reboot ensures any kernel updates take effect and that your server starts clean with the latest security patches.

Best practice: Always perform this step before making any configuration changes, as package updates can sometimes reset configuration files.

2. Creating a Dedicated User Account

sudo adduser <username>
sudo usermod -aG sudo <username>
su - <username>

NOTE: Change the with the username you want to add

Running administrative tasks as root violates the principle of least privilege. By creating a dedicated user account, you reduce the blast radius of potential security breaches and create an audit trail for administrative actions.

What happens here :

adduser creates a new user with a home directory
usermod -aG sudo grants the user administrative privileges through the sudo group
su - <username> switches to the new user context

3. SSH Key Authentication Setup

mkdir -p ~/.ssh
chmod 700 ~/.ssh
touch ~/.ssh/authorized_keys
echo "your_public_key_here" > ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

Password authentication is inherently weak—passwords can be brute-forced, guessed, or compromised through data breaches. SSH keys provide cryptographic authentication that's exponentially more secure.

Directory permissions explained:

700 on .ssh directory: Only the owner can read, write, or execute
600 on authorized_keys: Only the owner can read or write the file

These restrictive permissions are crucial—SSH will refuse to use keys with overly permissive access.

4. SSH Hardening Configuration

sudo vi /etc/ssh/sshd_config

Critical configuration changes (sshd_config) file:

PermitRootLogin no
usePAM no  
PasswordAuthentication no

exit the file and then on your terminal

sudo systemctl restart ssh

Why this matters

PermitRootLogin no: Prevents direct root access via SSH, forcing attackers to compromise a user account first, then escalate privileges
usePAM no: Disables Pluggable Authentication Modules for SSH, reducing the attack surface
PasswordAuthentication no: Completely disables password-based authentication, making brute-force attacks ineffective

Important: Test your SSH key authentication before implementing these changes. Once password authentication is disabled, key-based access becomes your only entry method.

One additional hardening measure worth considering is changing SSH from its default port 22 to a custom port. While this provides security benefits, it comes with significant operational overhead (we're not going to cover it in this blog).

5. Streamlined SSH Access

Most of our configuration is done, but we can still make the process of connecting to our VPS a bit more smooth, see now everytime we need to connect to our VPS we have to pass the private-key, here a fix for that.

In your local machine's terminal

vi ~/.ssh/config

SSH config file:

Host your-server-nickname
    HostName your_server_ip
    User <username>
    IdentityFile path_to_your_private_key
    IdentitiesOnly yes

NOTE: The username should be the same that we created in step 2 of this tutorial.

Benefits:

Operational benefits:

Now you can just use ssh server-nickname instead of lengthy commands to connect to your VPS.
IdentitiesOnly yes: Prevents SSH from trying multiple keys, reducing authentication noise in logs.
Ensures the same key and user are always used for this server.

Additional Security Considerations:

While this guide covers fundamental hardening steps, consider these additional measures for enhanced security:

Fail2ban: Automatically blocks IPs after failed authentication attempts
UFW (Uncomplicated Firewall): Restricts network access to necessary ports only
SSH port changes: Move SSH from default port 22 to reduce automated attacks

Key Takeaways:

This configuration establishes multiple security layers: eliminating weak authentication methods, restricting privileged access, and implementing cryptographic verification. Each step addresses specific attack vectors commonly exploited in server breaches.

GoogleSignIn Macos - Flutter

Deepraj Baidya — Mon, 18 Aug 2025 19:39:50 +0000

Integrating Google Sign-In into your Flutter app is a great way to enhance user experience by offering a quick and easy authentication process. While setting this up for Android and iOS is well-documented, the macOS platform often gets overlooked. In this guide, we’ll walk you through the steps needed to seamlessly add Google Sign-In to your Flutter macOS app. Whether you’re expanding your existing Flutter project or starting fresh, this tutorial will equip you with everything you need to implement secure and reliable authentication for macOS users. Let’s dive in and get started!

Prerequisites :

Flutter : Obviously 😂
Firebase : To enable google sign in as a Authentication Method we need to add Google as a provider in your Firebase Project.
google_sign_in : A Flutter plugin for Google Sign In.

Step 1 : OSX Deployment Target

While the official google_sign_in package suggests to keep the minimum deployment target of 10.15+, but by default while creating a flutter app the minimum deployment for macos is set to 10.14, so let's start by changing this :

Navigate to your macos/Podfile file and simply change version as shown here:

 platform :osx, '10.15'

now open the macos directory in xcode and do the following:

click on Runner.
Select Info from the tabview
Set the macOS Deployment Target\ to 10.15.

Step 2 : OAuth client configuration in Google Cloud Console.

Create a Firebase project , add Google as an Auth Provider in the Authentication Section and then do the fun stuff (adding SHA, flutterfire_cli etc), once you're completely done setting up the project and initialising our Flutter App do :

visit the GCP dashboard
Select the Firebase project form the top left corner.
Click on APIs and Services

Select Credentials from the left panel.
Click on the Create Credentials button and proceed as follows:

Just give it a Name for identification and your app's bundle ID, which you can find here, then copy the Client ID and the IOS URL scheme.

Now open your Info.plist file macos/Runner\ and add the following key values

   <key>GIDClientID</key>
        <string>CLIENT ID</string>
        <key>CFBundleURLTypes</key>
        <array>
            <dict>
                <key>CFBundleURLSchemes</key>
                <array>
                    <string>iOS URL scheme</string>
                </array>
            </dict>
        </array>

now replace the paste the copied values in the fields.

Lastly add these to your Release.entitlements and DebugProfile.entitlements files under macos/Runner\ to allow networking in your macos app from client side.

   <key>com.apple.security.network.client</key>
   <true />

Seems like a lot of work , but the hard part is over.

Let's now move towards the flutter side of things.

Step 3 : Flutter 😁

In your dependencies add google_sign_in: ^6.2.1 and firebase_core: ^3.3.0.
(Optional) : cd into your macos directory and run these commands

   pod repo update
   pod update

Edit your main.dart\ file.

   import 'package:flutter/material.dart';
   import 'firebase_options.dart';
   import 'package:firebase_core/firebase_core.dart';
   import 'package:google_sign_in/google_sign_in.dart';

   void main() {
     await Firebase.initializeApp(
       options: DefaultFirebaseOptions.currentPlatform,
     );
     runApp(MyApp());
   }

   class MyApp extends StatelessWidget {
     @override
     Widget build(BuildContext context) {
       return MaterialApp(
         home: SignInDemo(),
       );
     }
   }

   class SignInDemo extends StatefulWidget {
     @override
     _SignInDemoState createState() => _SignInDemoState();
   }

   class _SignInDemoState extends State<SignInDemo> {
     GoogleSignInAccount? _currentUser;

     final GoogleSignIn _googleSignIn = GoogleSignIn();

     @override
     void initState() {
       super.initState();
       _googleSignIn.onCurrentUserChanged.listen((GoogleSignInAccount? account) {
         setState(() {
           _currentUser = account;
         });
       });
       _googleSignIn.signInSilently();
     }

     Future<void> _handleSignIn() async {
       try {
         await _googleSignIn.signIn();
       } catch (error) {
         print(error);
       }
     }

     Future<void> _handleSignOut() async {
       await _googleSignIn.disconnect();
     }

     @override
     Widget build(BuildContext context) {
       return Scaffold(
         body: ConstrainedBox(
           constraints: const BoxConstraints.expand(),
           child: Column(
             mainAxisAlignment: MainAxisAlignment.center,
             children: <Widget>[
               if (_currentUser != null)
                 Column(
                   children: <Widget>[
                     ListTile(
                       leading: GoogleUserCircleAvatar(
                         identity: _currentUser!,
                       ),
                       title: Text(_currentUser!.displayName ?? ''),
                       subtitle: Text(_currentUser!.email),
                     ),
                     ElevatedButton(
                       onPressed: _handleSignOut,
                       child: Text('SIGN OUT'),
                     ),
                   ],
                 )
               else
                 Column(
                   children: <Widget>[
                     ElevatedButton(
                       onPressed: _handleSignIn,
                       child: Text('SIGN IN'),
                     ),
                   ],
                 ),
             ],
           ),
         ),
       );
     }
   }

That's it, you've successfully implemented google signin in your macos app.

Thumbs Up Okay GIFfrom Thumbs Up GIFs

Conclusion :

By following this guide, you’ve successfully integrated Google Sign-In into your Flutter macOS application, bringing a smooth and secure authentication experience to your users. While macOS support in Flutter may not always be as straightforward as mobile platforms, taking the time to implement this feature ensures your app is versatile and user-friendly across devices. Now, your users can effortlessly sign in with their Google accounts, enhancing engagement and trust in your app. As Flutter continues to grow, mastering cross-platform integration like this is key to staying ahead.

Let me know your thoughts in the Comment Section.

Happy Coding !! Keep Building!

Resources used :

Build your own Posthog - PART 1

Deepraj Baidya — Mon, 18 Aug 2025 19:24:37 +0000

Introduction and Project Overview

What if I told you that you could build your own version of PostHog or Mixpanel in just a weekend? That's exactly what I did with SmolHog - and through this blog, I'm going to share why I built it, how it works, and why you should care.

The Why

Every developer has used Google Analytics or Mixpanel, but have you ever wondered what's actually happening under the hood? When your app sends an event, where does it go? How does it get processed? How do those beautiful dashboards get their data in real-time?

Building SmolHog has been an incredible journey into system design patterns, event-driven architectures, and real-time data processing. There's no better way to understand how these systems work than building one yourself!

Tech Stack

Technology	Purpose
Typescript/Express	API Gateway
Flutter/ Dart	Flutter SDK
Python/ FastAPI	Event Processor
PostgreSQL	Database
RabbitMQ	Message Broker
NextJS	Analytics Dashboard (Client Side)
Jaeger	Tracing
Prometheus	Monitoring
Grafana & Loki	Dashboard & Logs (System Infra)
Docker	Containerization

10,000 foot perspective

Key Components

Flutter SDK

Source of telemetry/events generated by client applications.
Sends events over WebSocket to the backend API gateway.

API Gateway

Entry point for incoming traffic.
Validates API keys to enforce authentication/authorization.
Forwards valid events into the message broker for asynchronous processing.
Exposes tracing (via Jaeger) and metrics (via Prometheus).

RabbitMQ (Message Broker)

Provides asynchronous decoupling between ingestion and processing.
Events are queued for consumption by downstream processors.

Event Processor

Consumes queued events from RabbitMQ.
Performs enrichment, transformation, or filtering.
Queues processed events for storage.
Reports tracing and metrics.

Workers

Specialized background workers consume processed events.
Handle persistence and business-specific logic.

Database

Storage backend for processed events.
Supports query execution for analytics endpoints.

Frontend

Provides analytics dashboards and APIs.
Queries traces from Jaeger and metrics from Prometheus.
Fetches data from /analytics/* endpoints backed by the database.
Monitoring & Logs Collection
Central observability layer.
Collects metrics from all components.
Aggregates traces across request flows.
Provides visibility into latency, throughput, and error rates.

Key Features

Event Tracking
SmolHog can track any user interaction - clicks, page views, form submissions - with custom properties for detailed analysis.
User Identification
Connect events to specific users and track their journey through your application over time.
Real-time Dashboard
See events as they happen with a 10-second refresh interval (with plans to upgrade to WebSockets for true real-time updates).
Custom Event Properties
Attach any properties to your events for deeper analysis and segmentation.
Time-Series Analysis
Track event distribution over time to identify patterns and trends.
Cross-Platform SDK
Currently supports Flutter, with a clean, easy-to-use API.

Stay tuned for more technical deep dives into specific components of SmolHog in future blog posts!

Till then Happy Coding.