DEV Community: Mohamad Obeid

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

Mohamad Obeid — Sat, 20 Jun 2026 06:29:27 +0000

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

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

🌐 Live site: infolinks.app
💻 GitHub: github.com/MohamadObeid9/Info_Links
📢 Telegram: @Info_Links9
📖 Part 1: I built a free course resource platform for my university

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.

[Boost]

Mohamad Obeid — Thu, 16 Apr 2026 15:36:17 +0000

Mohamad Obeid

Apr 16

I built a free course resource platform for my university — here's the real story

#showdev #opensource #beginners #webdev

3 min read

I built a free course resource platform for my university — here's the real story

Mohamad Obeid — Thu, 16 Apr 2026 07:24:41 +0000

I'm a CS student in my third year at Le CNAM Lebanon. A few months ago I noticed something frustrating — students were constantly asking each other in random group chats: "does anyone have the link for X course materials?" Every semester, the same chaos. No central place. No organization. Just noise.

So in February 2025 I started a Telegram channel called Info Links — just me, manually organizing course links, Telegram groups, Google Drive folders, and Google Classroom links by program, year, and semester. No code. No fancy tools. Just organization and consistency.

What started as one person with a simple idea grew to 300+ students in under a year. Posts were hitting 3000+ views. I realized the problem was real — and bigger than I thought.

For months I dreamed about turning it into a proper website. A couple days ago, on April 11th, I finally did.

What I built

Info Links is now a full platform covering 50+ courses — from foundational subjects all the way through License and partial Master's degrees in Computer Science.

For students:

🔍 Smart search by course name or code
📋 Courses organized by program, year, and semester
🔗 Multiple resource types per course — Google Drive, Google Classroom, Telegram, and external links
🏷️ Optional vs mandatory course tagging
🌓 Light/Dark mode, fully responsive
💬 Submit new resources or report broken links directly from the site
⭐ Feedback System — Rate the platform and provide suggestions

For me as admin:

Full course management — add, edit, delete, organize
Analytics dashboard — daily visitors, 7/30/90-day and all-time stats
Contribution review — approve or reject user-submitted resources
Report management — handle broken link reports
JSON export for full data backup
Feedback Management — View and manage user feedback and ratings

The tech

Frontend: Pure HTML5, CSS3, Vanilla JavaScript
Backend/Database: Supabase (PostgreSQL)
Deployment: GitHub Pages
Built with: Claude AI as my pair programmer

No framework. No build step. One focused project that does exactly what it needs to do.

Why free, always

Someone asked me why I don't charge for access — I could easily charge for the content, honestly.

My answer: if I was a broke student looking for my course materials, I wouldn't pay. So I won't charge. Simple as that.

This project exists because of the community. It belongs to the community.

What's next

I'm learning Go and plan to rebuild the backend as a proper REST API with PostgreSQL. The frontend stays the same — the backend becomes my real Go learning project, with an actual use case instead of another tutorial todo app.

The goal isn't just to learn Go. It's to eventually open this up so any university can self-host their own version of Info Links for their students.

Where to find it

🌐 Live site: infolinks.app
💻 GitHub: github.com/MohamadObeid9/Info_Links
📢 Telegram channel: @Info_Links9

What's the most useful thing someone built for their university or local community that you've seen? Looking for inspiration on where to take this next.

The best projects start with a real problem. This one started with students asking the same question over and over in a group chat. Sometimes that's all it takes.

Update (Jun 2026): Month 1 of the Go rebuild is done — read what shipped.