🎓 מפתחי בינה מלאכותית - GenAI Engineers

הפרדה בין צד לקוח וצד שרת, ושילוב APIs בין שירותים

234 שעות אקדמיות 2 סמסטרים E2E - קונספט עד ענן

ארכיטקטורה - צד לקוח, צד שרת, ושירותים

כדי לפתח מערכת GenAI יציבה צריך קודם להבין היכן הקוד רץ, איך זורם מידע, ומהו "חוזה" בין חלקי מערכת.

1) מודל Client-Server במבט מערכתי

הדפדפן הוא סביבת הרצה מוגבלת ובטוחה יחסית, שמריצה HTML/CSS/JS עבור תצוגה ואינטראקציה. השרת הוא סביבת הרצה שאנו שולטים בה, וממנה אנו יכולים לגשת למסדי נתונים, סודות (API keys), תורים, קבצים ושירותים נוספים. ההפרדה הזו היא לא "טכנולוגיה", אלא עקרון אבטחה וסקייל.

Client Browser - UI, JS, Fetch אין גישה לסודות/DB Server API - FastAPI / Node DB, Cache, Secrets HTTP Request (GET/POST) HTTP Response (HTML/JSON)
מודל בקשה-תגובה: הדפדפן שולח בקשה (Request) והשרת מחזיר תשובה (Response). על גבי זה בנוי REST.
מה חשוב להבין בהפרדה הזו?
  • אבטחה: מפתח ל-LLM או למסד נתונים לא אמור להופיע בקוד שרץ בדפדפן.
  • ביצועים: פעולות כבדות או איטיות (למשל קריאת DB, תיווך למודל, כתיבה לקבצים) שייכות לשרת.
  • אמינות: השרת צריך לנהל Timeouts, Retries, Rate Limits, תורים וניטור.
  • חוזים: ה-API הוא חוזה שמאפשר לצוותים לעבוד במקביל.

2) API בין שירותים (Services-to-Services)

במערכת GenAI אמיתית יש יותר משרת אחד: שירות API, שירות חיפוש/אינדוקס, שירות לוגים, שירות תשלומים, ולעתים גם שירות "תיווך מודלים". במקום לקשור את כולם למונולית, מקימים גבולות ברורים - כל שירות אחראי על תחום אחד ומדבר עם אחרים דרך API.

API Gateway Auth, Rate limit Routing LLM Service Tool calling, prompts Data Service DB, cache, RAG store Observability Logs, metrics, traces
חלוקה טיפוסית: שער כניסה (Gateway), שירות מודלים, שירות מידע, ותשתיות ניטור. הקווים מייצגים קריאות API פנימיות.

3) עקרונות תכנון חוזי API

חוזה יציב

חוזה הוא לא "URL" בלבד. הוא כולל פורמט בקשה, פורמט תשובה, קודי שגיאה, גרסאות, ומגבלות קצב. חוזה טוב מאפשר פיתוח מקבילי: צד אחד מתקדם, הצד השני נשען על ה-Contract.

כלים: OpenAPI/Swagger, סכמות Pydantic, תיעוד Redoc.

גבולות (Boundaries)

משתדלים שלא "לדלוף" פרטים פנימיים בין שירותים. לדוגמה: שירות תשלומים לא אמור לדעת איך בנוי מסד המשתמשים. הוא אמור לקבל user_id ולקבל תשובה של "האם מותר". זה מאפשר החלפה או שדרוג ללא שבר.

כלל אצבע: כל שירות בעל בעלות נתונים (data ownership) ברורה.

טעויות נפוצות בארכיטקטורה של מתחילים
  • מפתח API בדפדפן: גורם לניצול ושימוש לרעה.
  • API בלי סטנדרט שגיאות: כל צוות "ממציא" פורמט, ומכאן באגים.
  • מיקרו-שירותים מוקדם מדי: אם אין צורך, זה מוסיף מורכבות תפעולית.
  • אין observability: בלי לוגים ומדדים אתה "עיוור" בפרודקשן.

המשך טבעי מכאן הוא להבין איך מתכננים REST נכון - בעמוד הבא.

לקריאת הפרק על REST API