Forem: Vasyl

I Quit Designing Data-Intensive Applications (DDIA) Three Times. Here's What I Build on the Fourth Try.

Vasyl — Wed, 22 Apr 2026 05:14:01 +0000

In 2023 I bought DDIA on Kindle. Opened the replication chapter. Quit after 40 pages and didn't open it for six months.

In 2024 I bought it again, because the book is clearly worth finishing. Got to page 80. Closed it.

In 2025 I tried a third time with ChatGPT open in another tab to explain the hard terms. It got easier. But every lookup was the same loop — alt-tab, paste the sentence, wait, come back, find my place. After three chapters I wasn't really reading the book anymore. I was reading my own habit of switching tabs.

The book still sits in my Kindle library, marked unfinished. If you have a book like that on your shelf, this post is for you. I finally figured out why I kept quitting, and built a tool that fixes it for me. Maybe it fixes it for you too.

What was actually breaking

When I quit for the third time, I sat down and tried to be honest about what was stopping me.

It wasn't that the book was too hard. I understood most of what was on the page. The problem was the rest — the unfamiliar terms.

Every unknown term forced a decision between two bad options.

Option one: stop and look it up. Alt-tab, paste the sentence, wait, come back, find my place. Flow broken. The next paragraph is harder to hold in your head.

Option two: skip it and hope context saves me. Sometimes it does. But after a dozen skips in a chapter, the quality of my reading drops noticeably. And each "I'll figure it out later" turns into debt.

The exhaustion wasn't coming from reading. It was coming from the constant small decisions.

There was a third problem too. Even when I did look something up, a week later I'd forgotten it. ChatGPT doesn't remember you asked. Anki remembers, but making cards by hand is its own pile of friction. I was learning words in order to forget them. And reading books in order to quit them.

What I got wrong about AI and reading

When ChatGPT arrived, a lot of people thought long books were dead. Why read 600 pages of DDIA when you can ask and get a summary in a minute?

I believed that for about a year.

Then I sat in a 2025 interview being asked about replication strategies in distributed systems, and realized I couldn't explain the difference between synchronous and asynchronous replication past surface-level buzzwords. I'd read dozens of summaries, listened to podcasts, watched YouTube breakdowns. I knew things on the surface. I didn't understand any of them deeply.

For staying current, summaries are fine. For real understanding, nothing replaces sitting with a book that someone spent years structuring. Those are exactly the books I kept quitting around page 40.

What I built

In January 2026 I started building what became TextStack — a reader where I could read technical books without the tab switching.

The idea is simple. Tap a word you don't know. An explanation appears inline — not a dictionary entry, but a short concept explanation from Claude that takes into account what the book is about and what the sentence is doing. For everyday words, a short translation. For technical terms like RLHF, attention mechanism, or eventual consistency — two or three sentences on what it is and why it matters, with links to related ideas and common confusions.

The word goes into a personal dictionary automatically. But not the way LingQ does it, where your review queue grows to hundreds of items and you quit the app. I built a filter — only words from roughly the top 15,000 English words by frequency, or technical terms, enter spaced repetition. The rest are saved as reference. The weekly review queue is capped, so it never spirals.

Over three and a half months I put together a working version on .NET 10, React, and React Native. PostgreSQL, Claude API for explanations, Edge TTS for audio, offline PWA. It ingests EPUB, PDF, and FB2. The catalog started wide, but I'm pruning it hard — I'm realizing focus matters more than I thought.

It lives at textstack.app — full pitch at the end of this post.

What I got wrong for three months

For the first three months I was building for an abstract "non-native English speaker who wants to read books." Nobody needs that.

In April I looked at it honestly and asked who I'd actually built it for. The answer was: a developer trying to read AI engineering books. Because that's what I'd been trying to read for two years. Chip Huyen's AI Engineering. Hands-On Large Language Models. Designing Machine Learning Systems. Building Agentic AI Systems. Prompt Engineering for LLMs. I bought all of them. I finished none.

When I looked at other developers' reading lists online, I saw I wasn't alone. A lot of developers are trying to move into AI engineering right now. We're all reading the same books, and a lot of us aren't finishing them.

This isn't a generic "non-native English" problem. It's a specific problem for a specific group going through a specific career transition.

So I'm pivoting. Not "a reader for everyone." A reader for developers learning AI engineering. A narrow niche where I'm already the user.

The next six months

Four things.

1. Rebuild the product around the AI angle. Trim the catalog to 15–20 AI engineering books. Rewrite the homepage. Shift the framing from translation to explanation. Improve the prompts for technical terms.

2. Actually start reading. Hands-On LLMs in May. AI Engineering in June and July. Building Agentic AI Systems in August. Not as a task — as something I want. I want to work as an AI engineer in two years, and the only way there is through these books. I'll read them inside TextStack, because if it doesn't work for me, it won't work for anyone.

3. Write about the process. This is the first post. If you want to follow along, the blog has RSS.

4. Find the first paying customer.

I'll say it openly: if in six months there's one stranger paying for TextStack, I'll consider this project a success regardless of the other numbers. The first dollar from someone you don't know is a threshold most solo devs never cross. Crossing it is a big part of the work of leaving employment.

Try it

Live at textstack.app — you can open a sample chapter of Pragmatic Programmer or Hands-On LLMs without signing up.

If you're in a similar spot — non-native dev, bought the AI engineering books, didn't finish them — send me a note. Twitter: @Rexetdeus. Email on the site. I'll give you early access and listen to what works and what doesn't. In exchange I need honest feedback.

If it's not your thing, thanks for reading this far. If someone you know is stuck on Chapter 3 of AI Engineering, maybe forward them this post.

P.S.

One more thing. This problem — quitting hard books at page 40 — isn't really about English and isn't really about AI. It's that reading tools are stuck in the early 2010s while content has gotten much denser.

Kindle Word Wise is from 2014, and it still shows single-word definitions that can't handle eventual consistency or attention mechanism. LingQ has been showing translations and adding words to SRS for close to two decades, and the core experience hasn't really changed. Readlang was a clever browser extension in 2013; development stopped when the founder went to Duolingo.

Modern books need different tools. Not dictionaries — explanations. Not infinite queues — capped ones. Not one experience for everyone — context-aware understanding.

That's the opening I'm walking into. I'll let you know in six months how it went.

First post in a series about building TextStack as an AI engineering books reader. Star the repo if you want to follow along: github.com/mrviduus/textstack · textstack.app

How We Made Our React SPA Visible to Google Without Rewriting Everything

Vasyl — Sat, 17 Jan 2026 23:31:51 +0000

TL;DR: We needed Google to index 500+ book pages on our SPA. Instead of migrating to Next.js or building a complex SSR solution, we added dynamic rendering with Prerender in 3 files. Here's exactly how.

The Problem: Google Can't See Your Beautiful SPA

We built TextStack — a free online library with a Kindle-like reader. React frontend, ASP.NET Core API, PostgreSQL. Classic stack, works great.

One problem: Google saw nothing.

<!-- What users see -->
<title>As I Lay Dying by William Faulkner | TextStack</title>
<h1>As I Lay Dying</h1>
<p>After a woman in rural Mississippi dies...</p>
<!-- 98 chapters, rich metadata, Schema.org markup -->

<!-- What Googlebot saw -->
<title>Free Online Library | TextStack</title>
<div id="root"></div>
<!-- Empty. Nothing. Void. -->

We had 500+ books with beautiful SEO metadata, Schema.org structured data, Open Graph tags — all generated client-side. Googlebot executes JavaScript, but it's inconsistent and slow. Our pages weren't getting indexed.

The Options We Considered

Option 1: Server-Side Rendering (Next.js/Remix)

Pros: Industry standard, great DX, built-in optimizations

Cons: Complete frontend rewrite. Our React app was ~50 components, custom reader with offline sync, complex state management. Estimated time: 3-4 weeks.

Option 2: Static Site Generation

Pros: Fastest possible page loads, works everywhere

Cons: We tried this. Built a Next.js SSG version. It worked... until we opened it in the browser. The reader was broken. Styles were wrong. We'd essentially need to maintain two frontends.

Option 3: Dynamic Rendering (Prerender)

Pros: Zero changes to existing React app. Add a service, configure nginx, done.

Cons: Additional infrastructure, slight latency for first bot request.

We chose Option 3.

What is Dynamic Rendering?

Dynamic rendering means serving different content based on who's asking:

Regular User (Chrome, Safari, Firefox):
  User → nginx → SPA (index.html + JS) → JS renders in browser

Search Bot (Googlebot, Bingbot):
  Bot → nginx → Prerender → Headless Chrome renders page → HTML response

Google officially supports this approach and doesn't consider it cloaking (as long as the content is the same).

The Architecture

Here's our setup:

┌─────────────────────────────────────────────────────────────┐
│                         nginx                                │
│  ┌─────────────────────────────────────────────────────────┐│
│  │ Check User-Agent                                        ││
│  │ Is it Googlebot/Bingbot/etc?                           ││
│  └──────────────┬────────────────────┬────────────────────┘│
│                 │ YES               │ NO                    │
│                 ▼                   ▼                       │
│  ┌──────────────────┐    ┌──────────────────┐              │
│  │ Prerender        │    │ Static Files /   │              │
│  │ (Headless Chrome)│    │ Vite Dev Server  │              │
│  └────────┬─────────┘    └──────────────────┘              │
│           │                                                 │
│           ▼                                                 │
│  ┌──────────────────┐                                      │
│  │ Fetch & Render   │                                      │
│  │ React App        │──────► API                           │
│  └──────────────────┘                                      │
└─────────────────────────────────────────────────────────────┘

The Implementation

Step 1: Add Prerender Service

We used — a lightweight Docker image with headless Chrome:

# docker-compose.yml
services:
  prerender:
    image: tvanro/prerender-alpine:7.2.0
    container_name: books_prerender
    environment:
      MEMORY_CACHE: 1      # Enable in-memory cache
      CACHE_MAXSIZE: 500   # Cache up to 500 pages
      CACHE_TTL: 3600      # 1 hour cache
    ports:
      - "3030:3000"
    deploy:
      resources:
        limits:
          memory: 1G       # Chrome is hungry

Step 2: Configure nginx Bot Detection

# Bot detection map
map $http_user_agent $prerender_ua {
    default 0;
    "~*googlebot" 1;
    "~*bingbot" 1;
    "~*yandex" 1;
    "~*facebookexternalhit" 1;
    "~*twitterbot" 1;
    "~*linkedinbot" 1;
    "~*slackbot" 1;
    "~*whatsapp" 1;
    "~*applebot" 1;
    # Add more as needed
}

Step 3: Route Bots to Prerender

server {
    listen 80;
    server_name textstack.app;

    # Internal prerender location
    location /prerender-internal/ {
        internal;
        proxy_pass http://prerender:3000/;
        proxy_set_header Host $host;
        proxy_connect_timeout 60s;
        proxy_read_timeout 60s;
    }

    location / {
        # Check if bot
        set $prerender 0;
        if ($prerender_ua) {
            set $prerender 1;
        }

        # Don't prerender static files
        if ($uri ~* "\.(js|css|png|jpg|svg|woff2)$") {
            set $prerender 0;
        }

        # Route bots to prerender
        if ($prerender = 1) {
            rewrite ^(.*)$ /prerender-internal/http://$host$1 last;
        }

        # Normal users get SPA
        try_files $uri $uri/ /index.html;
    }
}

The Challenge: API Calls Inside Prerender

Here's where it got interesting. After setting everything up, our book detail pages showed:

<h1>Error</h1>
<p>Failed to fetch</p>

The problem: Our SPA makes API calls to fetch book data. The API URL was configured as http://localhost:8080. Inside the Prerender container, localhost is... the container itself. Not our API.

The solution: Vite's dev server proxy.

// vite.config.ts
export default defineConfig({
  server: {
    proxy: {
      '/api': {
        target: 'http://api:8080',  // Docker service name
        changeOrigin: true,
        rewrite: (path) => path.replace(/^\/api/, ''),
      },
    },
    // Allow prerender to access via Docker network
    allowedHosts: ['web', 'localhost'],
  },
})

Then we changed our API base URL:

// Before
const API_BASE = 'http://localhost:8080'

// After
const API_BASE = '/api'  // Relative, works everywhere

Now when Prerender's Chrome loads our SPA:

JS executes and calls /api/en/books/some-book
Vite proxies to http://api:8080/en/books/some-book
API returns data
React renders the page
Prerender captures the HTML

The Result

Before (what Googlebot saw):

<title>Free Online Library | TextStack</title>
<div id="root"></div>

After:

<title>As I Lay Dying by William Faulkner | TextStack</title>
<meta name="description" content="After a woman in rural Mississippi dies,
her husband and five children begin an arduous journey...">

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Book",
  "name": "As I Lay Dying",
  "author": {"@type": "Person", "name": "William Faulkner"},
  "description": "...",
  "inLanguage": "en"
}
</script>

<h1>As I Lay Dying</h1>
<p class="book-detail__author">William Faulkner</p>
<ul><!-- 98 chapters with links --></ul>

Performance:

First request (cold): ~3-5 seconds (Chrome needs to render)
Cached requests: ~50ms
Cache hit rate: ~95% (bots recrawl the same pages)

Quick Test

Want to see what Googlebot sees on your site?

# Your site as a regular user
curl -s "https://yoursite.com/page" | grep "<title>"

# Your site as Googlebot
curl -s -A "Googlebot" "https://yoursite.com/page" | grep "<title>"

If the titles are different (or the second one is empty), you have an SEO problem.

Files Changed

The entire implementation touched 5 files:

File	Lines	Purpose
`docker-compose.yml`	+20	Add prerender service
`nginx.conf`	+85	Bot detection & routing
`vite.config.ts`	+10	API proxy for prerender
`docker-compose.prod.yml`	+18	Production prerender
`nginx-prod.conf`	+118	Production bot routing

No React components changed. No business logic touched. The SPA remains exactly as it was.

Should You Use This?

Yes, if:

You have an existing SPA that works well
You need SEO but can't justify a rewrite
Your content doesn't change every second
You're comfortable with Docker/nginx

No, if:

You're starting a new project (just use Next.js)
You need real-time SEO updates
Your pages are highly personalized
You can't add infrastructure

Have questions about implementing this for your SPA? Drop a comment below or open an issue on GitHub!

Tags: #react #seo #docker #nginx #webdev

How to Expose Your Local Server to the Internet (Without Port Forwarding)

Vasyl — Fri, 02 Jan 2026 17:37:18 +0000

TL;DR: Use Cloudflare Tunnel to make your home server accessible from anywhere. Free, secure, no router configuration needed.

I recently deployed a web app running on my laptop to a real domain. No cloud hosting, no VPS, no monthly bills. Just my laptop, a domain, and Cloudflare Tunnel.

Here's exactly how I did it.

The Problem

I wanted to host my side project on my own hardware. Sounds simple, right?

But my setup had issues:

No access to the main router's admin panel
Dynamic IP address
Port forwarding wasn't an option

Traditional solutions like opening ports 80/443 weren't going to work.

The Solution: Cloudflare Tunnel

Cloudflare Tunnel (formerly Argo Tunnel) creates an outbound connection from your server to Cloudflare's edge. No incoming ports needed.

Internet → Cloudflare (SSL) → Tunnel → Your laptop

It's free, handles SSL automatically.

Prerequisites

A domain name (any registrar works)
A Cloudflare account (free tier is fine)
A Linux/Mac/Windows machine running your app
~10 minutes

Step 1: Add Your Domain to Cloudflare

Go to dash.cloudflare.com
Click Add a site
Enter your domain (e.g., myapp.com)
Select the Free plan
Cloudflare will show you new nameservers

Step 2: Update Nameservers

Go to your domain registrar and replace the nameservers with Cloudflare's.

For example, if you're using Porkbun:

Go to Domain Management → Your domain
Click Nameservers → Edit
Replace with Cloudflare nameservers:

   carter.ns.cloudflare.com
   vita.ns.cloudflare.com

Save and wait 5-30 minutes for propagation

Step 3: Create a Tunnel

In Cloudflare, go to Zero Trust (left sidebar)
Navigate to Networks → Tunnels
Click Create a tunnel
Name it something like my-server
You'll get an installation command with a token

Step 4: Install Cloudflared

On your server, install the cloudflared daemon:

Ubuntu/Debian:

curl -L --output cloudflared.deb https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-amd64.deb
sudo dpkg -i cloudflared.deb

macOS:

brew install cloudflared

Windows:
Download from GitHub releases

Step 5: Connect the Tunnel

Run the command Cloudflare gave you:

sudo cloudflared service install <YOUR_TOKEN>

This installs cloudflared as a system service that starts automatically on boot.

Check it's running:

sudo systemctl status cloudflared

Step 6: Add a Public Hostname

Back in Cloudflare Dashboard:

Go to your tunnel → Configure
Click Public Hostname → Add a public hostname
Fill in:
- Subdomain: leave empty (or use www)
- Domain: select your domain
- Service Type: HTTP
- URL: localhost:80 (or whatever port your app runs on)
Save

Note: If you get "DNS record already exists" error, delete the existing A record for your domain in DNS → Records first.

Step 7: Test It

Open your domain in a browser. It should load your local app with HTTPS!

# Or test from command line
curl https://myapp.com

Running Multiple Services

You can route different domains or paths to different local services:

Domain	Service
`myapp.com`	`localhost:3000` (frontend)
`api.myapp.com`	`localhost:8080` (API)

Just add multiple public hostnames in the tunnel configuration.

My Setup

Here's what I'm running:

textstack.app     → localhost:80 → nginx → React frontend
textstack.app/api → localhost:80 → nginx → Docker API (port 8080)
textstack.dev     → localhost:80 → nginx → Same app, different site

All from a laptop sitting in my living room.

Security Tips

Firewall: Only allow necessary ports locally

   sudo ufw allow 22/tcp   # SSH
   sudo ufw allow 80/tcp   # For tunnel (local only)
   sudo ufw enable

Don't expose admin panels to the internet. Keep them on localhost only.
Cloudflare adds SSL automatically - no need for Let's Encrypt.
Use Access Policies (in Zero Trust) to require authentication for sensitive routes.

Troubleshooting

Site not loading?

# Check tunnel is running
sudo systemctl status cloudflared

# Check your app is running
curl localhost:80

# Check DNS propagation
dig myapp.com

"Address Not Found" on mobile?
DNS might not have propagated to your carrier yet. Try:

Toggle airplane mode on/off
Use a different DNS (1.1.1.1)
Wait 15-30 minutes

502 Bad Gateway?
Your local app isn't responding. Check it's running on the correct port.

Cost

Cloudflare Tunnel: Free
Domain: ~$10/year
Hosting: $0 (your own hardware)

When NOT to Use This

High-traffic production apps (your home internet has limits)
Apps requiring 99.99% uptime (your laptop can crash)
Sensitive data without proper security measures

For serious production workloads, use proper cloud hosting.

Wrapping Up

Cloudflare Tunnel is perfect for:

Side projects
Development/staging environments
Self-hosted apps
Home automation dashboards
Personal APIs

It took me about 15 minutes to go from "app running locally" to "app accessible worldwide with HTTPS."

No cloud bills. No DevOps complexity. Just your code, running on your hardware, accessible to the world.

Have questions? Drop a comment below or find me on Twitter/X.

Building something cool with this setup? I'd love to hear about it!

Tags: cloudflare, self-hosting, devops, tutorial, web-development

Build and Push .NET 8 Apps as Docker Images (No Dockerfile)

Vasyl — Thu, 24 Jul 2025 02:19:51 +0000

1. Why do this?

.NET 8 can build a Docker image for you.
One command creates and tags the image.
You can push the image without Docker on the build server.

2. What you need

.NET SDK 8.0.200+ — Build and publish the image.
Docker or Podman (optional) — Run the image on your PC.
GitHub or Azure DevOps — Run CI/CD examples.

3. Build and run on your PC

Open a terminal and run:

dotnet new console -o MyApp
cd MyApp
dotnet publish -t:PublishContainer -p:EnableSdkContainerSupport=true
docker run --rm myapp:latest

The SDK picks the base image, tags it myapp:latest, and stores it locally.

4. Change image settings

Use Alpine Linux

  dotnet publish --os linux-musl -t:PublishContainer

Use Ubuntu 22.04

  dotnet publish -t:PublishContainer -p:ContainerFamily=jammy

Tiny chiseled image

  dotnet publish -t:PublishContainer -p:ContainerFamily=jammy-chiseled-extra

Set repo & tag

  dotnet publish -t:PublishContainer -p:ContainerRepository=ghcr.io/user/app -p:ContainerImageTags=v1

Push in build

  dotnet publish -t:PublishContainer -p:ContainerRegistry=ghcr.io -p:ContainerPush=true

5. GitHub Actions

Save this as .github/workflows/docker.yml:

name: Build and push image
on: [push]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-dotnet@v4
        with:
          dotnet-version: 8.0.x
      - uses: docker/login-action@v3
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}
      - name: Publish image
        run: |
          dotnet publish -c Release -t:PublishContainer \
            -p:ContainerRepository=ghcr.io/${{ github.repository }} \
            -p:ContainerImageTags=${{ github.sha }} \
            -p:ContainerPush=true

6. Azure DevOps

Save this as azure-pipelines.yml:

trigger:
- main

pool:
  vmImage: ubuntu-latest

variables:
  acrName: myacr.azurecr.io
  imageRepo: demo/myapp

steps:
- checkout: self
- task: UseDotNet@2
  inputs:
    packageType: sdk
    version: 8.0.x
- script: |
    dotnet publish -c Release -t:PublishContainer \
      -p:ContainerRegistry=$(acrName) \
      -p:ContainerRepository=$(imageRepo) \
      -p:ContainerImageTags=$(Build.BuildNumber) \
      -p:ContainerPush=true
  displayName: Build and push

7. Quick fixes

Hidden folders like .well-known are missing → Rename the folder or add a custom MSBuild target.
Need apt packages → Make your own base image and set ContainerBaseImage.
Private NuGet feed → Use the same NuGet auth you use in normal builds.

8. Remember

No Dockerfile for most apps.
Images are smaller and run as non‑root.
One command can build and push.