Forem: yep

Front-End & Struggles

yep — Fri, 10 Apr 2026 13:43:31 +0000

I didn’t have much frontend experience. This post covers the struggles I ran into.

Starting Point: React + TypeScript + Plain CSS

React with TypeScript felt like the obvious choice — popular, good ecosystem, type safety. I started writing plain CSS modules for styling. Full control, right?

The problem wasn't the code. It was that I had no design vision. I'd write a component, look at it, and know it looked bad but not know how to fix it. What colors? How much padding? How should this align? I couldn't answer these questions. The feedback loop was: write code → look bad → feel stuck → repeat. This went on for weeks.

Tailwind CSS Didn't Solve the Real Problem

I switched to Tailwind CSS thinking it would help. It sped things up — utility classes are fast to write, no context switching between files. But Tailwind is a tool for people who already know what they want to build. It doesn't give you design vision, it just makes it faster to execute one. I still didn't know what I wanted.

I tried Figma. I couldn't make anything that looked good there either. The problem wasn't the tools.

I restarted the project multiple times during this period — changing UI approach, structure, and direction. It felt like progress but mostly wasn't. This lasted around 3-4 weeks. Eventually I accepted that I wasn't going to figure out design from scratch and looked for a component library.

shadcn/ui

I looked at Material UI and Ant Design. Both felt heavy and opinionated in ways that would fight me later. I wanted something that:

Looked good out of the box
Integrated with Tailwind
I could actually own the code

shadcn/ui fit all of this. The key difference is that components are generated into your codebase rather than installed as a dependency. This gives full control over behavior and styling, without being constrained by a library’s abstraction. That turned out to matter a lot later when I needed to adapt components for React Native.

Next.js: Tried It, Left It

Around this time I migrated to Next.js. SSR, SSG, the whole thing. After a while I realized most of my components were client-side anyway. ASTRING is a chat app — it's dynamic content fetched after load, not static pages that benefit from SSR. I moved back to React with Vite. Faster dev server, simpler setup, no framework fighting back.

State Management: Jotai

Chat state is genuinely complex — active rooms, message lists, unread counts, real-time updates coming in from WebSocket, user presence. Redux felt like too much ceremony for this. Context API caused re-render problems as state got more interconnected.

Jotai worked well. Atoms are simple to create, updates are granular, and the mental model maps cleanly to "this piece of state, these components that care about it." Chat state in particular became much cleaner — each room's state is an atom, components subscribe only to what they need.

React Native: Why I Left Ionic

I built the mobile version with Ionic React first. Code reuse from the web was easy. But Ionic started showing limits for a chat app specifically — animations felt off, native components were lacking, the "native feel" wasn't there. Chat apps have specific UX expectations: smooth scrolling through message history, keyboard handling, swipe gestures, native-feeling transitions. Ionic's web-based approach couldn't deliver these well enough.

I moved to React Native with Expo. Expo makes the setup significantly easier — no manual native build configuration, good tooling, OTA updates.

Current Setup: Monorepo with pnpm Workspaces

Moving to React Native meant I had two apps — web (React + Vite) and mobile (React Native + Expo). Rather than duplicate code, I set up a monorepo with pnpm workspaces. Nothing fancy.

Shared packages:

Services — business logic
API clients — all backend communication
Jotai atoms — shared state: rooms, chats, user cache

Web and mobile each have their own UI layer, but everything underneath is shared. State is defined once — a room list atom, a message cache atom, a user presence atom — and both platforms consume the same atoms. This means a bug fix or API change happens once, and state behavior is consistent across platforms.

For styling on React Native I use NativeWind — Tailwind for React Native. Same utility classes I use on web, works on mobile. Makes the styling consistent and fast.

shadcn/ui on React Native — since shadcn components live in my codebase, I adapted them for React Native manually. div → View, button → Pressable, CSS → NativeWind classes. It's tedious but straightforward, and the result is consistent components across both platforms without two completely separate design systems.

Where It Stands

The code is messy in places. The UI is functional but not something I'm proud of visually. The monorepo structure is working well. Mobile is better than Ionic was for the specific things chat needs.

The main thing I learned: frontend is a different skill set. I kept thinking better tools would solve a design problem. They didn't. What helped was accepting I needed pre-built components, adapting them rather than fighting them, and not over-engineering the state management.

From Fly.io to On-Premise Kubernetes

yep — Thu, 09 Apr 2026 13:39:56 +0000

Everything works in localhost. Exposing it to the internet is a different problem. I went through Fly.io, Linode managed Kubernetes, and eventually landed on an on-premise cluster. Each step had tradeoffs in both cost and operational complexity.

Containers and Kubernetes

Before getting into the details, here is the short explanation.

A container is a lightweight, isolated unit that packages an application with its runtime and dependencies. Unlike virtual machines, containers share the host OS kernel, which makes them efficient in terms of startup time and resource usage. Docker is the standard tooling: define a Dockerfile, build an image, and run it across environments with minimal variation.

The problem: once we have multiple containers across multiple machines, managing them manually is chaos. Which machine runs what? What happens when a container crashes? How do you roll out updates without downtime?

Kubernetes solves this. It's an orchestration platform — you describe what you want (3 replicas of this service, always keep them running, expose them on this port) and Kubernetes figures out how to make it happen. The key building blocks:

Pod — the smallest unit, one or more containers running together
Deployment — describes how many pods to run and how to update them
Service — a stable network endpoint that routes traffic to the right pods
Ingress — routes external HTTP traffic into the cluster

The big win: if a pod crashes, Kubernetes restarts it. If a node goes down, it reschedules pods elsewhere. You stop thinking about individual machines and start thinking about desired state.

Phase 1: Fly.io + Vercel

For the backend I started with Fly.io. Easy to deploy, cheap during development — I stayed under their $5 threshold. For the frontend, Vercel. Push to GitLab, it deploys automatically. Vercel still handles the frontend today, no complaints. Fly.io manages container just fine.

Fly.io was fine for stateless services. The problem was stateful ones — ScyllaDB and NATS.

Running stateful services on Kubernetes properly requires operators — controllers that understand the specific lifecycle of a piece of software. ScyllaDB has its own operator that handles cluster bootstrapping, repairs, scaling, backup, topology changes. NATS has one too. On platforms like this, running Kubernetes operators isn’t possible because you don’t have access to a Kubernetes control plane. As a result, lifecycle management for stateful systems must be handled manually. You're stuck managing stateful services manually. I spent more time managing the platform than building the product.

Phase 2: Linode Managed Kubernetes

I needed real Kubernetes. Linode offered $100 credit on signup, which was enough to experiment properly.

The setup: 3 worker nodes (1 CPU, 2GB RAM, 50GB storage each) plus a load balancer. Linode's managed Kubernetes is free for the control plane — we only pay for nodes and networking.

3 nodes × $12/month = $36
Load balancer = $10/month
Total: $46/month

I used Terraform with Linode's provider to provision the cluster — infrastructure as code, version controlled, easy to redeploy. Once the cluster was up, I could run operators properly. ScyllaDB and NATS behaved the way they were supposed to.

When the $100 credit ran out, $46/month was hard to justify for a project still in testing. So I started thinking about on-premise.

Phase 3: On-Premise Kubernetes

The same teacher from my IOI days - gave me access to three VMs on his company's infrastructure. Free. Each machine had 8 cores, 8GB RAM, and 50GB storage.

I set up my own Kubernetes cluster on these using k3s — a lightweight Kubernetes distribution that works well for on-premise and resource-constrained environments. I'll write a dedicated post on the k3s setup, but the short version: it's full Kubernetes without the overhead, and it runs fine on these VMs.

Full control over the environment. I can run any operator, configure networking however I need, no platform restrictions. The tradeoff is that there's no managed control plane — if something breaks at the infrastructure level, I fix it myself. It’s acceptable also free just some of my time.

I deployed everything: ScyllaDB cluster, NATS, PostgreSQL, Redis, the backend services. All running on three VMs, costing nothing.

Where Things Stand

Frontend: Vercel, still works great
Backend + all services: On-premise k3s cluster

On-premise infrastructure requires more operational effort but provides full control and effectively zero cost when hardware is available. Next I'll write about the actual k3s setup — how I configured the cluster, networking, storage, and got everything running.

Object Storage & CDN Journey

yep — Thu, 09 Apr 2026 13:18:38 +0000

A chat application needs reliable object storage — media uploads, backups, logs. Sounds simple, but there’s lot of choices. I went through six different solutions before landing on something that actually made sense.

The S3 API

Before getting into the journey, one thing worth explaining: almost every object storage provider today implements the S3 API — the interface originally built by AWS for their Simple Storage Service.

It's a RESTful interface: buckets as containers, objects accessed by unique keys, HTTP methods for everything. The key thing is it's a standard. Providers like Wasabi, MinIO, Backblaze, Cloudflare R2 — they all speak S3. That means I can swap providers without rewriting application logic, just change the endpoint and credentials. That portability matters a lot when you're still figuring out the right fit.

The Provider Journey

AWS S3

The obvious starting point. Reliable, feature-rich, integrates with everything. I used it early on and it worked fine — but the pricing model is higher than others. I stopped using it before things got expensive.

Backblaze B2

Backblaze B2 has egress-free pricing, which sounds great. The problem: it only has American data centers. My servers and users aren't in America, so the latency was noticeable and unacceptable for a real-time chat app.

Tigris (via Fly.io)

Tigris (Fly.io) provides globally distributed, S3-compatible storage with low latency, addressing the B2 latency limitations. However, its pricing model includes per-request charges in addition to storage. For an API-heavy workload like a chat system, this would scale poorly, so I decided not to go with it.

MinIO

I actually deployed MinIO in my cluster. It's open-source, S3-compatible, and simple to run. But running it yourself means managing infrastructure, handling high availability, paying for the compute. For a small project it's overkill — I was spending more time on storage ops than on the actual product.

Wasabi

Wasabi has egress-free pricing and good performance. I settled here for a while. But there's a catch: Wasabi doesn't support public bucket permissions.

For private files, that's fine — I generate pre-signed URLs from the backend, the user gets a temporary link, no credentials exposed. But for public files like profile pictures, I had to build a backend service to forward them to users. Extra latency, extra backend load, not ideal.

I made it work, but then realized a bigger problem.

The Wasabi Pricing Problem

Wasabi charges for a minimum of 1TB regardless of how much you actually store. My total data — user uploads, database backups, cluster backups — was under 10GB. I was paying $8/month to store 10GB. That's bad.

Fixing the Public File Problem First

Before I figured out the pricing issue, I spent time solving the public file latency problem with Cloudflare caching. Worth documenting because it works well if you're stuck on Wasabi or something like this.

The setup: every public file request goes through my backend at /api/v1/media/file/*. I set Cloudflare cache rules on that path — mark responses eligible for cache, force an edge TTL of 1 year, bypass backend Cache-Control headers. Once a file is cached at Cloudflare's edge, it never hits my backend or Wasabi again.

Here's a real cached response:

CF-Cache-Status: HIT — served from Cloudflare's edge, not my backend
Age: 774 — seconds it's been cached at the edge
Cache-Control: max-age=31536000 — browser caches it for 1 year too

Zero extra cluster resources, no Wasabi bandwidth on repeat requests, low latency globally. If you're using Wasabi and hitting this problem, this approach works.

Because of the fixed fee, i decided to move anyway.

Final Setup: Cloudflare R2

Cloudflare R2 has a free tier of 10GB. My entire dataset fits in that. No egress fees, native CDN built in — so no need for the Cloudflare caching workaround above (though good to know it works). I moved everything to R2 and now pay nothing for storage.

For backups, I'm keeping Backblaze B2 in mind for when data grows — egress-free and cheap for large volumes, as long as the latency to my users is acceptable for backup use cases (it is).

Current state:

Cloudflare R2 — user uploads, all active data, everything under 10GB (free tier)
Backblaze B2 — future home for backups once R2 free tier isn't enough

The egress-free advantage of Wasabi turned out to be irrelevant at my scale. Under 1TB, you're just paying the minimum anyway. R2's free tier made the decision easy

Finding Rigth Database

yep — Wed, 08 Apr 2026 14:04:20 +0000

Most applications need to persist state. In a chat application, that state is massive, constantly growing, and high-frequency. The obvious starting point is a traditional RDBMS — but the specific access patterns of a real-time chat system eventually force a rethink.

The Problem with RDBMS for Chat

I could use PostgreSQL for storing messages. It works, until it doesn't.

Chat is different from most relational data. Messages don't join to other tables. What I actually need is simple: insert a message, fetch messages by room or user. That's it. So the requirements are:

It grows fast — millions, then billions of rows
No joins needed — just "give me all messages for room X"
Reads and writes need to be fast

Traditional databases like PostgreSQL and MySQL weren't designed with this access pattern as the primary use case. Here's why that matters.

Partitioning

As the message table grows, we can partition it — split it into smaller physical chunks based on some key, like room ID or time range. The database only scans the relevant partition instead of the whole table. Postgres supports this natively, but it handles it differently from distributed systems — partitions still live on a single machine, so we’re organizing data, not distributing the load.

The Write Scaling Problem

The bigger issue is writes. PostgreSQL and MySQL use a single-master model — one node handles all writes, replicas handle reads. Every message sent goes through that one master. At high write volume, that becomes bottleneck.

The common solution is sharding: split data across multiple independent database instances, each owning a slice. Hash the room ID to decide which shard it lives on. In theory, clean. In practice, painful — managing shard keys, handling rebalancing when nodes are added, cross-shard queries becoming a nightmare. I decided early on to avoid this entirely by choosing a database built for it natively.

Cassandra and ScyllaDB

This is where wide-column stores like Cassandra — and its C++ reimplementation, ScyllaDB — come in. Same architecture, ScyllaDB just rewrote it in C++ for better performance and lower latency.

The core idea: instead of one master handling writes, Cassandra/ScyllaDB uses a ring topology. Every node in the cluster owns a range of a hash space. When a message is written, the room ID gets hashed and routed to the node that owns that hash range. No single master, no write bottleneck — every node can accept writes.

Replication works naturally on top of this. With a replication factor of 3, a write doesn't just go to the primary node — it also goes to the next 2 nodes on the ring. So there are 3 copies of the data across different nodes. If one goes down, the data is still there. No manual failover, it's built into how the ring works.

The other key advantage is the partition key. By using room ID as the partition key, Cassandra/ScyllaDB guarantees all messages for that room are stored together on the same node. Pair that with a clustering key on timestamp, and messages within a room are physically stored in time order — fetching history becomes one sequential read, already sorted. No ORDER BY, no extra cost.

This turns random I/O into sequential I/O. Fetching chat history means finding the right node and reading one continuous stream. That's a hardware-level optimization that a single-master Postgres setup simply can't match at scale.

The tradeoff: Cassandra/ScyllaDB is bad at full scans and joins, because those require hitting every node. But based on the requirements here, that doesn't matter — joins are never needed.

This isn't just theory. Discord went through this exact problem — first scaling with Cassandra for billions of messages, then eventually migrating to ScyllaDB for better performance at trillions of messages. Worth reading if you want a production-scale perspective:

I'll write a dedicated post on Cassandra/ScyllaDB internals — replication strategies, consistency levels, and multi-DC support deserve their own space.

The Hybrid Architecture

There's no perfect database. Different tools solve different problems, so I use both:

PostgreSQL — relational, "small" data: users, friend lists, room metadata. Needs ACID compliance and complex queries, but doesn't grow at a massive rate.
Cassandra/ScyllaDB — the heavy data: every message ever sent. High-write throughput, fast sequential reads by room, horizontally scalable without a single write master.

Each database does what it's actually good at.

What's Next

There's more to cover here — consistency models, high availability, failover, and distributed systems fundamentals like Raft. I'll get into those in future posts. For now, this is the architectural reasoning behind the storage layer in ASTRING.