WEBVTT

00:00:00.000 --> 00:00:07.700
מוכנים למד מינוס עשרה ימים של Microsoft 365, Copilot, בינה מלאכותית, Azure, והאנשים שמעצבים את עתיד העבודה.

00:00:07.860 --> 00:00:12.280
בינואר הקרוב, M365Con חוזר, ואנחנו הולכים בגדול.

00:00:12.460 --> 00:00:18.820
הצטרפו אלינו להרצאות בשידור חי, הדגמות מהעולם האמיתי, וידע מעשי ממומחי MVP ומובילים בתעשייה מרחבי העולם.

00:00:19.020 --> 00:00:21.700
בלי שקפים גנריים ובלי מילים ריקות מתוכן.

00:00:21.880 --> 00:00:29.240
אנחנו מתמודדים עם האתגרים האמיתיים, Copilot Studio, סוכני AI, Fabric, אבטחה, ממשל ואוטומציה.

00:00:29.240 --> 00:00:35.000
בין אם אתם, אנשי איט, מפתחים או מנהלים עסקיים, יש ששנים שתוכננו בדיוק עבורכם.

00:00:35.380 --> 00:00:40.460
במהלך עשרה ימים מלאים, תוכלו לחקור טכנולוגיות רבות ולהתחבר לקהילה גלובלית.

00:00:40.700 --> 00:00:44.800
צפו בשידור חי וקחו איתכם תובנות מעשיות חזרה לארגון שלכם.

00:00:45.100 --> 00:00:49.380
ינואר 2027, עשרה ימים, קהילת מייקרוסופט אחת.

00:00:49.540 --> 00:00:50.880
ההרשמה פתוחה כעת.

00:00:51.560 --> 00:00:56.180
היכנסו לאם 365Con.net והבטיחו את מקומכם היום.

00:00:56.180 --> 00:00:59.020
זה M365Con.net.

00:00:59.240 --> 00:01:05.100
הרשמו עכשיו ב-M365Con.net ונתראה בשידור חי בינואר.

00:01:05.260 --> 00:01:10.880
בניתם אפליקציה שעובדת, אז הוספתם עוד שירות ועוד אחד, ופתאום ניהול התעבורה ביניהם הופך לסיוט.

00:01:10.980 --> 00:01:14.480
אז מה זה בעצם API Gateway? והאם אתם באמת צריכים אחד כזה?

00:01:14.620 --> 00:01:17.720
עד סוף הפרק הזה, תבינו מה עושה API Gateway?

00:01:18.060 --> 00:01:20.520
מדוע הוא פותר את הקאוס בניהול שירותים מרובים?

00:01:20.740 --> 00:01:22.440
ואיך לדעת אם אתם צריכים אחד?

00:01:22.440 --> 00:01:27.040
נתחיל בבעיה, אחר כך בחלקים, ואז נראה איך הם משתלבים יחד.

00:01:27.560 --> 00:01:29.420
הבעיה, יותר מדי דלתות.

00:01:29.580 --> 00:01:32.160
דמיינו שאתם מנהלים חברה שצומחת מהר.

00:01:32.340 --> 00:01:36.900
יש לכם צוות מחירות בקומה השלישית, הנהלת חשבונות במרטף, ואית באגף האחורי.

00:01:37.020 --> 00:01:43.040
עכשיו, דמיינו שלכל אחת מהמחלקות האלו יש דלת כניסה משלה, מספר טלפון משלה, ומאבטח משלה שלא מדבר עם האחרים.

00:01:43.040 --> 00:01:51.120
אם אתם מבקר שמנסה להשאיר חבילה שיהיה לכם בהצלחה, אתם צריכים לדעת בדיוק באיזו דלת להשתמש, עם איזה מאבטח לדבר, ומה לעשות כשהמאבטח בהפסקה.

00:01:51.240 --> 00:01:56.500
זה בדיוק מה שקורה כשהאפליקציה שלכם כוללת שירותי צד שרת מרובים, וכל לקוח פונה לכל אחד מהם ישירות.

00:01:56.660 --> 00:02:04.460
הלקוח, בין אם זו אפליקציית מובייל, אתר או שירות אחר, צריך לדעת איפה כל שירות נמצא, איך לבצע אימות, ומה לעשות כשמשהו משתבש.

00:02:04.460 --> 00:02:09.620
כל שירות בודד צריך לטפל בעצמו בהבטחה, בהגבלת קצב, rate limiting, ובטיפול בשגיאות.

00:02:09.740 --> 00:02:12.360
זו עבודה כפולה, וקל לדברים להפוך ללא עקביים.

00:02:12.580 --> 00:02:17.200
קחו בנק, למשל, יש להם שירותים נפרדים לחשבונות, תשלומים, הלוואות וזיהוי הונאות.

00:02:17.380 --> 00:02:19.700
בשיטה הישנה, כל אחד מהם חשוף ישירות.

00:02:19.880 --> 00:02:25.600
אפליקציה לנייד צריכה להכיר ארבעה כתובות URL שונות, ארבעה שיטות אימות שונות וארבעה דרכים שונות לטיפול בשגיאות.

00:02:25.600 --> 00:02:32.560
זו רמת מורכבות פי ארבעה ופי ארבעה עזורים שבהם משהו עלול להשתבש, וזה הקאוס ששער API נועד לתקן.

00:02:32.740 --> 00:02:33.620
אז מה הפתרון?

00:02:33.940 --> 00:02:35.060
מהו שער API?

00:02:35.300 --> 00:02:38.400
דמיינו שער API כמו דלפק הקבלה של בית מלון.

00:02:38.660 --> 00:02:44.560
כשנכנסים, אין צורך לדעת באיזו קומה נמצא משק הבית, איפה המטבח או איך להגיע לצוות התחזוקה.

00:02:44.660 --> 00:02:48.560
פשוט ניגשים לדלפק הקבלה, אומרים להם מה צריכים, והם מטפלים בשער.

00:02:48.560 --> 00:02:54.340
הם מפנים את הבקשה שלך על האדם הנכון, בודקים אם מותר לך להיות שם, ואפילו מטפלים בבקשות בסיסיות בעצמם.

00:02:54.520 --> 00:02:57.220
שער API עושה את אותו הדבר עבור התוכנה שלך.

00:02:57.380 --> 00:03:01.600
זוהי נקודת כניסה אחת שיושבת בין הלקוחות שלך לבין שירותי היבק אנד שלך.

00:03:01.740 --> 00:03:03.900
כל בקשה עוברת דרך השער תחילה.

00:03:04.000 --> 00:03:07.460
הוא מחליט לאן לשלוח אותה, האם לאשר אותה ומה לשלוח בחזרה.

00:03:07.640 --> 00:03:09.300
ובכן, זה לא רעיון חדש.

00:03:09.300 --> 00:03:14.060
Reverse Proxies קיימים כבר עשורים, אך שער ה-API הפך לחיוני עם המיקרו שירותים.

00:03:14.180 --> 00:03:17.320
כשמפרקים אפליקציה להרבה שירותים קטנים, פתאום יש הרבה דלתות.

00:03:17.480 --> 00:03:19.440
השער מספק לכם דלת כניסה אחת.

00:03:19.560 --> 00:03:24.800
בעולם Azure, Azure API Management הוא הפלטפורמה המלאה, והשער הוא הרכיב המרכזי שמטפל בתעבורה.

00:03:24.960 --> 00:03:26.720
אבל, התבנית זהה בכל מקום.

00:03:26.920 --> 00:03:28.880
נקודת כניסה אחת, שליטה מרכזית.

00:03:29.040 --> 00:03:30.440
כל בקשה נכנסת פנימה.

00:03:30.440 --> 00:03:33.280
השער בודק אותה, מנתב אותה ושולח את התגובה בחזרה.

00:03:33.400 --> 00:03:36.160
הלקוח לעולם לא מדבר עם שירותי Hey! Backend שלך ישירות.

00:03:36.280 --> 00:03:37.520
הוא מדבר רק עם השער.

00:03:37.720 --> 00:03:39.400
בואו נפרק מה זה אומר בפועל.

00:03:39.540 --> 00:03:42.140
נתחיל עם התפקיד הבסיסי ביותר, ניתוב.

00:03:42.560 --> 00:03:44.280
חלק ראשון, ניתוב תעבורה.

00:03:44.480 --> 00:03:49.020
התפקיד הפשוט ביותר של שער API הוא ניתוב, הפניית כל בקשה לשירות הנכון.

00:03:49.180 --> 00:03:50.780
תחשבו איך אתר אינטרנט עובד.

00:03:50.940 --> 00:03:53.160
כשלוחצים על קישור, הדפדפן שולח בקשה.

00:03:53.300 --> 00:03:54.660
לבקשה הזו יש נתיב.

00:03:54.660 --> 00:03:57.820
אם הנתיב הוא Users, השער יודע לשלוח אותו לשירות המשתמשים.

00:03:57.920 --> 00:04:00.060
אם זה Orders, הוא הולך לשירות ההזמנות.

00:04:00.240 --> 00:04:03.580
השער קורא את הנתיב, מבין לאן הוא צריך להגיע ומעביר אותו הלאה.

00:04:03.680 --> 00:04:07.220
ללא שער, הלקוחות שלכם צריכים להכיר כל כתובת URL של כל שירות.

00:04:07.320 --> 00:04:11.960
האפליקציה לנייד צריכה את הכתובת של שירות המשתמשים, שירות ההזמנות, שירות התשלומים ושירות הקטלוג.

00:04:12.100 --> 00:04:13.840
אלו המון כתובות URL לנהל.

00:04:14.000 --> 00:04:16.880
ואם אחת מהכתובות האלה משתנה, צריך להדכן כל לקוח.

00:04:16.880 --> 00:04:19.500
עם Gateway, לקוחות מכירים רק כתובת URL אחת.

00:04:19.640 --> 00:04:23.020
הכתובת של הגאטאווי לא אכפת להם איפה השירותים באמת נמצאים.

00:04:23.160 --> 00:04:26.140
הם פשוט שולחים את הבקשה לגייטווי, והוא מטפל בכל השאר.

00:04:26.260 --> 00:04:30.020
זהו אחד ממקרי השימוש הנפוצים ביותר ב-API Gateway, ניתוב מבוסס משאבים.

00:04:30.160 --> 00:04:32.860
המחקר של Apache APIsIX מציין זאת במפורש.

00:04:33.020 --> 00:04:37.560
ניתן לנתב לפי הנתיב שיטת ה-HTTP, הכותרות, ואפילו המיקום הגיאוגרפי של הלקוח.

00:04:37.560 --> 00:04:41.160
אם מי שהוא מאירופה שולח בקשה, אפשר לנתב אותו למרכז נתונים אירופי.

00:04:41.240 --> 00:04:44.520
אם מי שהוא מארצות הברית שולח בקשה, הוא יגיע למרכז נתונים אמריקאי.

00:04:44.620 --> 00:04:46.340
הלקוח אפילו לא מודע לכך שזה קורה.

00:04:46.480 --> 00:04:47.920
הוא פשוט מקבל תגובה מהירה.

00:04:48.060 --> 00:04:49.420
ניתוב מטפל גם בגרסאות.

00:04:49.600 --> 00:04:51.940
נניח שיש לך גרסה חדשה לשירות המשתמשים שלך.

00:04:52.100 --> 00:04:55.980
לקוחות ישנים עדיין משתמשים בית V1, Users, וחדשים בית V2, Users.

00:04:56.140 --> 00:04:58.080
הגאטאווי מנתב אותם לבקאנד שונים.

00:04:58.080 --> 00:05:01.420
לקוחות ישנים ממשיכים לעבוד בזמן שאתה פורס את הגרסה החדשה.

00:05:01.560 --> 00:05:04.020
ניתן לשנות את הבקאנד מבלי לשבור את הלקוחות.

00:05:04.160 --> 00:05:07.260
זה משמעותי מאוד כשמנהלים אפליקציה חיה עם משתמשים אמיתיים.

00:05:07.420 --> 00:05:09.240
תחשבו על פלטפורמת מסחר אלקטרוני.

00:05:09.400 --> 00:05:13.360
יש לכם שירותים נפרדים לקטלוג, לעגלת הקניות, לתשלום ולחשבונות משתמשים.

00:05:13.520 --> 00:05:17.320
בלי גאטווי, אפליקציית מובייל צריכה להכיר 4 כתובות URL שונות.

00:05:17.420 --> 00:05:19.300
עם גאטווי היא מכירה רק אחת.

00:05:19.300 --> 00:05:24.880
הגאטווי קורא את הנתיב קטלוג, עגלה, תשלום, חשבון ושולח כל בקשה לשירות הנכון.

00:05:25.040 --> 00:05:26.640
ניתוב פשוט הוא החלק הקל.

00:05:26.800 --> 00:05:29.140
התפקיד הבא הוא איפה שזה הופך לשימושי באמת.

00:05:29.380 --> 00:05:31.260
חלק שני, הבטחה בדלת הכניסה.

00:05:31.380 --> 00:05:33.300
כל קריאת API צריכה להיבדק.

00:05:33.460 --> 00:05:34.820
מי מבצע את הבקשה הזו?

00:05:34.940 --> 00:05:36.600
האם יש להם את ההרשאות המתאימות?

00:05:36.780 --> 00:05:39.660
ללא גאטווי, כל שירות צריך לטפל באימות שלו בעצמו.

00:05:39.820 --> 00:05:42.100
זה אומר עבודה כפולה וקל מאוד לטעות בזה.

00:05:42.100 --> 00:05:48.080
שירות אחד עשוי לבדוק הסימונים כראוי, אחר עשוי לדלג על שלב, ואחר עשוי להשתמש בשיטה שונה לגמרי.

00:05:48.240 --> 00:05:51.080
התוצאה היא הבטחה לא עקבית בכל האפליקציה שלך.

00:05:51.260 --> 00:05:52.480
הגאטווי משנה את זה.

00:05:52.660 --> 00:05:55.200
הוא מטפל באימות והרשאות במקום מרכזי אחד.

00:05:55.400 --> 00:05:59.380
נקודה אחת לבדיקה, נקודה אחת לאכיפה, נקודה אחת להדכון שהמדיניות משתנה.

00:05:59.560 --> 00:06:01.520
זו פרקטיקה מומלצת ומעולה להבטחה.

00:06:01.520 --> 00:06:07.060
הוא מעמת מפתחות API JWT, הסימוני אור-אוף או תעודות בכל בקשה בודדת.

00:06:07.200 --> 00:06:10.400
כל בקשה עוברת את אותה הבדיקה, ללא יוצא מן הכלל.

00:06:10.580 --> 00:06:12.340
הגאטווי יכול גם לאכוף חוקים.

00:06:12.500 --> 00:06:15.860
אתה יכול לקבוע, מפתח API זה יכול לקרוא רק מנקודות הקצה של פריעה.

00:06:15.940 --> 00:06:19.320
או, לקוח זה יכול לגשת רק לשירות הקטלוג, לא לשירות התשלומים.

00:06:19.460 --> 00:06:23.100
אתה מגדיר הרשאות מדויקות ברמת הגאטווי, והן חלות באופן אוטומטי.

00:06:23.240 --> 00:06:26.040
שירותי Hey Backend לעולם לא צריכים לדאוג לגבי הרשאות.

00:06:26.040 --> 00:06:28.820
הם רק מאבדים את הבקשה ושולחים בחזרה את הנתונים.

00:06:29.020 --> 00:06:29.760
הנה העניין.

00:06:29.920 --> 00:06:33.080
הגאטווי הוא מקום מרכזי לביטול גישה כשמשהו משתבש.

00:06:33.240 --> 00:06:36.500
אם מפתח ה-API של לקוח נחשף, מבטלים אותו בגייטווי.

00:06:36.680 --> 00:06:37.920
שינוי אחד, וזהו.

00:06:38.060 --> 00:06:40.420
לא צריך לעדכן כל שירות או להפעיל מחדש דבר.

00:06:40.640 --> 00:06:43.000
הבקשה הבאה מהמפתח הזה תידחם מידית.

00:06:43.140 --> 00:06:44.320
קחו דוגמה מהמציאות.

00:06:44.460 --> 00:06:46.600
לבנק יש שירות תשלומים ושירות חיובים.

00:06:46.600 --> 00:06:49.700
רק שירות התשלומים זקוק להרשאת כתיבה למערכת החיובים.

00:06:49.700 --> 00:06:50.880
הגאטווי עוכף זאת.

00:06:51.060 --> 00:06:54.320
אם לקוח מנסה לכתוב למערכת החיובים דרך נקודת קצה שגויה,

00:06:54.540 --> 00:06:55.460
הגאטווי חושם זאת.

00:06:55.620 --> 00:06:57.560
שירות החיובים אפילו לא רואה את הבקשה.

00:06:57.720 --> 00:07:02.040
הגאטווי יכול גם לתמוך ב-Mutual TLS ובאינטגרציית WAF להגנה מעמיקה יותר.

00:07:02.240 --> 00:07:04.680
אבל בליבה שלו, הוקב ההגנה הראשון שלכם.

00:07:04.840 --> 00:07:08.640
הבטחה זה דבר אחד, אבל מה קורה כשמגיעות יותר מדי בקשות בבת אחת?

00:07:08.640 --> 00:07:10.400
חלק שלישי, ניהול תעבורה.

00:07:10.400 --> 00:07:14.080
מה קורה קש מינוס עשרת אלפים משתמשים נכנסים לאפליקציה בו זמנית?

00:07:14.240 --> 00:07:17.420
אולי יש מבצע בזק, אולי השקת מוצר הפכה לוויראלית,

00:07:17.600 --> 00:07:20.240
או סתם יום שלישי רגיל וכולם החליטו להתחבר יחד.

00:07:20.440 --> 00:07:24.920
בלי גאטווי, שירותי היי בקאנד שלכם מופגזים ישירות, והם עלולים לקרוס.

00:07:25.100 --> 00:07:26.540
לא לאט, אלא בבת אחת.

00:07:26.720 --> 00:07:28.560
כאן נכנס לתמונה ניהול התעבורה.

00:07:28.560 --> 00:07:31.740
הגאטווי יכול להגביל כמה בקשות כל לקוח יכול לבצע.

00:07:31.740 --> 00:07:34.700
הגבלת קצב, רייט לימיטינג, וביסות הם פיצ'רים סטנדרטיים.

00:07:34.860 --> 00:07:37.020
מגדירים את הכללים בגייטווי, והוא אוכף אותם.

00:07:37.200 --> 00:07:39.560
שירותי היי בקאנד שלכם לעולם לא מרגישים את האומס.

00:07:39.740 --> 00:07:42.840
ניתן להגדיר מכסות לכל משתמש, לכל מפתח API, או לכל כתובת IP.

00:07:43.020 --> 00:07:44.940
נניח שיש לכם גירסה חינמית ל-API.

00:07:45.100 --> 00:07:47.020
משתמשים חינמיים מקבלים מאה בקשות לשעה.

00:07:47.160 --> 00:07:48.940
משתמשי פרימיום מקבלים עשרת אלפים.

00:07:48.940 --> 00:07:52.100
הגאטווי עוקב אחרי כל בקשה, ואוכף את המגבלות הללו בכניסה.

00:07:52.200 --> 00:07:56.740
משתמש חינמי מגיע למכסה, והגאטווי שולח הודעת, נסה שוב מאוחר יותר, מנומסת.

00:07:56.940 --> 00:07:59.500
שירותי היי בקאנד אפילו לא יודעים שהייתה בקשה.

00:07:59.640 --> 00:08:02.280
הם ממשיכים לעבוד כרגיל ולשרת את הלקוחות המשלמים.

00:08:02.460 --> 00:08:04.440
הגאטווי מטפל גם באיזון או מסים.

00:08:04.640 --> 00:08:09.100
אם יש לכם מספר מופעים, אינסטנסז, של אותו שירות, הגאטווי מפזר את הבקשות ביניהם.

00:08:09.100 --> 00:08:13.060
מופע אחד מקבל בקשה, המופע השני את הבאה, והשלישי את הבאה אחריה.

00:08:13.260 --> 00:08:13.960
זה אוטומטי.

00:08:14.080 --> 00:08:16.520
ואם מופע אחד נופל, הגאטווי מנתב לאחר.

00:08:16.660 --> 00:08:17.900
הלקוחות לעולם לא יודעים.

00:08:18.020 --> 00:08:19.640
הם פשוט מקבלים את התגובה שלהם.

00:08:19.820 --> 00:08:22.380
איזון או מסים עם בדיקות תקינות שומר על פעילות חלקה.

00:08:22.480 --> 00:08:25.160
הגאטווי מבצע פינג לכל מופע כדי לוודא שהוא חי.

00:08:25.280 --> 00:08:27.020
אם לא, הוא מפסיק לשלוח אליו תעבורה.

00:08:27.020 --> 00:08:30.020
זה חשוב במיוחד עבור ממשקי API עם תעבורה גבוהה.

00:08:30.020 --> 00:08:33.520
ללא הגאטווי, זינוק בתעבורה פוגע בשירותים שלכם ישירות.

00:08:33.700 --> 00:08:40.200
עם הגאטווי, הזינוק פוגע קודם בגייטווי, שסופג אותו, מפיץ אותו ומגן על השירותים שלכם מקריסה.

00:08:40.360 --> 00:08:43.700
אוקיי, אבל מה קורה אם הנתונים לא נראים נכון כשהם מגיעים?

00:08:44.320 --> 00:08:46.660
חלק ארבע, טרנספורמציה של נתונים.

00:08:46.660 --> 00:08:50.460
לפעמים הנתונים שהלקוח שולח לא תואמים למה שהאקנד שלכם מצפה לו.

00:08:50.580 --> 00:08:53.760
אולי הלקוח שולח JSON, אבל הבקנד שלכם מבין רק XML.

00:08:54.080 --> 00:08:55.520
אולי שמות השדות לא תואמים.

00:08:55.520 --> 00:08:59.000
הלקוח משתמש בט, פרסט ניים, והבקנד שלכם מצפה למד פרסט ניים.

00:08:59.120 --> 00:09:00.840
חוסר ההתאמות האלה גורמים לתקלות.

00:09:01.040 --> 00:09:04.620
בדרך הישנה, הייתם צריכים לתקן כל לקוח בנפרד או לשכתב את הבקנד.

00:09:04.660 --> 00:09:05.100
לא להיט.

00:09:05.260 --> 00:09:08.260
הגאטווי יכול לשנות את הנתונים לפני שהם מגיעים לבקנד.

00:09:08.360 --> 00:09:09.600
תחשבו עליו כי מתרגם.

00:09:09.600 --> 00:09:13.100
הוא יושב באמצע ויכול לשנות את הנתונים בדרך פנימה, בדרך החוצה או בשניהם.

00:09:13.220 --> 00:09:15.720
זה הרעיון של טרנספורמציאת בקשות ותגובות על קצה המזלג.

00:09:15.720 --> 00:09:17.140
בואו אתן לכם דוגמה מהחיים.

00:09:17.320 --> 00:09:19.640
נניח שיש לכם מערכת ישנה שמצפה לאקס אמל.

00:09:19.780 --> 00:09:21.140
היא רצה כבר 15 שנה.

00:09:21.260 --> 00:09:22.120
היא עובדת מצוין.

00:09:22.300 --> 00:09:25.340
אבל עכשיו אתם בונים אפליקציה חדשה, ואפליקציות מובייל מדברות ג'ייסון.

00:09:25.500 --> 00:09:29.460
ללא גייטווי, הייתם צריכים לשכתב את המערכת הישנה או להכריח את האפליקציה לשלוח אקס אמל.

00:09:29.460 --> 00:09:31.520
עם גייטווי, אתם לא צריכים לעשות אף אחד מהם.

00:09:31.620 --> 00:09:33.200
אפליקציית המובייל שולחת ג'ייסון.

00:09:33.340 --> 00:09:34.820
הגאטווי ממיר אותו לאקס אמל.

00:09:34.960 --> 00:09:36.640
המערכת מקבלת את מה שהיא מצפה לו.

00:09:36.760 --> 00:09:38.840
אפליקציית המובייל מקבלת תשובה בחזרה בג'ייסון.

00:09:38.980 --> 00:09:40.600
אף אחד לא היה צריך לשכתב שום דבר.

00:09:40.800 --> 00:09:41.760
זה היופי שבדבר.

00:09:41.940 --> 00:09:45.940
הגאטווי יכול גם להוסיף או להסיר כותרות, לשנות כתובות URL או להסתיר נתונים רגישים.

00:09:46.080 --> 00:09:48.440
תארו לעצמכם שתגובה מכילה מספר כרטיס אשראי.

00:09:48.440 --> 00:09:50.280
אתם לא רוצים שזה יחזור ללקוח.

00:09:50.460 --> 00:09:54.100
הגאטווי יכול להסיר את זה לפני שהתגובה יוצאת או להחליף בגרסה מוסתרת.

00:09:54.100 --> 00:09:55.900
הבקאנד לא צריך להשתנות בכלל.

00:09:56.080 --> 00:09:57.160
הגאטווי מטפל בזה.

00:09:57.340 --> 00:09:59.700
זה שימושי במיוחד כשאתם עושים מודרניזציה למערכות ישנות.

00:09:59.840 --> 00:10:01.360
אתם לא צריכים לשכתב את הבקאנד.

00:10:01.520 --> 00:10:03.280
אתם לא צריכים להכריח לקוחות להשתנות.

00:10:03.460 --> 00:10:05.000
אתם פשוט משנים את הגאטווי.

00:10:05.180 --> 00:10:06.760
זה כמו מתרגם בכנס בינלאומי.

00:10:06.760 --> 00:10:10.140
כולם מדברים בשפה שלהם, אבל המתרגם מוודא שכולם מבינים.

00:10:10.300 --> 00:10:12.620
הגאטווי הוא המתרגם הזה עבור התוכנה שלכם.

00:10:12.760 --> 00:10:15.720
אז, ניתוב, הבטחה, הגבלת תעבורה, פרנספורמציה, זה הרבה.

00:10:15.840 --> 00:10:17.400
אבל אלו לא ארבעה דברים נפרדים.

00:10:17.620 --> 00:10:19.020
בואו אראה לכם איך הם מתחברים.

00:10:19.240 --> 00:10:20.140
איך הכל מתחבר.

00:10:20.340 --> 00:10:21.080
הנה העניין.

00:10:21.280 --> 00:10:23.020
ארבע המשימות האלה לא נפרדות.

00:10:23.200 --> 00:10:26.100
הן עובדות יחד על כל בקשה ובקשה בכל פעם שהיא מגיעה.

00:10:26.100 --> 00:10:28.100
הגאטווי בודק את האימות, אוטנטיקיישון.

00:10:28.240 --> 00:10:29.940
הוא מבדע את מגבלת הקצב, רייט לימיט.

00:10:30.060 --> 00:10:31.160
הוא מנתב לשירות הנכון.

00:10:31.300 --> 00:10:32.880
הוא משנה את הנתונים במידת הצורך.

00:10:32.880 --> 00:10:34.200
הוא מקבל את התגובה בחזרה.

00:10:34.340 --> 00:10:35.980
הוא משנה גם אותה, אם יש צורך בכך.

00:10:36.080 --> 00:10:37.900
לאחר מכן, הוא שולח הכל בחזרה ללקוח.

00:10:38.040 --> 00:10:38.980
צינור עיבוד אחד.

00:10:39.140 --> 00:10:42.600
כל שלב קורה אוטומטית, לפי הסדר, בלי שאף שירות יצטרך לחשוב על זה.

00:10:42.760 --> 00:10:44.820
הכוח האמיתי אינו תמון בתכונה בודדת.

00:10:44.980 --> 00:10:46.100
הוא תמון באינטגרציה.

00:10:46.100 --> 00:10:49.320
אפשר להוסיף מדיניות הבטחה חדשה בלי לגעת בניתוב.

00:10:49.500 --> 00:10:51.640
את שירות הבקנד בלי לשנות את הלקוח.

00:10:51.820 --> 00:10:54.840
אפשר להדכן את הגבלות הקצב בלי לפרוס שום דבר מחדש.

00:10:54.840 --> 00:10:57.940
כל חלק הוא עצמאי, אך כולם עובדים באותו צינור עיבוד.

00:10:58.080 --> 00:11:01.920
ומכיוון שהכל עובר דרך מקום אחד, מקבלים נראות מלאה למה שקורה.

00:11:02.080 --> 00:11:04.920
לוגים, מדדים, ניתוחים, הכל מנקודה אחת.

00:11:05.120 --> 00:11:08.120
אפשר לראות כמה בקשות התקבלו, אילו נכשלו, אילו היו איטיות,

00:11:08.120 --> 00:11:10.060
ואילו לקוחות צורכים הכי הרבה משאבים.

00:11:10.200 --> 00:11:13.520
בלי גייטווי, היית צריך לאסוף את הנתונים האלה מכל שירות בנפרד.

00:11:13.660 --> 00:11:15.360
עם גייטווי, הכל נמצא ממש שם.

00:11:15.560 --> 00:11:16.540
זו התובנה הגדולה.

00:11:16.540 --> 00:11:20.640
הגאטווי הוא לא רק נתב, הוא מרכז בקרה לכל פלטפורמת ה-API שלך.

00:11:20.800 --> 00:11:24.120
כל בקשה, כל תגובה, כל שגיאה, הכל זורם דרך מקום אחד.

00:11:24.280 --> 00:11:26.400
יש לך נקודת מבט אחת לכל מה שקורה.

00:11:26.540 --> 00:11:27.900
אז איך בעצם משתמשים בזה?

00:11:28.120 --> 00:11:29.920
בואו נדבר על מה אפשר לעשות עכשיו.

00:11:29.920 --> 00:11:30.960
טיפים מעשיים

00:11:30.960 --> 00:11:32.000
בואו נהיה כנים.

00:11:32.180 --> 00:11:35.740
אם יש לך השירות אחד או שניים, כנראה שעדיין אין לך צורך ב-API Gateway.

00:11:35.940 --> 00:11:38.760
אפשר לטפל בניתוב בעצמך ולנהל הרשאות בכל שירות.

00:11:38.940 --> 00:11:40.480
זה לא אלגנטי, אבל זה עובד.

00:11:40.480 --> 00:11:45.340
אבל ברגע שמגיעים לשלושה שירותים או חושפים APIs ללקוחות חיצוניים, המורכבות מצטברת מהר.

00:11:45.500 --> 00:11:47.400
הגאטווי מחזיר את ההשקעה בו מהר מאוד.

00:11:47.540 --> 00:11:49.020
אז מה הצעד הראשון הכי טוב שלך?

00:11:49.200 --> 00:11:50.640
ריכוז עימות נתונים בגייטווי.

00:11:50.780 --> 00:11:52.120
עשה זאת לפני כל דבר אחר.

00:11:52.120 --> 00:11:54.800
אחר שירות אחד, העבר את בדיקת ההרשאות שלו לגייטווי.

00:11:54.920 --> 00:11:57.460
תשים לב מיד שקוד השירות שלך נהיה נקי יותר.

00:11:57.660 --> 00:12:00.380
אין יותר לוגיקת עימות הסימונים מפוזרת בכל מקום.

00:12:00.380 --> 00:12:03.520
אין יותר תהיות אם התמטה את זה באותו אופן בכל שירות.

00:12:03.700 --> 00:12:06.660
הגאטווי מטפל בזה פעם אחת וכל שירות נהנה מזה.

00:12:06.860 --> 00:12:08.560
הצעד הבא, הגבלת קצב.

00:12:08.720 --> 00:12:11.540
אפילו הגבלה פשוטה מגנה על הבקנד שלך מאומס יתר.

00:12:11.540 --> 00:12:14.460
התחל עם משהו בסיסי כמו מאה בקשות לדקה לכל לקוח.

00:12:14.640 --> 00:12:16.800
זה מונע מלקוח סורר להפיל את השירותים שלך.

00:12:16.920 --> 00:12:17.600
אפשר לדבר.