DEV Community

Cover image for From Supabase-only to production Go: Month 1 of rebuilding Info Links
Mohamad Obeid
Mohamad Obeid

Posted on

From Supabase-only to production Go: Month 1 of rebuilding Info Links

#go #webdev #career #showdev

Two months ago I wrote about building Info Links — a free course resource platform for students at Le CNAM Lebanon. Telegram channel, 300+ students, 50+ courses, no paywall, ever.

At the end of that post I said the next step was learning Go and rebuilding the backend properly. Not a tutorial todo app. A real REST API behind a live product people actually use.

That was the plan. This is what Month 1 actually looked like.

The promise vs. the starting point

When I wrote that first post, the "backend" was mostly Supabase. The frontend talked to Postgres through Supabase's client. GitHub Pages served static files. It worked — but it wasn't a backend I could defend in an interview.

My Month 1 goal wasn't "learn Go syntax." It was: make Info Links survive a senior engineer reading the repo for 15 minutes.

That meant:

  • Real layered architecture (not everything in handlers)
  • Tests you can run without a database
  • Observability, health checks, CI
  • Documentation that explains why, not just what

I gave myself one month. Here's the scorecard.

What shipped

1. A real Go backend (not a rewrite for the sake of it)

The frontend stayed vanilla HTML/CSS/JS — same UX students already knew. What changed is everything behind it:

  • Go REST API serving /api/* endpoints
  • Same Postgres database (Supabase-hosted), but the Go server owns the API layer
  • JWT admin auth through the backend instead of direct client-side Supabase calls for admin operations
  • Static file serving from the Go binary — one deploy, one service

The repo went from ~6 backend files with SQL mixed into handlers to 100+ Go files across api, service, repository, middleware, seo, and more.

That sounds like a lot. It is. But it's organized now — not accidental complexity.

2. Architecture I can explain out loud

The biggest single win wasn't a feature. It was structure.

Before: global DB singleton, SQL in handlers, hard to test.

After:

HTTP request → router → handler → service → repository → Postgres
Enter fullscreen mode Exit fullscreen mode
  • internal/repository — SQL lives here, behind interfaces
  • internal/service — validation and business rules, no HTTP
  • internal/api — thin handlers: decode JSON, call service, return status codes

Dependency injection from main. No globals. Handlers mockable. This was the refactor I was most afraid of. It's also the one I'm most glad I did.

I wrote 6 Architecture Decision Records (docs/adr/) explaining choices like:

  • Why net/http instead of Gin/Fiber
  • Why Supabase stays for Postgres hosting
  • Why Render instead of GitHub Pages for the full stack
  • Why server-side SEO pages exist alongside the SPA

If an interviewer asks "why didn't you use X?" — I have an answer that isn't "I didn't know about X."

3. Production hygiene (the unglamorous stuff that matters)

This is the part that doesn't screenshot well but shows up in every backend job description:

Thing Status
Structured logging (slog) ✅
/healthz + /readyz ✅
Prometheus /metrics ✅
Request ID + panic recovery middleware ✅
Rate limiting (golang.org/x/time/rate) ✅
CI: go test -race, golangci-lint, govulncheck ✅
Multi-stage Dockerfile + docker-compose ✅
Load testing with k6 + written results ✅

The load test was genuinely fun. I hammered /api/content at 4,400 req/s from a single IP — the rate limiter returned 429 in under 1ms without touching the database. Zero crashes. That's interview gold: "I load-tested my own service and documented what broke."

Test coverage on internal/api (~93%) and internal/service (~96%) — table-driven tests, mocked repositories, the works.

4. SEO without abandoning the SPA

Students still get the fast client-side app. Crawlers get server-rendered HTML for course pages, sitemap, and robots.txt. Best of both worlds, one Go server.

5. Learnings docs (the "AI-pair, human-owned" habit)

For every major package I wrote a docs/learnings/*.md file — my own words explaining request flow, middleware order, error mapping, SEO rendering. Not for GitHub stars. So I can whiteboard my own code without an agent open beside me.

That habit was the hardest part of Month 1. More on that below.

What broke (and what I learned from it)

The "product looks bigger than the code" problem

My first post made Info Links sound like a big platform. And it is — for students. But an interviewer can read your backend in one sitting. Month 1 wasn't about adding features. It was about making the engineering match the story.

AI-pair coding is fine. Not understanding your own code is not.

I used AI heavily — same as the first build. The difference this month: I added a rule. 45 minutes daily, no AI. Refactor something. Explain a file out loud. If I can't, I don't ship it yet.

Some nights that 45 minutes felt pointless. Then I'd hit an interview-style question in my own head — "why is the service layer separate from the repository?" — and realize I actually knew the answer. That matters more than any LeetCode streak right now.

By the numbers (Month 1)

  • Backend: Supabase-direct → Go REST API on Render
  • Go files: ~6 → 100+
  • ADRs: 0 → 6
  • Test coverage: ~0% → ~93% (api) / ~96% (service)
  • Middleware stack: none → logging, metrics, rate limit, auth, recovery, request ID
  • Load test doc: yes, with real k6 numbers
  • Blog posts planned: 2 → this is #2 (closing Month 1)

The product still serves the same community. Same free ethos. Same Telegram channel. Same GitHub repo. The engineering finally caught up to the story I was telling.

Closing Month 1 honestly

Did I hit every checkbox on my roadmap? Almost. The important ones — architecture, tests, observability, CI, ADRs, load testing, learnings docs — yes.

What's still ahead:

  • Month 2: a companion Go service (link health checker worker — goroutines, context, errgroup)
  • OSS contributions to popular Go repos
  • Job applications with this repo as the centerpiece
  • Mock interviews and the uncomfortable parts

Month 1 was about making Info Links interview-grade. I think it is now — or at least, it's the first version of my backend I'd be willing to walk a senior engineer through without sweating.

Month 2 is about proving it wasn't a one-time effort.

Where to find it

If you rebuilt a project specifically to learn a language — not as a tutorial clone, but as something real people use — what was the hardest part? Architecture? Testing? Deployment? Convincing yourself you actually understood what you shipped?

For me it was the gap between "it works" and "I can explain every layer without looking at the screen." Month 1 was about closing that gap.

The best projects still start with a real problem. Mine started in a group chat full of students asking for the same link every semester. Two months and one Go backend later — still the same problem, better engineering.

Top comments (0)