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

ואחד מן הימים עשיתי וובינר שהסביר את התמונה הזו, והתגובות היו חמות, רותחות, ומהות הקורס הוא להסביר את כל זה

עכשיו יש פה מלא דברים, וכרגע נתמקד בדברים שקשורים לבק, והם, בסדר הזה:

פרונט ---> בק ---> DB

אבל למעשה בק זה תהליך שנראה ככה:

פילטרים ---> אימות זהות ---> API ---> אימות הרשאות ---> פעולות לוגיות ---> API חיצוניים ---> פעולות DB.

ובנפרד ועבור כולם - לוגים.

הבה נתאר כל אחד מהם, זה ה"מינימלי" בד"כ, כי יכול להיות יותר, אבל ע"פ רוב זה הבסיס וזה התהליך

פילטרים - Security Filters

אני אשתדל להדגים את זה, אבל אנחנו תמיד צריכים להניח ששולחים לנו קוד זדוני ל API שלנו, ואנחנו צריכים שכבת הגנה כנגד זה. לפעמים שמים את זה ממש בקוד, לפעמים שמים את זה כשכבה בפעולות הDB, ולפעמים לוקחים תוכנה חיצונית עבור זה, בעולם האינטרט זה נקרא WAF (Web Application Firewall).

עבור הדוגמא שלנו אנחנו נגיד לAI שלנו לבנות לנו מראש שכבה כלשהי שתחפש ברמה בסיסית קוד זדוני, ככה לצאת ידי חובה. ביום שיהיה לנו משהו רציני אנחנו מחוייבים ע"פ חוק להביא יועץ אבטחת מידע אמיתי (כי יש מלא חרטטנים) שיבדוק, ימליץ, ויעזור ליישם אבטחה אמיתית.

אימות זהות - Authentication

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

כי כתוב ראובן? אולי אריאל שלח בשם ראובן? תחשבו שאני מתקשר לפיצרייה, מזמין 10 פיצות לכתובת של ראובן, נותן פרטים מלאים, אבל אומר שאשלם מזומן לשלוח. פתאום דופקים לראובן בבית עם 10 פיצות!! ככה זה בדיוק בעולם התוכנה.

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

API - Application Programming Interface

לפעמים נקרא controllers

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

ככה הAPI הוא בעצם רשימת הפעולות שאני מציע לצרכן שלי לעשות, אם הוא רוצה. וכמובן שאני יכול לעשות מלא מלא תנאים לכל פעולה, לדוגמא 2 תנאים מקדימים זה הפילטרים ואימות הזהות, ותנאי המשך קבוע הוא...

אימות הרשאות - authorization

נניח שיש API שמאפשר מחיקה של שורה בDB. ונניח שראובן הוכיח שהוא ראובן ושלח לAPI כל מה שנדרש. אבל השורה הזו שייכת לשמעון. אז ראובן לא יכול לגעת בשורות של שמעון. זה הרגע שאני אדחה את הבקשה עם שגיאת הרשאה.

ייתכן שראובן לא יכול למחוק בכלל פריטים. רק מנהלים יכולים.

כל פעולה ופעולה צריכה שיהיה לה "רמת הרשאה", נמוך, בינוני, גבוה, בד"כ מתואר כ"אנונימי" (ללא אימות זהות), נמוך/בסיסי/לוגין (יוזר מזוהה פשוט), בינוני/חבר/משתתף/עורך (יוזר שהוא כבר "בפנים" אבל לא מנהל), וגבוה/מנהל (יכול לעשות הכל). 

כל אחד מההרשאות האלו יכול להתפצל להמון תתי הרשאות ותתי תפקידים וקבוצות, ועוד ועוד וזה בקלות יכול להסתבך, אבל בד"כ אנחנו באפליקציות שטוחות/פשוטות נעשה את הרמות הבאות:

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

פעולות לוגיות - business logic layer

נניח שהמשתמש רוצה לפתוח קריאת שירות לתמיכה טכנית.

מה שהיוזר עושה זה רק למלא טופס ולשלוח, וה-API אמור לגלגל את זה האלה לשכבת הפעולות הלוגיות.

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

API חיצוניים

הרבה פעמים נשתמש בתוכנות צד ג' , נניח לשליחת מייל נשתמש בגימייל או ספק מיילים אחר, עבור הטיקט ששלח לנו היוזר נשתמש באיזה CRM (תוכנה לניהול קשרי לקוחות), אז צריך להפעיל את התוכנות הללו. התוכנות הללו בעצמן מספקות לנו API עבורן, ובד"כ השימוש בהן יעשה עם איזה יוזר וססמא מיוחדים, ותחת תנאים מיוחדים, אולי שלהם, אולי שלנו.

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

פעולות DB - נקרא DAL היינו Data Access Layer

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

לוגים - logs / logger

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

בד"כ עושים כמה רמות של לוגים:

• DEBUG - אם אתה נושם תרשום את זה
• LOG - אם אתה זז תרשום את זה
• INFO - אם עשית משהו מעניין תרשום את זה
• WARN - אם יש בעיה אבל היא לא עצרה אותך - תרשום את זה
• ERROR - אם נתקלת בבעיה - תרשום את זה
• FATAL - אם נפטרת - תוציא תעודת פטירה (גיחי חח)

בדכ נשתמש בתוכנות מוכנות מראש ללוגים, כי יש כאלו לרוב ותיקות ומוצלחות, נרשום את הלוגים שלנו מלא מלא מלא כל הזמן לאיזה קובץ

כל עוד אין בעיה נגדיר שהרמה הנמוכה ביותר לרישום היא WARN, וכשיש בעיה או סוגייה נוריד לLOG או אפילו DEBUG.

יש לזכור להגיד לAI להשתמש בתבנית שנקראת try catch בכל מקום, שזה אומר שאם יש שגיאה במקום לקרוס - לרשום את השגיאה ולעצור את התהליך בליטוף במקום בבעיטה (ולפעמים נבקש במקום בעיטה לשדרג לג'ק של האוטו)