ToCode

# מסתדר - "איך אתה ב git?" - "מסתדר. יודע ליצור ענפים, לעשות קומיטים, למזג. מה שצריך אני עושה ומקסימום כשאני נתקע אני תמיד מוצא ב Stack Overflow את הדרך" - "איך אתה ב Java?" - "ב Java אני די טוב. כתבתי יישומי צד-שרת גדולים וגם תיקנתי בעיות ביצועים ונעילות ב DB. אני יודע לכתוב Design Patterns ומבין טוב ארכיטקטורה. אין לי בעיה להיכנס לכל מערכת ולכתוב איזה פיצ'ר שצריך". רוב האנשים שמגייסים עובדים מחפשים עובד שיודע מספיק טוב את הטכנולוגיה שבה משתמשים אצלכם בחברה. ככה גם נראות מודעות דרושים ויש בזה משהו הגיוני. אם העבודה תהיה לכתוב יישום React, אתה רוצה בן אדם שיודע לבחור את הקומפוננטות כמו שצריך ולא יעשה לך בלאגן בקוד. הבעיה בשיטת החיפוש הזאת היא שיש די הרבה אנשים שיודעים "להסתדר" בטכנולוגיה, וכך אנחנו נתקעים עם אינסוף קורות חיים בלי שום יכולת לסנן את האנשים הנכונים או לתת פידבק לאנשים שחושבים שהם מספיק טובים אבל צריכים עוד אימון. אבל אפשר לחשוב על כיוון אחר לגיוס, שהתשובה אליו היא לא על סקלאה: - "ובאיזה שפת תכנות את ממש מצטיינת?" - "מה את יודעת על שפת התכנות הזאת שרק מעטים יודעים?" - "איזה דבר גילית על שפת התכנות הזאת שממש הפתיע אותך?" - "איזה הרצאה הכי אהבת מהכנס המקצועי האחרון שהיה על טכנולוגיה זו? ולמה?" - "איך היית ממליצה למישהו חדש ללמוד את הטכנולוגיה הזו מאפס?" - "איזה טעויות כולם עושים בתחילת הדרך בטכנולוגיה זו, שאת כבר לא עושה?" - "ומה עשית כדי להכיר כל כך טוב את הטכנולוגיה הזו?" תשובות של מועמד ל-7 השאלות האלה כמעט תמיד יספיקו בשביל להבין מי עומד מולכם, ויתנו כלים הרבה יותר טובים להחלטה על הגיוס הבא.

# למה צריך שורת פקודה כשיש GUI? (טיפ AWS) הבחירה לעבוד משורת הפקודה לא תמיד מתקבלת בהבנה אצל אנשים, לפחות עד שאותם אנשים נתקעים בקיר. לאחרונה גיליתי כזה קיר כשניסיתי למחוק טבלאות מ DynamoDB על AWS. ה GUI למחיקת טבלה כולל את רשימת כל הטבלאות וכפתורי רדיו כדי לבחור איזו טבלה תרצה למחוק. אחרי הבחירה מופיע דיאלוג בו צריך לכתוב את המילה delete כדי שהטבלה תימחק. ואם יש לך 50 טבלאות שאתה רוצה למחוק? נו, גם זה סוג של ריפוי בעיסוק. לפחות עד שנזכרתי שאפשר לגשת לממשק גם דרך כלי שורת הפקודה. הפקודה:

$ aws dynamodb list-tables

מדפיסה JSON עם רשימת כל הטבלאות:

{
    "TableNames": [
        "Table1",
        "Table2",
        "Table3"
    ]
}

נשלח אותו ל jq כדי לקבל רק את השמות:

 AWS_PAGER="" aws dynamodb list-tables | jq '.TableNames[]'
"Table1"
"Table2"
"Table3"

ונמשיך עם xargs בשביל למחוק אחת אחת:

$ AWS_PAGER="" aws dynamodb list-tables | jq '.TableNames[]'| xargs -n 1 aws dynamodb delete-table --table-name

האם היה נחמד לקבל ממשק GUI יותר נוח מאמזון? ברור. ועדיין עדיף ללמוד לעבוד עם ה CLI מאשר לבזבז שעה על מחיקת אוביקטים וניווט ב GUI.

# אונליין ואופליין עכשיו שהקורונה נגמרה מסתבר שאין שום קונפליקט בין אירועי אונליין לאופליין - לשניהם יש מקום. אונליין מאפשר לנו להיחשף לאנשים ושיטות עבודה שהיו בעבר חסומים בפנינו או שאנחנו לא אפשרנו לעצמנו ליהנות מהם. יש היום ביוטיוב יותר הרצאות מקצועיות טובות ממה שבן אדם מסוגל לראות גם אם תשב על זה מסביב לשעון. אונליין מאפשר לנו לעבוד יחד בצורה הרבה יותר יעילה מאשר פנים אל פנים. בפגישת עבודה בזום אני מספיק יותר. בקורס אונליין תלמידים יכולים להתקדם מאוד מהר (כי כל התוכן כבר מוקלט) ולשאול שאלות כשנתקעים, או לעבוד יחד על משימה בזום בצורה הרבה יותר יעילה ממה שעשינו בכיתה. היכולת להתחלק לקבוצות קטנות, לחלק את הקבוצות לחדרים ולשתף תוצרים בזמן אמת דרך כלים שאנחנו כבר רגילים לעבוד איתם פותחת דלת שעד עכשיו היתה סגורה. והאופליין? כמות המיטאפים שמתוכננים החודש עם הכותרת "מפגש פרונטאלי ראשון אחרי הקורונה" וכמות האנשים שבאים אליהם מזכירה לנו שהרבה יותר קל לנו ליצור קשרים עם אנשים כשאנחנו איתם באותו מרחב פיזי, ושאנשים רבים התגעגעו לחוויה הזאת ומחפשים אותה. אם גם לכם זה היה חסר שווה להעיף מבט בלינק https://www.meetup.com/cities/il/tel_aviv-yafo/events/ ולראות אם יש אירוע שמעניין אתכם ומסתדר בשעות.

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

function MyProjects () {
  const { data: user } = useSWR('/api/user')
  if (!user) {
    return 'loading...';
  }
  
  const { data: projects } = useSWR('/api/projects?uid=' + user.id)
  if (!projects) return 'loading...'

  return 'You have ' + projects.length + ' projects'
}

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

function MyUser() {
  const { data: user } = useSWR('/api/user')

  if (!user) {
    return 'loading...';
  }
    
  return (
    <MyProjects user={user} />
  );
}

function MyProjects () {
  const { user } = props;
  const { data: projects } = useSWR('/api/projects?uid=' + user.id)

  if (!projects) return 'loading...'

  return 'You have ' + projects.length + ' projects'
}

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

function MyProjects () {
  const { data: user } = useSWR('/api/user')
  const { data: projects } = useSWR(() => '/api/projects?uid=' + user.id)
  // When passing a function, SWR will use the return
  // value as `key`. If the function throws or returns
  // falsy, SWR will know that some dependencies are not
  // ready. In this case `user.id` throws when `user`
  // isn't loaded.

  if (!projects) return 'loading...'
  return 'You have ' + projects.length + ' projects'
}

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

  if (typeof key === 'function') {
    try {
      key = key()
    } catch (err) {
      // dependencies not ready
      key = ''
    }
  }

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

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

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

# ספריית msw היא כל מה שהיה אפשר לרצות מספריית Mock ב JavaScript ואז עוד קצת לאחרונה גיליתי את ספריית msw שהפכה תוך רגע לספריית ה Mock האהובה עליי, ואני בכלל לא אוהב להשתמש ב Mock. אני רוצה לשתף כאן דוגמה קצרה לספריה ודרך זה לראות מה כל כך מלהיב בה. ## קודם כל קוד לפני msw כשהיינו צריכים לבדוק קומפוננטה שפונה לשרת היו לנו 4 אפשרויות: 1. היינו יכולים לשנות את קוד הקומפוננטה (כן ב JavaScript אפשר לעשות הרבה מהדברים האלה מבחוץ ומתוך קוד הבדיקה) כדי שלא באמת תפנה לשרת אלא תשתמש במידע פיקטיבי שכאילו התקבל מהשרת. 2. היינו יכולים להקים שרת ספציפי לבדיקות שתמיד מחזיר מידע פיקטיבי 3. היינו יכולים להשתמש בשרת האמיתי ולהקים סביבת בדיקות שבדיקות אוטומטיות יעבדו מולה. 4. היינו יכולים לוותר על בדיקת התקשורת ולבדוק רק את החלקים שמציגים מידע. שיטה (1) מסורבלת במקרה הטוב ולא ישימה במקרה הגרוע. שיטה (2) קשה לתחזוקה ותפעול, שיטה (3) נפלאה לסביבת אינטגרציה אבל לא ממש מתאימה ל TDD כי לא תמיד אפשר לגרום לשרת האמיתי להחזיר בדיוק את המידע שאתה צריך ושיטה (4) מרגישה כמו החמצה. ספריית msw מציעה גישה פשוטה יותר בה קוד Low Level בסביבת הריצה דורס את פונקציות התקשורת ומחזיר תשובות פיקטיביות:

import { rest } from 'msw'
import { setupServer } from 'msw/node'

const server = setupServer(

  // Describe the requests to mock.
  rest.get('/book/:bookId', (req, res, ctx) => {
    return res(
      ctx.json({
        title: 'Lord of the Rings',
        author: 'J. R. R. Tolkien',
      }),
    )
  }),
)

beforeAll(() => {server.listen()})

afterAll(() => {server.close()})

test('renders a book data', () => {

  // Render components, perform requests, API communication is covered.

})

הקוד נועד לשמש בתוך קוד בדיקות והשורות המלהיבות הן כל מה שקורה בתוך הפונקציה setupServer. אנחנו פשוט מגדירים נתיבים במבנה של Express ואיזה מידע להחזיר בכל נתיב. באופן אוטומטי כשקומפוננטה מרונדרת בתוך קוד הבדיקה (בחלק של ה test) מנסה לפנות לשרת, הפניה נתפסת ב Service Worker והתשובה הפיקטיבית חוזרת. ## למה זה מלהיב היתרונות המרכזיים בגישה של msw הם: 1. אפשר להשתמש בכל קוד צד לקוח קיים בשביל לבנות את התשובות הפיקטיביות. 2. התחזוקה מאוד פשוטה כי כל הגדרות ה Mock Data נכתבות בקובץ הבדיקות יחד עם קוד הבדיקה, ואין בעיה לשלב מספר "שרתים" פיקטיביים בתוכנית בדיקות, אחד לכל קובץ בדיקות. 3. אין תקשורת אמיתית ברשת. אין בעיה של Firewalls ולא צריך לפתוח פורטים. 4. לא צריך לשנות כלום בקוד הקומפוננטה. מבחינת קוד צד-לקוח לא משנה איך הקוד פונה לשרת msw תתפוס את הבקשה ותגיב עם התשובה הפיקטיבית. 5. מבנה הנתיבים עם הנקודותיים והפרמטרים מתאים למה שאנחנו מכירים מ Express. 6. יש תמיכה מלאה ב REST וב GraphQL 7. הכל רץ ב Node.JS באמצעות ספריה בשם node-request-interceptor או בדפדפן באמצעות Service Worker. בריצה בדפדפן צריך להפעיל פונקציית איתחול אחרת שנקראת setupWorker. הספריה מאוד פשוטה לשימוש וכבר חסכה לי הרבה קוד Mock בכמה מקומות. שווה לבדוק פרטים ולראות אם היא תעזור גם לכם בדף הבית בקישור: https://mswjs.io/.

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

# איך להתחיל לשבור מונוליט למיקרו סרביסים ארכיטקטורת Micro Services יכולה לעזור בפיתוח מהיר יותר, בשילוב טכנולוגיות חדשות ואפילו בארגון טוב יותר של הקוד. אבל, לבנות ארכיטקטורת Micro Services מלאה למערכת לוקח זמן ופיתוח תשתיות. לא תמיד אנחנו פנויים ללכת בכל הכח על פיתוח כזה ולשבור את כל המערכת הקיימת. אם אתם מעדיפים לעבור לפתח Micro Services בצעדים קטנים, הנה כמה הצעות לסרביסים שתוכלו להתחיל לפתח כבר היום בלי לשבור קוד קיים: ## הקימו סרביס שמבצע פעולה מסוימת בצורה עצמאית ללא בסיס נתונים אתר טוקוד כתוב כולו ב Rails אבל כשהייתי צריך בוט טלגרם שיפרסם את הפוסטים החלטתי לנסות להקים Micro Service באליקסיר שיטפל רק בזה. הקוד לבוט נמצא כאן: https://github.com/ynonp/tocode_bot. מה שכיף בסרביס כזה זה שהוא עצמאי לגמרי. אנחנו יכולים להקים סרביס שיקבל פקודות דרך Message Queue או שיבצע משימה בצורה מחזורית. הדבר החשוב הוא לטפל במשימות שלא צריכות בסיס נתונים וככה החיים של כולם נשארים פשוטים. דוגמאות נוספות לסרביסים כאלה יהיו סרביס שרושם משתמשים לרשימת דיוור, סרביס שמנפיק חשבוניות, סרביס ל Chat Bot לאתר או כל דבר קטן כזה שלא צריך מידע. ## הקימו סרביס שמבצע משימה מחזורית ורושם את התוצאה לבסיס נתונים שלו אחרי שהתנסיתם בסרביס שלא צריך מידע שווה להמשיך לסרביס שדווקא כן. שמירת מידע פנימי בסרביס וחשיפתו החוצה באמצעות API זו התנסות טובה בתקשורת בין מספר סרביסים. שימוש בסרביס חיצוני ובבסיס נתונים חיצוני עוזר לנו לבנות Deployments בלתי תלויים בין הסרביס לשאר המערכת. העובדה שבתוך הסרביס יישמר מעט מידע אומרת שיהיה לכם קל לעבוד על המידע הזה ולהפעיל עליו מיגרציות וחישובים, בלי קשר למידע הגלובאלי של כלל המערכת. ניסוי טוב עכשיו יהיה לחבר מערכת אנאליטיקות ל DB של הסרביס הקטן ולראות איך זה עובד לכם. ## הקימו API Gateway אחרי שהצלחתם להוציא חלק מהפונקציונאליות לסרביסים שלא שומרים מידע והתנסיתם בבניית סרביסים שכן שומרים אפשר להמשיך לאתגר הבא שהוא החיבור בין הסרביסים. התקנת API Gateway תתן לכם מקום מרכזי בו תוכלו לערוך את בקשות הרשת הנכנסות וליצור קשר בין כל הסרביסים שמטפלים באותה בקשה. באמצעות API Gateway נוכל להוסיף למשל שדה Request ID לכותרות ה HTTP של הבקשה ולהעביר אותו גם בבקשות העוקבות בין Services, כך שבלוג כל ההודעות שקשורות לטיפול בהודעה מסוימת יישמרו יחד. בונוס נוסף של API Gateway הוא טיפול מרכזי באותנטיקציה. שרת ה API Gateway יוכל לזהות כל משתמש נכנס ולהוסיף עוד כותרת ל HTTP עם פרטי המשתמש. פרטים אלה יעברו לכל הסרביסים שימשיכו לטפל בבקשה וכך יהיה קל לבנות סרביסים שדורשים הזדהות. ## הקימו מערכת לאיסוף וניהול לוגים השלב הבא הוא הקמת מערכת מרכזית לניהול לוגים. פיתרון קוד פתוח פופולרי נקרא Elastic Stack, ואפשר גם להשתמש בפיתרונות ענן כמו Cloudwatch של AWS. מה שחשוב הוא שיהיה לנו מקום אחד בו אפשר לראות את הלוגים מכל הסרביסים שכבר יצרנו, ושיהיה קל לחבר בין לוגים של סרביסים שונים. ## הקימו סרביס שמנהל הזדהות הצעד הבא והאחרון מבחינת התשתית הוא הקמת סרביס הזדהות. זה בעצם הקו המפריד בין מערכת מונוליט עם קצת סרביסים למערכת Micro Services עם מונוליט קטן. סרביס ייעודי להזדהות שמחובר ל API Gateway אומרת שהסרביסים השונים לא צריכים להתעסק בניהול משתמשים וכל התקשורת בנושא המשתמשים עוברת דרך JWT שהקלאיינט מחזיק אצלו. ברגע שבניתם את זה ניטרלתם את צוואר הבקבוק המרכזי במערכת ומפה אפשר להמשיך לשבור את הקוד לעוד ועוד סרביסים קטנים. שירות הזדהות פופולרי הוא auth0 והוא יודע להתחבר לבסיס נתונים שלכם שכבר מחזיק את הנתונים או אם לא מפריע לכם להוציא את פרטי המשתמשים החוצה אפשר גם לייבא את כל טבלת המשתמשים שלכם פנימה לשם. שירות נוסף ששווה לבדוק הוא AWS Cogito שיתאים יותר אם אתם כבר בענן של AWS. ## המשיכו בקצב שלכם המעבר מ Monolyth ל Micro Services הוא תהליך ארוך ובכוונה אני לא מציע בפוסט לוחות זמנים לכל שלב או אפילו ממליץ לבצע את כל השלבים. כל מערכת, כל פרויקט, וכל צוות עם שיטת והקצב שלהם. יהיו הרבה צוותים שיישארו זמן ארוך על אחד השלבים או אפילו ייעצרו לגמרי בשלב מסוים כי זה בדיוק מה שהם צריכים. שיטת העבודה הטובה ביותר היא זו שאתם הכי פרודוקטיביים בה.