תוכנית הקמה מינימלית וניתנת להרחבה
ההחלטה שלי בשבילך: להתחיל עם VPS אחד, Docker Compose, Caddy, Node/Fastify, PostgreSQL ו־Prisma — דף חלק, בלי העברת נתונים קיימים, אבל עם אפשרות Scale Up בעתיד.
למה זו הדרך הנכונה
- שרת אחד בלבד בהתחלה.
- עלות נמוכה ופחות תקלות.
- לא בונים את המשחקים מחדש.
- כל הקרדיטים עוברים דרך API בטוח.
- בעתיד אפשר לפצל DB, Frontend ו־API.
החלק הכי חשוב
כל שינוי קרדיטים חייב לקרות בשרת בלבד, בתוך database transaction. ה־Frontend לא משנה קרדיטים ישירות.
תוכנית החלטות
| # | תחום | החלטה | מה עושים | למה |
|---|---|---|---|---|
| 1 | מטרת ההקמה | מעבר נקי ודף חלק | מקימים מערכת חדשה מאפס בלי להעביר נתונים קיימים. יוצרים Owner ראשון, 12 משחקים והגדרות בסיסיות. | הכי מהיר, זול ופשוט להתחלה. |
| 2 | תשתית התחלתית | VPS אחד בלבד | שרת אחד עם Ubuntu 24.04, 2 vCPU, 4GB RAM, 80GB SSD. | מעט תשתיות, פחות תקלות ועלות נמוכה. |
| 3 | ספק שרת | Hetzner או DigitalOcean | להקים שרת באזור קרוב לקהל המשתמשים. | שירותים יציבים ופשוטים לניהול. |
| 4 | ניהול שירותים | Docker Compose | מריצים API, Database ו־Caddy בקובץ compose אחד. | קל להעברה, גיבוי ו־Scale Up בעתיד. |
| 5 | HTTPS ו־Proxy | Caddy | Caddy נותן SSL אוטומטי ומנתב app/API. | פחות התעסקות מ־Nginx ו־Certbot. |
| 6 | Backend | Node.js 22 + Fastify | בונים API חיצוני מהיר לכל הפעולות: Login, שחקנים, קרדיטים, ספינים ודוחות. | מהיר, קל, מתאים לגדילה. |
| 7 | Database | PostgreSQL 16 | שומר players, admins, game_configs, spins, transactions, settings, audit_logs. | אמין מאוד ומתאים לפעולות קרדיטים. |
| 8 | ORM | Prisma | מגדירים schema ו־migrations לטבלאות. | מסדר את מסד הנתונים ומקל על שינויים. |
| 9 | אימות | JWT + bcrypt | Login מחזיר token, סיסמאות נשמרות מוצפנות. | עצמאי, בטוח ולא תלוי במערכת חיצונית. |
| 10 | Frontend | React/Vite הקיים | לא בונים את המשחקים מחדש. מחליפים רק את שכבת הנתונים ל־API חיצוני. | חוסך זמן ושומר את מה שכבר בנוי. |
| 11 | Frontend Hosting | בהתחלה באותו VPS | Caddy מגיש את ה־build של האפליקציה. | לא צריך עוד שירותים בהתחלה. |
| 12 | דומיינים | app ו־api | app.yourdomain.com לאפליקציה, api.yourdomain.com לשרת. | הפרדה נקייה ומוכנה לגדילה. |
| 13 | אבטחת שרת | SSH Key + Firewall | פותחים רק 22, 80, 443. PostgreSQL לא פתוח החוצה. | בסיס אבטחה הכרחי. |
| 14 | טבלאות | רק מה שצריך | players, admin_accounts, game_configs, spin_results, token_transactions, app_settings, audit_logs. | מבנה נקי בלי עומס מיותר. |
| 15 | Seed ראשוני | Owner + משחקים + Settings | מכניסים Owner ראשון, 12 משחקים, RTP התחלתי והגדרות מערכת. | המערכת מוכנה לעבודה מהר. |
| 16 | קרדיטים | רק דרך השרת | ה־Frontend לא משנה קרדיטים ישירות. כל שינוי עובר דרך API. | מונע טעויות, כפילויות ורמאות. |
| 17 | Atomic Transactions | חובה | grant-player, fund-admin, redeem ו־spin payout רצים בתוך database transaction. | אם פעולה נכשלת באמצע, הכל חוזר אחורה. |
| 18 | Idempotency | מניעת לחיצה כפולה | מוסיפים idempotency key לפעולות קרדיטים וספינים. | מונע חיוב כפול מלחיצה כפולה. |
| 19 | API Version | /v1 | כל הנתיבים יהיו תחת /v1. | מאפשר שדרוג עתידי בלי לשבור את האפליקציה. |
| 20 | Validation | Zod | בודקים כל בקשת API לפני שמכניסים ל־DB. | שומר על נתונים נקיים. |
| 21 | Logging | Pino | רושמים בקשות ושגיאות בלוגים מסודרים. | קל לאתר תקלות. |
| 22 | Audit Log | טבלת audit_logs | שומרים login failed, grant credits, redeem, role change, password reset. | בקרה וניהול בטוחים. |
| 23 | דוחות | חישוב ב־API | Daily P/L, player summary ו־admin credit reports מחושבים בשרת. | ה־Frontend נשאר קל ומהיר. |
| 24 | Backups | גיבוי יומי | pg_dump יומי ל־PostgreSQL ושמירה מוצפנת. | חובה כדי לא לאבד נתונים. |
| 25 | Monitoring | /v1/health | Health endpoint ובדיקת זמינות חיצונית. | מקבלים התראה אם השרת נופל. |
| 26 | סדר עבודה 1 | תשתית | VPS, Docker, Caddy, PostgreSQL, health check. | בסיס יציב לפני פיתוח. |
| 27 | סדר עבודה 2 | Auth + Users | Player login, Admin login, JWT, roles, password hash. | בלי הרשאות אין מערכת בטוחה. |
| 28 | סדר עבודה 3 | ניהול בסיסי | Players API, Admins API, GameConfig API. | מחליף את ניהול הנתונים הקיים. |
| 29 | סדר עבודה 4 | Credit API | fund-admin, grant-player, redeem עם transactions. | הלב הכספי של המערכת. |
| 30 | סדר עבודה 5 | Spins API | שמירת ספינים, הימור, זכייה, paylines ו־RTP. | מחבר את המשחקים למסד החדש. |
| 31 | סדר עבודה 6 | חיבור Frontend | מחליפים קריאות Base44 בקריאות API חיצוני. | המשחקים נשארים, רק הנתונים משתנים. |
| 32 | סדר עבודה 7 | בדיקות | Login, יצירת שחקן, טעינת קרדיטים, Spin, Bonus, Redeem, Daily P/L. | מאשר שהמערכת מוכנה. |
| 33 | Scale Up ראשון | Managed PostgreSQL | כשיש עומס, מעבירים DB החוצה ומשנים DATABASE_URL. | השדרוג הכי חשוב והכי פשוט. |
| 34 | Scale Up שני | Cloudflare Pages | מעבירים Frontend ל־CDN. | טעינה מהירה יותר ופחות עומס על השרת. |
| 35 | Scale Up שלישי | כמה שרתי API | מריצים כמה API instances מאחורי Load Balancer. | מתאים לעומס גבוה בעתיד. |
| 36 | החלטה סופית | VPS + Docker + Caddy + Fastify + PostgreSQL + Prisma | זו התוכנית המינימלית שאני ממליץ להתחיל איתה. | זולה, מהירה, נקייה ומוכנה לגדילה. |
פירוט ביצוע מעשי — מה עושים בכל סעיף
כאן נכנס גם ה־ZIP שהורדת: בשלב 6 פותחים אותו בתיקיית ה־Frontend, ואז בשלב 7 מתחילים לחבר אותו ל־API החדש.
| שלב | פעולה | מה עושים בדיוק | תוצאה |
|---|---|---|---|
| 1 | פתיחת חשבון שרת | פותחים חשבון אצל Hetzner או DigitalOcean, מוסיפים אמצעי תשלום, ובוחרים אזור שרת קרוב לקהל המשתמשים. | יש חשבון Cloud מוכן להקמת שרת. |
| 2 | יצירת VPS | יוצרים שרת Ubuntu 24.04 עם 2 vCPU, 4GB RAM ו־80GB SSD. נותנים לו שם ברור כמו pog-production. | יש שרת ריק באינטרנט עם כתובת IP. |
| 3 | חיבור דומיין | בניהול הדומיין יוצרים שתי רשומות: app שמצביעה ל־IP של השרת ו־api שמצביעה לאותו IP. | app.yourdomain.com ו־api.yourdomain.com מגיעים לשרת. |
| 4 | גישה מאובטחת לשרת | מגדירים SSH Key, מתחברים לשרת, ומוודאים שלא עובדים עם סיסמה רגילה לכניסה לשרת. | גישה בטוחה לשרת. |
| 5 | הכנת תיקיות עבודה | יוצרים תיקייה ראשית /var/www/pog ובתוכה frontend, api, database, backups, caddy. | יש מבנה תיקיות ברור לכל חלק במערכת. |
| 6 | איפה שמים את ה־ZIP | את ה־ZIP שהורדת מ־Base44 פותחים בתוך /var/www/pog/frontend. זה הקוד של האפליקציה והמשחקים הקיימים. | קוד האפליקציה נמצא במקום הנכון על השרת. |
| 7 | הכנת Frontend לעבודה חיצונית | בתוך קוד ה־Frontend מחליפים בהדרגה את קריאות Base44 לקריאות ל־API החדש, דרך קובץ apiClient אחד. | האפליקציה מתחילה לדבר עם השרת שלך במקום עם Base44. |
| 8 | התקנת Docker | מתקינים Docker ו־Docker Compose על ה־VPS כדי להריץ את כל השירותים בצורה מסודרת. | השרת מוכן להריץ containers. |
| 9 | יצירת docker-compose | יוצרים docker-compose.yml שמגדיר שלושה שירותים: api, postgres, caddy. PostgreSQL מקבל volume קבוע לשמירת נתונים. | כל המערכת עולה בפקודה אחת. |
| 10 | הגדרת Caddy | מגדירים Caddy כך ש־app.yourdomain.com מציג את ה־Frontend ו־api.yourdomain.com מעביר בקשות ל־API. | HTTPS וניתוב עובדים אוטומטית. |
| 11 | יצירת Backend API | בתיקיית /var/www/pog/api מקימים פרויקט Node.js עם Fastify. מתחילים מ־/v1/health שמחזיר שהשרת חי. | יש API בסיסי פעיל. |
| 12 | חיבור Database | מגדירים PostgreSQL ב־Docker, יוצרים DATABASE_URL, ומחברים את ה־API למסד הנתונים. | ה־API מצליח לקרוא ולכתוב ל־Database. |
| 13 | Prisma Schema | מגדירים Prisma עם הטבלאות: players, admin_accounts, game_configs, spin_results, token_transactions, app_settings, audit_logs. | מבנה מסד הנתונים מוגדר בקוד. |
| 14 | הרצת Migration | מריצים migration שמייצר בפועל את הטבלאות ב־PostgreSQL. | כל הטבלאות קיימות במסד הנתונים. |
| 15 | Seed ראשוני | מריצים seed שמכניס Owner ראשון, 12 משחקים, RTP התחלתי והגדרות מערכת בסיסיות. | המערכת מתחילה נקייה אבל מוכנה להתחברות ראשונית. |
| 16 | בניית Login | בונים endpoints עבור player-login ו־admin-login. הסיסמאות נשמרות עם bcrypt והשרת מחזיר JWT. | שחקן ו־Admin יכולים להתחבר דרך השרת החדש. |
| 17 | הרשאות Roles | מוסיפים בדיקה בכל endpoint: Player, Admin, Owner. כל פעולה מקבלת הרשאות לפי התפקיד. | אי אפשר לגשת לפעולה לא מורשית. |
| 18 | Players API | בונים יצירה, עדכון, רשימה וטעינת שחקן מחובר. Admin רואה רק שחקנים שלו, Owner רואה הכל. | ניהול שחקנים עובד חיצונית. |
| 19 | Admins API | בונים יצירה, עדכון, שינוי תפקיד, שינוי סיסמה ומימון Admin. רק Owner מקבל גישה מלאה. | ניהול אדמינים עובד חיצונית. |
| 20 | Game Config API | בונים טעינת משחקים ועדכון RTP/active לכל משחק. | הלובי והאדמין מקבלים הגדרות משחקים מהשרת החדש. |
| 21 | Credit API | בונים fund-admin, grant-player ו־redeem. כל פעולה חייבת database transaction ויוצרת token_transaction. | קרדיטים עוברים בצורה מדויקת ובטוחה. |
| 22 | Spin API | בונים יצירת spin ועדכון win_amount. כל משחק שולח לשרת הימור, זכייה, game_id ו־rtp_at_time. | כל ספין נשמר במסד החדש. |
| 23 | Reports API | בונים Daily P/L, דוח שחקן, דוח תנועות קרדיטים ודוח משחקים. | האדמין יכול לראות דוחות מהשרת החדש. |
| 24 | חיבור האפליקציה ל־API | ב־Frontend יוצרים apiClient שמחזיק את API URL ואת ה־JWT. כל מסך עובר להשתמש בו במקום Base44. | האפליקציה עובדת מול השרת העצמאי. |
| 25 | Build ל־Frontend | אחרי החיבור ל־API מריצים build וממקמים את תיקיית dist במקום ש־Caddy מגיש. | האפליקציה זמינה ב־app.yourdomain.com. |
| 26 | בדיקות התחברות | בודקים Owner, Admin ושחקן. בודקים סיסמה שגויה, משתמש נעול והרשאות. | Login והרשאות תקינים. |
| 27 | בדיקות קרדיטים | בודקים Owner מממן Admin, Admin מטעין שחקן, שחקן עושה Redeem וכל פעולה מופיעה בדוחות. | מערכת הקרדיטים תקינה. |
| 28 | בדיקות משחקים | בודקים Spin רגיל, זכייה, בונוס, הורדת הימור, עדכון קרדיטים ושמירת SpinResult. | המשחקים עובדים מול השרת החדש. |
| 29 | גיבוי יומי | מגדירים גיבוי יומי של PostgreSQL לתיקיית /var/www/pog/backups ושמירה של כמה ימים אחורה. | יש הגנה בסיסית מאובדן נתונים. |
| 30 | בדיקת עלייה לאוויר | מבצעים בדיקה מלאה: Login, יצירת Admin, יצירת Player, טעינה, משחק, Redeem, דוחות. | אפשר להתחיל להשתמש במערכת החדשה. |