מ-Supabase ל-Production Go: חודש 1
לפני חודשיים בניתי את Info Links. זוהי פלטפורמת משאבים חינמית עבור סטודנטים ב-Le CNAM Lebanon. היא משרתת 300 סטודנטים ו-50 קורסים.
בתחילה, ה-backend השתמש ב-Supabase באופן ישיר. זה עבד, אבל לא יכולתי להגן על הבחירה הזו בראיון טכני. המטרה שלי לחודש הראשון לא הייתה רק ללמוד את התחביר של Go. רציתי לבנות מערכת שמהנדס בכיר יכבד.
הנה מה שהשתנה:
- ה-backend עבר משימוש ב-Supabase בלבד ל-Go REST API.
- בסיס הקוד גדל מ-6 קבצים ליותר מ-100 קבצים.
- הטמעתי ארכיטקטורה שכבתית: API, Service, Repository, ו-Middleware.
- הוספתי dependency injection כדי להסיר משתנים גלובליים.
- כתבתי 6 Architecture Decision Records (ADRs) כדי להסביר את הבחירות שלי.
המבנה החדש עוקב אחר מסלול ברור: HTTP request → Router → Handler → Service → Repository → Postgres.
התמקדתי במוכנות לייצור (production readiness) באמצעות התוספות הבאות:
- Structured logging באמצעות slog.
- Health checks ומדדים (metrics).
- Rate limiting למניעת שימוש לרעה.
- CI עם race detection ו-linting.
- Multi-stage Docker builds.
- כיסוי בדיקות גבוה (93% עבור ה-API ו-96% עבור ה-Service).
ביצעתי גם בדיקות עומסים (load testing) עם k6. שלחתי ל-API 4,400 בקשות בשנייה. ה-rate limiter חסם תעבורה עודפת בפחות מ-1ms. המערכת לא קרסה.
שיעור גדול אחד היה הכלל שלי לשימוש ב-AI. אני מקדיש 45 דקות בכל יום לעבודה ללא AI. אני משתמש בזמן הזה כדי לבצע refactor לקוד או להסביר קובץ בקול רם. אם אני לא יכול להסביר אותו, אני לא משחרר אותו (ship it). זה סוגר את הפער בין "זה עובד" לבין "אני מבין למה זה עובד".
ההנדסה כעת תואמת את המשימה. המוצר נשאר חינם עבור סטודנטים, אבל ה-backend הוא כעת ברמה של ראיונות עבודה (interview-grade).
בחודש הבא, אבנה שירות Go נלווה לבדיקת תקינות קישורים (link health) באמצעות goroutines ו-context.
Live site: infolinks.app GitHub: github.com/MohamadObeid9/Info_Links Telegram: @Info_Links9