Architektúra Blackrent: monorepo, Neon, edge

Blackrent začal ako jednoduchá rezervačná stránka. Dnes je to platforma s 4 frontendmi (zákaznícky web, klientsky portál, admin, React Native servisná appka), spoločným backendom a Postgres databázou na Neone. Tu je, prečo sme zvolili práve túto architektúru a kde sme spravili kompromisy.

Monorepo, ale nie kvôli hype

Použili sme pnpm workspaces + Turbo. Hlavná motivácia nebola "jeden repo pre všetko", ale jeden zdiel — packages/db. Drizzle schema je share-ovaná medzi všetkými 4 appkami, takže keď pridáme stĺpec, TypeScript okamžite zhodí build na každej appke ktorá ho potrebuje.

• apps/customer-website — Next 16 SSG/ISR
• apps/client-portal — Next 16 SSR (auth-gated)
• apps/admin — Next 16 SSR (RBAC)
• apps/service-mobile — Expo / React Native
• packages/db — Drizzle schema + migrations
• packages/ui — shadcn primitivy

Neon serverless driver, nie pg pool

Na Verceli serverless funkciách dramaticky lepšie funguje @neondatabase/serverless než klasický pg + connection pool. Dôvod: HTTP fetch driver bez perzistentného TCP — žiadne "too many connections" pri scale-out, žiadny pooler navyše.

import { neon } from '@neondatabase/serverless';
import { drizzle } from 'drizzle-orm/neon-http';

const sql = neon(process.env.DATABASE_URL!);
export const db = drizzle(sql, { schema });

Čo sme spravili zle (a opravili)

1. Začali sme s tRPC. Opustili — pre 4 nezávislé klienty bolo zbytočne tesné prepojenie. Dnes REST + Zod + ts-rest pre interný admin.
2. Mali sme custom JWT auth. Migrovali na better-auth — menej kódu, viac featúr (sessions, MFA, sociálne loginy).
3. Storage v S3-kompat. Opustili — cloudflare R2 + presigned URL je 5× lacnejšie pri rovnakej rýchlosti pre EÚ.

Čísla, ktoré nás zaujímali

• p95 SSR latency: 180 ms (Frankfurt edge)
• DB read p95: 28 ms (Neon EU)
• Mobilná appka cold start: 1.4 s na iPhone 12
• Lighthouse Performance customer-website: 96