𝗙𝗿𝗼𝗺 𝗦𝘂𝗽𝗮𝗯𝗮𝘀𝗲 𝘁𝗼 𝗣𝗿𝗼𝗱𝘂𝗰𝘁𝗶𝗼𝗻 𝗚𝗼: 𝗠𝗼𝗻𝘁𝗵 𝟭
Two months ago, I built Info Links. It is a free resource platform for students at Le CNAM Lebanon. It serves 300 students and 50 courses.
Initially, the backend used Supabase directly. It worked, but I could not defend it in a technical interview. My goal for Month 1 was not just learning Go syntax. I wanted to build a system a senior engineer would respect.
Here is what changed:
- The backend moved from Supabase-only to a Go REST API.
- The codebase grew from 6 files to over 100 files.
- I implemented a layered architecture: API, Service, Repository, and Middleware.
- I added dependency injection to remove global variables.
- I wrote 6 Architecture Decision Records (ADRs) to explain my choices.
The new structure follows a clear path: HTTP request → Router → Handler → Service → Repository → Postgres.
I focused on production readiness through these additions:
- Structured logging with slog.
- Health checks and metrics.
- Rate limiting to prevent abuse.
- CI with race detection and linting.
- Multi-stage Docker builds.
- High test coverage (93% for API and 96% for Service).
I also performed load testing with k6. I hit the API with 4,400 requests per second. The rate limiter blocked excess traffic in under 1ms. The system did not crash.
One big lesson was my rule for using AI. I spend 45 minutes every day working without AI. I use this time to refactor code or explain a file out loud. If I cannot explain it, I do not ship it. This closes the gap between "it works" and "I understand why it works."
The engineering now matches the mission. The product remains free for students, but the backend is now interview-grade.
Next month, I will build a companion Go service to check link health using goroutines and context.
Live site: infolinks.app GitHub: github.com/MohamadObeid9/Info_Links Telegram: @Info_Links9