Middleware הוא מונח נפוץ בפיתוח אתרים. זה יכול להיות הרבה דברים בהתאם להקשר, מה שהופך את המונח למבלבל מעט.
במאמר זה נתחיל בהגדרת המונח ונמשיך בדיון על כמה מקרי שימוש שונים.
לאחר קריאת מאמר זה תוכל להיות מעורב יותר בשיחות טכניות ואדריכליות עם עמיתייך. תוכלו להיות מסוגלים יותר מבחינת עיצוב ממשקי API מאובטחים ואמינים וזרמי נתונים.
הגדרת Middleware
Middleware היא תוכנה המשמשת כמתווך בין שני יישומים או שירותים בכדי להקל על תקשורתם.
אתה יכול לחשוב על זה כ- proxy שיכול לשמש כמצטבר נתונים, כמתרגם או סתם כ- proxy שמעביר בקשות.
מקרים לשימוש נפוץ עבור Middleware
1) מתרגם
ישנם פורמטים רבים של החלפת נתונים, כגון JSON, XML ו- Protobuf. למרות שאנו משתמשים כיום ב- JSON, לכל אחד מהם יש מקרי שימוש משלו.
לדוגמא, ידוע כי פרוטובופרס מציגים ביצועים יותר מ- JSON אך הם אינם ניתנים לקריאה אנושית. אז אולי אתה משתמש ב- Protobuffers לשירותים פנימיים ואתה יכול להשתמש ב- JSON כאשר צרכן ה- API הוא דפדפן.
אתה יכול גם לבדוק את המאמר שלי על Protobuffers אם אתה מעוניין ללמוד עוד עליהם.
בואו נגיד שאנחנו זקוקים לשני השירותים הללו, המדברים על פרוטוקולים שונים, כדי לתקשר זה עם זה.
אנו יכולים ליצור תוכנת ביניים העושה שימוש בספריית המרת נתונים ומתרגמת את הבקשות לפורמט שהשירות המקבל יכול להבין.
2) צבירת-שכפול נתונים
אדריכלות מיקרו-שירות היא תבנית אדריכלית פופולרית המופעלת בדרך כלל ביישומים מודרניים.
אם אינך מכיר את ארכיטקטורת המיקרו-שירותים, זה בעצם אומר שהיישום שלך מורכב מאפליקציות או שירותים קטנים רבים שאינם תלויים זה בזה ופועלים יחד על ידי תקשורת דרך האינטרנט.
לדוגמא, בפרויקט מסחר אלקטרוני, ייתכן שיהיה לך מיקרו-שירות לאחסון מוצרים ואחזורם, מיקרו-שירות אחר לחיפוש ועוד אחד לאימות ואחסון משתמשים. ולכל אחד מאגר משלו.
בואו נגיד שאנחנו רוצים ליישם את החיפוש שלנו בצורה שהוא יחפש משתמשים ומוצרים כאחד.
אם זו הייתה יישום מונוליטי נוכל פשוט לכתוב שאילתה כדי לחפש בכל טבלה ולהצטרף לתוצאות. אך כעת מאגרי המידע שלנו פועלים בשרתים שונים.
לבעיה זו יש פתרונות מרובים, ונבחן שניים מהם.
צבירת נתונים
אנו יכולים להשתמש בתוכנת תיווך כדי לשלוח בקשות לשני השרתים, ולבקש מהם לחפש במסדי הנתונים שלהם שמות משתמש ומוצרים התואמים למילה שחיפשה.
אז נוכל לצבור את התוצאות משני השרתים ולהחזיר אותם ללקוח. שים לב שמספר הבקשות גדל באופן ליניארי ככל שאנחנו מגדילים את מספר השרתים (ואנחנו צריכים גם למזג את הנתונים האלה).
שכפול נתונים
אנו יכולים לאחסן נתונים כפולים בשרת החיפוש שלנו, כך שהוא יכול לחפש אותם ישירות במקום לבקש משרתי מוצרים ומשתמשים. זה פחות יעיל מבחינת זיכרון אבל הרבה יותר מהיר - ומהירות היא קריטית עבור שירותי החיפוש.
אם הטבלאות שאנו זקוקים להן הן מוצר ומשתמש, אנו יכולים ליצור טבלאות אלה גם בשרת החיפוש שלנו. ואז, בכל פעם שנשמור משתמש חדש במאגר המשתמשים שלנו, נשמור גם עותק אחד בשרת החיפוש.
יש לנו כמה אפשרויות: ראשית, אנו יכולים להתקשר לשיטות החיסכון של שרת החיפוש משיטות השמירה של שרתי המשתמש והמוצר בכדי לשכפל את הנתונים. לחלופין, אנו יכולים ליצור תוכנת תיווך לשמירה שתבצע את הפעולות הבאות:
- בכל פעם שמגיעה בקשת שמירה, התקשרו לשמירת מוצר / שרת משתמש ולשמור שרת חיפוש.
- אם השמירה הראשונה נכשלת, אל תתקשר לשמירה באחרת (זה שומר על עקביות מסדי הנתונים).
בואו נסתכל על דיאגרמות העיצוב בלי ועם תוכנת ביניים. ראשית, ככה זה נראה בלי:
נראה מכוער, נכון? ואכן, זה מכוער וזה יהפוך את הקוד שלך למסובך יותר ולצמוד היטב.
להלן פתרון זהה לתוכנת תיווך:
בתרחיש זה, צד הלקוח פשוט מתקשר לתוכנת הביניים כדי לשמור מוצר או משתמש והיא מטפלת בשאר.
אין קוד הקשור לשכפול הנתונים, לא בשרתי המוצר או בשרת או בצד הלקוח. Middleware דואגת לדברים האלה.
3) אבטחת API
עבור כל קוד בצד הלקוח הקדמי, אנו יכולים להציג את הבקשות היוצאות, במסוף הדפדפן או באמצעות שרת proxy.
דיברנו על שרת משתמש שמטפל בכניסה ובהרשמה. אם קוד הקצה שלנו שולח את הבקשות ישירות לאותו שרת, הכתובת של שרת האימות שלנו נחשפת. לאחר לימוד כתובת ה- IP של ה- backend שלנו, התוקפים יכולים להשתמש בכלים כדי למצוא את נקודות הקצה שלנו ולסרוק את השרת שלנו לאיתור נקודות תורפה.
אנו יכולים להשתמש בתוכנת הביניים כ- proxy כדי להסתיר את כתובת ה- URL של שרת האימות שלנו. הקצה הקדמי שלנו מתקשר עם תוכנת הביניים והוא יעביר את הבקשה לשרת האימות ויחזיר את התגובה.
גישה זו מאפשרת לנו גם לחסום את כל הבקשות לשרת האימות שלנו, למעט הבקשות מכתובת האתר של התוכנה האמצעית שלנו. זה הופך את שרת האימות שלנו להרבה יותר בטוח.
זה לא היה אפשרי בעבר, מכיוון שהקצה שלנו התקשר עם שרת האימות. מכיוון שהקצה הקדמי פירושו מחשב הלקוח, לא יכולנו להחיל מסנן IP.
4) חשיפת ממשקי API ציבוריים
בחלק הקודם למדנו שניתן להשתמש באמצעי האמצעי להגבלת הגישה ל- API שלנו.
עכשיו בואו נסתכל על הצד השני של המשוואה: מה אם נרצה לתת גישה מוגבלת ל- API שלנו? אולי אנחנו מהנדסי תוכנה בבנק והבנק מתכנן האקתון. נצטרך לספק גישה ל- API שלנו, נכון?
אך מכיוון שאנחנו בנק, כמובן שאנחנו לא יכולים לספק גישה לכל ה- API ולאפשר כל פעולה. פירוש הדבר שעלינו למצוא דרך לספק גישה מוגבלת.
למטרה זו אנו יכולים ליישם תוכנת תיווך שחושפת רק חלק מנקודות הקצה ומפנה את הבקשות לממשק ה- API האמיתי שלנו. ואז אנו מספקים את ה- API הזה למפתחים בהאקתון.
סיכום
בפוסט זה התחלנו בהגדרה מהי תוכנת תיווך וניסינו לסווג את מקרי השימוש של תוכנות ביניים בפיתוח אתרים.
זכור כי זו אינה רשימה מלאה של מקרי שימוש, אך עדיין אני מקווה שזה הועיל לך.
תודה שקראת. אם אהבתם את המאמר, אני מזמין אתכם לבדוק את הבלוג שלי. אתה יכול גם להירשם לרשימת התפוצה שלי כדי לקבל הודעה כשאפרסם פוסט חדש :)