- אבטחה: מפתח ל-LLM או למסד נתונים לא אמור להופיע בקוד שרץ בדפדפן.
- ביצועים: פעולות כבדות או איטיות (למשל קריאת DB, תיווך למודל, כתיבה לקבצים) שייכות לשרת.
- אמינות: השרת צריך לנהל Timeouts, Retries, Rate Limits, תורים וניטור.
- חוזים: ה-API הוא חוזה שמאפשר לצוותים לעבוד במקביל.
ארכיטקטורה - צד לקוח, צד שרת, ושירותים
כדי לפתח מערכת GenAI יציבה צריך קודם להבין היכן הקוד רץ, איך זורם מידע, ומהו "חוזה" בין חלקי מערכת.
1) מודל Client-Server במבט מערכתי
הדפדפן הוא סביבת הרצה מוגבלת ובטוחה יחסית, שמריצה HTML/CSS/JS עבור תצוגה ואינטראקציה. השרת הוא סביבת הרצה שאנו שולטים בה, וממנה אנו יכולים לגשת למסדי נתונים, סודות (API keys), תורים, קבצים ושירותים נוספים. ההפרדה הזו היא לא "טכנולוגיה", אלא עקרון אבטחה וסקייל.
מה חשוב להבין בהפרדה הזו?
2) API בין שירותים (Services-to-Services)
במערכת GenAI אמיתית יש יותר משרת אחד: שירות API, שירות חיפוש/אינדוקס, שירות לוגים, שירות תשלומים, ולעתים גם שירות "תיווך מודלים". במקום לקשור את כולם למונולית, מקימים גבולות ברורים - כל שירות אחראי על תחום אחד ומדבר עם אחרים דרך API.
3) עקרונות תכנון חוזי API
חוזה יציב
חוזה הוא לא "URL" בלבד. הוא כולל פורמט בקשה, פורמט תשובה, קודי שגיאה, גרסאות, ומגבלות קצב. חוזה טוב מאפשר פיתוח מקבילי: צד אחד מתקדם, הצד השני נשען על ה-Contract.
כלים: OpenAPI/Swagger, סכמות Pydantic, תיעוד Redoc.
גבולות (Boundaries)
משתדלים שלא "לדלוף" פרטים פנימיים בין שירותים. לדוגמה: שירות תשלומים לא אמור לדעת איך בנוי מסד המשתמשים. הוא אמור לקבל user_id ולקבל תשובה של "האם מותר". זה מאפשר החלפה או שדרוג ללא שבר.
כלל אצבע: כל שירות בעל בעלות נתונים (data ownership) ברורה.
טעויות נפוצות בארכיטקטורה של מתחילים
- מפתח API בדפדפן: גורם לניצול ושימוש לרעה.
- API בלי סטנדרט שגיאות: כל צוות "ממציא" פורמט, ומכאן באגים.
- מיקרו-שירותים מוקדם מדי: אם אין צורך, זה מוסיף מורכבות תפעולית.
- אין observability: בלי לוגים ומדדים אתה "עיוור" בפרודקשן.
המשך טבעי מכאן הוא להבין איך מתכננים REST נכון - בעמוד הבא.