מערכת המפותחת בגישה של Micro Services בנויה מסרביסים קטנים ועצמאיים. במערכת כזאת עוזר לפעמים לבנות סרביס אחד שיחבר בין הסרביסים השונים ויהיה סוג של דלת כניסה למערכת. לסרביס כזה אנחנו קוראים API Gateway.

בשביל להבין איך API Gateway מתפקד או למה צריך אותו, בואו נדמיין מערכת Micro Services של חנות דיגיטלית. במערכת יכולים להיות לנו הסרביסים הבאים:

1. סרביס קטלוג מוצרים, בו מנהל מערכת יכול לעדכן פרטים על המוצרים השונים בחנות והמלאי שלהם.

2. סרביס ניהול פרופילים לקונים, שאחראי על טיפול במשתמשי האתר ושמירת המידע שלהם.

3. סרביס הזמנות ותשלומים.

4. סרביס המלצות, שאחראי על חיבור מידע ממספר מקורות כדי ליצור המלצות מותאמות אישית לגולשים.

5. סרביס סטטיסטיקות שאחראי על איסוף סטטיסטיקות של תנועה באתר כדי לעזור ל Product לשפר את המערכת.

בתוך מערכת כזאת אפשר לדמיין קוד Front End שאחראי להצגת דף הבית של גולש שחוזר לאתר אחרי שכבר קנה מוצרים בעבר:

1. הוא יצטרך לתקשר עם סרביס קטלוג המוצרים כדי לזהות איזה מוצרים "מקודמים" ומופיעים עכשיו בדף הבית.

2. הוא יצטרך לתקשר עם סרביס ההמלצות, כדי לראות אם יש המלצות אישיות לאותו גולש.

3. הוא יצטרך לתקשר עם סרביס הפרופילים, כדי להציג לגולש את תמונת הפרופיל שלו בצד של המסך.

4. הוא יצטרך לתקשר עם סרביס הסטטיסטיקות כל פעם שמשתמש מבצע פעולה באתר.

שמירת הכתובות של כל הסרביסים השונים בקוד JavaScript עשויה להיות מסורבלת. ואם נצטרך לשנות את הכתובות נצטרך בהתאמה גם להעלות גירסה לקוד צד הלקוח. בנוסף, אם כל סרביס רץ על שרת או פורט שונה, הסרביסים יצטרכו לתאם מדיניות CORS כדי שעוגיות יגיעו מהלקוח בצורה נכונה לכל סרביס, או שקוד צד הלקוח יצטרך לנהל בעצמו גישה באמצעות טוקנים.

אבל אולי הבעיה הכי גדולה היא שקוד צד הלקוח צריך להוציא מספר בקשות HTTP ב Ajax רק בשביל להראות את עמוד הבית. ככל שיש יותר בקשות כך זמן הטעינה גדול יותר ואין לנו שליטה על סדר המידע שמגיע.

גם בצד של הסרביסים ארכיטקטורה כזאת משאירה פערים. התנהגות משותפת למספר סרביסים צריכה להיכתב בתור ספריית קוד ולהיות משולבת בכל סרביס בנפרד. בנוסף כשנסתכל על הלוגים יהיה קשה לזהות שכל הבקשות לכל הסרביסים השונים קשורות לאותו דף שלקוח ספציפי מנסה להציג.

הפיתרון לכל הבעיות נקרא API Gateway. זה לא כלי אלא תבנית פיתוח, ולמעשה יש המון כלים שיכולים לתפקד בתור API Gateway, והרבה פעמים נראה מערכות שמשלבות כמה מהם. בתבנית API Gateway אנחנו בונים שירות בכניסה למערכת שיחבר את כל הסרביסים שלנו, ובגלל זה לפעמים הוא נקרא גם Backend for Frontend.

בדוגמת החנות שלנו אפשר לדמיין API Gateway שיקבל פניה לנתיב /, יפנה לכל הסרביסים במערכת, יאסוף מהם את התשובות שלהם לפניה ויחזיר אוביקט מידע אחד שמורכב מכל התשובות של כל הסרביסים.

אבל יש עוד כמה דברים ש API Gateway יכול לעשות:

1. ה Gateway יוסיף "מזהה בקשה" לכל בקשה שנכנסת למערכת, וכל הסרביסים משתמשים במזהה זה בכתיבה ללוג. כך קל לנו להסתכל בלוג ולהבין איזה בקשות קשורות, גם בין סרביסים שונים.

2. ה Gateway יוכל לטפל ב Caching של תשובות כדי להוריד עומס מהסרביסים הפנימיים.

3. ה Gateway יוכל לטפל ב Rate Limit או לחסום בוטים.

4. אם חלק מהסרביסים למטה, ה Gateway הוא במקום טוב לזהות את זה מהר ולהעביר את העומס לסרביסים אחרים.

5. ה Gateway יוכל לתעדף משתמשים מסוימים באמצעות העברתם לסרביסים פנויים יותר.

רק בגלל שהחלטתם להשתמש ב API Gateway אל תחשבו שאתם נעולים לכלי אחד ספציפי או יחיד במערכת. אין בעיה להרים שרת NGINX או HAProxy בכניסה למערכת כדי לטפל ב Rate Limit, ומאחוריו שרת Express כדי לבצע Request Aggregation. הדבר החשוב הוא להסתכל על ה Gateway בתור סרביס שיכול להיות מורכב מכמה תחנות ואחראי על תחומי עבודה מסוימים.

שימוש ב API Gateway יכול לעזור אפילו אם רק התחלתם לעבוד בגישת Micro Services ויש לכם ממש מעט סרביסים במערכת, והוא ממש הכרחי ככל שמספר הסרביסים עולה ואיתו העומס על המערכת והצורך בתיאום.