Original Summary

I’ve been working on an exam practice site called TestHarbour , and after changing the stack a few times, I ended up with something fairly simple. The basic setup looks like this: User | v Cloudflare | v Caddy | +--------> Next.js frontend | +--------> Go API | v PostgreSQL Everything runs with Docker Compose on a small Ubuntu VPS. The frontend is Next.js + React + Tailwind . It handles the public pages, practice interface, account pages, results, and the usual UI stuff. The backend is written in Go . I keep most of the actual application logic there instead of stuffing everything into Next.js. The API handles questions, practice sessions, user progress, access control, admin functions, and payment-related logic. For the database I’m using PostgreSQL . The main data is roughly split into things like: users questions answers practice_sessions practice_attempts subscriptions/access payments Questions are imported from structured files rather than entered manually one by one. That turned out to be pretty useful because I can build or review a question set separately and then import it into the site. For deployment, I currently run four main pieces: frontend backend postgres caddy Only Caddy is exposed publicly. I don’t expose ports like 3000, 8080, or 5432 directly to the internet. Caddy handles HTTPS and routes traffic to the frontend/backend containers internally. Cloudflare sits in front mainly for DNS and some basic protection. One thing I deliberately avoided was putting everything into one giant application. The frontend can change without touching the database layer too much, and the Go backend is small enough that I can still understand what is happening when something breaks. For payments, the site uses Stripe Checkout. The browser doesn’t decide whether someone has paid. Stripe sends a webhook to the backend, the backend verifies it, and then access is updated in PostgreSQL. That part looks more like: User | v Stripe Checkout | v Stripe Webhook | v Go backend | v PostgreSQL I also keep test and production payment settings separate. That saved me from a few stupid mistakes while setting things up. The biggest lesson from building this wasn’t really about choosing Go vs Node or PostgreSQL vs something else. It was keeping the pieces boring. A normal frontend, a normal API, a normal database, Docker, and a reverse proxy. Once the project started getting bigger, that mattered a lot more than trying to use the newest stack. If I were starting it again today, I’d probably use almost the same architecture.   submitted by   /u/Actual-Climate-8882 [link]   [comments]

  • 情报分类：服务器与云资源
  • 分类依据：内容涉及服务器、云资源或网络线路
  • 信息来源：Reddit · SideProject
  • 发布时间：2026/9/21 01:15:46