ToCode

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

#include <stdio.h>
#include <unistd.h>

int main(int argc, char **argv) {
  int c = 0;

  while(1) {
    sleep(1);
    printf("Keep going..., %d seconds passed\n", c);
  }
}

יש שם משתנה שרציתי להעלות אותו ב-1 בכל איטרציה, אבל שכחתי לכתוב את השורה כדי שיהיה באג בתוכנית. את התוכנית בניתי ב gcc עם סמלי דיבג ויצרתי ממנה אימג' נטול הפצה עם ה Dockerfile הזה:

FROM gcc:4.9 as build
COPY . /usr/src/myapp
WORKDIR /usr/src/myapp
RUN gcc -g -o myapp buggy.c

CMD ["./myapp"]

FROM gcr.io/distroless/nodejs:14
WORKDIR /app
COPY --from=build --chown=nonroot:nonroot /usr/src/myapp/myapp .
USER nonroot

ENTRYPOINT ["./myapp"]

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

docker run -it ynonp/buggy-demo

## חיבור gdb לקונטיינר רץ אני מפעיל קונטיינר מהאימג' כמו שסיפרתי לכם עם:

docker run --name myapp -it ynonp/buggy-demo

ועכשיו רוצה לחבר אליו gdb כדי לדבג אותו. המפתח הוא הפקודה הבאה להפעיל קונטיינר דיבאג:

docker run --cap-add=sys_admin --cap-add=sys_ptrace --security-opt seccomp=unconfined --pid container:myapp -it ubuntu

קונטיינר הדיבאג שמופעל רואה את אותם תהליכים שיש בקונטיינר myapp, אבל יש לו אימג' שונה, הוא רץ מאימג' של ubuntu. בגלל זה אני יכול להתקין עליו כלים כמו gdb. בתוך קונטיינר הדיבאג אני מריץ:

apt-get update
apt-get install gdb

עכשיו צריך למצוא את קובץ התוכנית myapp, ואת הקוד המקורי buggy.c כי gdb צריך את שניהם בשביל לעבוד טוב. לגבי קובץ המקור בגלל שאני יצרתי אותו אני יכול פשוט להעתיק את הקוד לקונטיינר הדיבאג ולשמור אותו בשם /tmp/buggy.c. לגבי הקובץ myapp הוא מסתתר במערכת הקבצים של הקונטיינר myapp. בשביל להגיע אליו אני משתמש בתיקיה /proc ומפעיל מתוך קונטיינר הדיבאג:

cp /proc/1/root/app/myapp /tmp

הנתיב /proc/1/root הוא לינק סימבולי לשורש עץ מערכת הקבצים של תהליך מספר 1. בתוך הקונטיינר תהליך מספר 1 הוא האפליקציה שהקונטיינר הריץ, ובגלל שקונטיינר הדיבאג חולק את מספרי התהליכים עם הקונטיינר myapp אז התהליך יהיה myapp כלומר התהליך אותו אני רוצה לדבג. סך הכל בקונטיינר הדיבאג יש לי עכשיו בתיקיית /tmp גם את הקובץ myapp שהוא קובץ התוכנית שהרצתי וגם את קובץ המקור שלו buggy.c. עם שני אלה אפשר להפעיל את gdb ולהתחבר לתהליך מספר 1 שכרגע רץ:

gdb ./myapp 1

אחרי זה אני נוחת בתוך gdb, יכול ללחוץ l כדי לראות את הקוד, next כדי להריץ את השורה הבאה ו print כדי להדפיס תוכן של משתנים. ## נ.ב. למה לא להיכנס לקונטיינר הקיים? בנקודה הזאת רבים מכם אולי חושבים שהיה אפשר פשוט להיכנס לקונטיינר myapp ולהריץ עליו gdb, משהו כזה:

docker exec -it myapp /bin/bash

התשובה שלפחות בדוגמה כאן זה פשוט לא עובד, והיא לא היחידה. הקונטיינר myapp הוא קונטיינר "ללא הפצה", זה אומר שבאימג' שהוא מריץ אין shell, אין מנהל חבילות, אין את gdb ואין דרך קלה להתקין אחד. הרבה פעמים כשאנחנו בונים אימג'ים לפרודקשן אנחנו מנקים אותם מכמה שיותר דברים גם כדי לא להשאיר מקום לחורי אבטחה וגם בשביל שהכל פשוט יעבוד מהר יותר. כשקונטיינר היעד כמעט ריק, חיבור קונטיינר נוסף ודיבאג דרכו הוא הדרך הקלה ביותר להגיע לנתונים ולבדוק מה שבור. גם בעבודה עם כלים אחרים (לא C), אם קונטיינר היעד ריק ואפילו לא כולל Shell, תמיד אפשר להשתמש באותו טריק ולחבר קונטיינר דיבאג, ולהגיע למערכת הקבצים של קונטיינר היעד דרך תיקיית /proc ושם לחקור מה הבעיה.

# זהירות: סקריפטים בפרודקשן היום למדתי שאנשים אוהבים להעתיק קטעי קוד ולהדביק אותם בפרודקשן, גם כשהתוצאה עלולה לשבור להם את המערכת. ב Issue שנפתח על הגירסה החדשה של אקסיוס אנחנו מוצאים כמה פנינים: > I am experiencing this breaking change, my production app is broken and unusable to my clients. > Me three. Prod is down. Got woken up here by confused users > It affected my app in production too, axios is not a function. > Confirmed as breaking production applications on my end as well. This is a big miss in testing coverage for a library like this. > Also having multiple broken production apps here. > Experiencing issues as well on production apps. Error: "axios is not a function" הבנתם את המסר, אפשר להיכנס לקישור למצוא עוד. אז כן אקסיוס שחררו גירסה חדשה שלא תואמת אחורה. זה הולך לקרות עם כל ספריה שנעבוד איתה. מה שהוביל לקריסת הדומינו בסיפור של אקסיוס, לפחות ממה שהבנתי מקריאת ה Issue, היה לינקים ל"גירסה החדשה ביותר" דרך unpkg:

<script src="https://unpkg.com/axios/dist/axios.min.js"></script>

קופי-פייסט של זה לקובץ html ושכחתם ממנו עד שאקסיוס מעלים גירסה חדשה עם Breaking Changes. ומה שכואב פה במיוחד שקשה מאוד לעלות על בעיות כאלה בבדיקות, כי הכל עובד וקשה לסמלץ מצב ש unpkg שולחים לנו קובץ לא נכון. ופה הכח של מפתחים ועבודה לפי Best Practices. הקפדה על מספר גירסה בתגית script ומאפיין integrity היתה מונעת את כל הבעיות. בכתיבת קוד, המטרה שלנו אינה לייצר קוד "עובד" אלא קוד "יציב".

# גם בפרויקט קטן גם בפרויקט צד קטן אפשר להשתמש ב git כדי לעקוב אחרי שינויים בקבצים לאורך זמן. אפילו שרוב הסיכויים שלא תצטרכו להשוות להיסטוריה. גם בפרויקט צד קטן אפשר להשתמש ב Github Actions כדי להעלות גירסה לפרודקשן, אפילו שאתם יודעים להפעיל rsync לבד וזה ייקח לכם בדיוק שתי דקות לכל גירסה. גם בפרויקט צד קטן אפשר להשתמש בקובץ סודות מוצפן במקום לשמור מפתחות API בתוך קוד היישום. אפילו שאין באמת סכנה שיפרצו לכם למערכת כי אתם היחידים שעובדים על הקוד ויש שניים וחצי משתמשים. גם פרויקט צד קטן אפשר להעלות לפלטפורמת ענן כמו AWS ולהשתמש בכלים שיכולים לגדול. אפילו שיהיה לנו הרבה יותר זול להשתמש ב VPS של 5$ בחודש. אז למה בעצם להתאמץ? ההשקעה בתשתיות ובהרגלי עבודה בפרויקט צד קטן היא הזדמנות להתרגל לעבודה נכונה ולהכיר את הכלים שלמדנו עליהם ואיך הם מתפקדים בעולם האמיתי. ברור שהייתי שמח להגיד לכם שכל פרויקט צד שתכתבו יעלה לאוויר וירוויח מיליונים, אבל לפחות מהניסיון שלי זה לא ממש קורה. מה שכן קורה הוא שמכל פרויקט צד שאנחנו כותבים אנחנו מקבלים ניסיון, הרגלי עבודה, היכרות עם טכנולוגיות חדשות ונקודת פתיחה טובה יותר לפרויקט הבא. ואם זאת המטרה אז המאמץ לכתוב נכון רק מקרב אתכם לשם יותר מהר.

למי שפספסו הקלטה של וובינר GraphQL שעבר אתמול:

# להתקדם בלי לזוז אם אתם תקועים בעבודה עם דד-ליינים לא הגיוניים שלא מאפשרים למידה, בעבודה על מוצר מיושן, בעבודה עם טכנולוגיה שכבר אף אחד לא צריך, בעבודה עם שיטות מיושנות - יש סיכוי טוב שאתם קמים בבוקר או מסיימים את היום בתחושה שזה חייב להשתנות. אני לא אשכח את התחושה כשלימדתי קורסים ב perl, כשכל שנה היו לי פחות ופחות לקוחות, וכשקורסים וייעוצים התחילו להתבטל. את הלקוחות שלקחו קורס או ייעוץ perl רק בשביל שאעזור להם להמיר את הקוד לשפה אחרת. במקום אחר ועם הרבה יותר כסף זה היה סטפן אילופ שניסח את האבחנה המפורסמת: > Nokia, our platform is burning. כשאנחנו נמצאים על פלטפורמה בוערת, כשאנחנו רואים איך כל שנה המיומנות שלנו מחלידה ואנחנו נהיים פחות רלוונטים לשוק העבודה, דווקא מתוך הפחד המוח מאמץ כל מיני התנגדויות לשינוי, למשל "עכשיו זה לא זמן טוב לעזוב כי בדיוק חגים", או "מה אכפת לי להישאר כל עוד משלמים טוב", או אפילו "גם קובול עדיין לא מתה, בטח אסתדר כמו שהסתדרתי עד עכשיו". הבעיה הגדולה היא שלהישאר במקום לא ממש עוזר, ואנחנו עדיין לא נמצאים במקום שמאפשר לצמוח או להמשיך הלאה. אף אחד לא יקבל אותך לגוגל עם הניסיון הלא רלוונטי והמיומנות המחלידה. ולכן הפיתרון הפשוט אך קשה ליישום - לגדול איפה שאנחנו נמצאים. זה אומר: 1. למצוא דרכים להכניס שיטות עבודה מתקדמות לקוד הנוכחי, גם בסתר וגם אם הבוסים לא מרוצים מזה (קן ת'ומפסון פיתח את יוניקס במרתף ואחרי שהפרויקט בוטל). במקרה שלנו אפשר להחליט שעל כל פיצ'ר נוסיף גם בדיקות אוטומטיות או תיעוד טוב, אפשר לנהל את השינויים שלנו על מאגר גיט פרטי, אפשר לכתוב אוטומציות גם אם לא ביקשו מכם. 2. ללמוד, גם (ובמיוחד) דברים שלא קשורים לעבודה. 3. לשים לב לדברים שאתם כן אוהבים בעבודה ולעבוד על האושר שלנו ביום יום. ככל שאנחנו יותר מתלהבים מהעבודה, מהאנשים, מהטכנולוגיה או מכל דבר אחר שקשור במוצר, כך יש לנו יותר רצון ואנרגיה רגשית לשנות. המטרה ב"לגדול איפה שאנחנו נמצאים" היא לא להתחיל מיד לעשות דברים חדשים, אלא ליצור את המרחב שבו נוכל לחקור ולגדול עד שנהיה בנקודת החלטה טובה יותר. בסיפור שלי עם perl מסלול כזה היה יכול להתמקד באותם לקוחות שדווקא רצו לברוח מ perl. היה אפשר ליצור קורסים ספציפיים של "פייתון למתכנתי פרל", לבנות סטארטרים וספריות תרגום טובות ולגדול יחד עם הלקוחות במקום שבו הייתי כדי לעשות את המעבר יחד עם הלקוחות. וכן יש סיכוי טוב שזה יבוא על חשבון דברים - כתיבת אוטומציה באה על חשבון דד-ליינים לטווח קצר; מחקר ולימוד לוקחים זמן שגם אותו רוב הזמן אין. אבל חשוב לזכור שברוב מקומות העבודה יש לכם הרבה יותר חופש פעולה ממה שאתם מדמיינים, ובמיוחד במקומות עבודה מיושנים שיודעים שאין להם איך לגייס. אפשר להתקדם בלי לזוז. ושווה להתאמץ בשביל זה, כי האלטרנטיבה קשה יותר.

בוקר טוב לכל מי שמתחרט.ת/פספס.ה/שכח.ה בעוד עשר דקות נפגשים בזום ללמוד על GraphQL אפשר עדיין להצטרף בקישור הזה: https://us06web.zoom.us/j/83970209603?pwd=bVZPOCtEaHplVGtzczVWSW5UVk9jZz09

# הסתכלות קדימה בביטויים רגולאריים שפת Rust לא כוללת תמיכה מובנית בביטויים רגולאריים, ובמקום זה יש ספריית הרחבה (crate) בשם regex שאמור לתת מענה. משפט אחד מתיעוד הפתיח של הספריה מיד תופס את העין:

This crate provides a library for parsing, compiling, and executing regular expressions. Its syntax is similar to Perl-style regular expressions, but lacks a few features like look around and backreferences.

מה הם אותם look around features ואיזה כוחות על הם מוסיפים לביטויים רגולאריים? בואו נגלה. ## אתגר פרל השבועי 185 באתגר הפרל השבועי מוחמד מציע את שני התרגילים הבאים כאילו לפי הזמנה: 1. נתון קלט שנראה כמו כתובת Mac בפורמט abc1.20f1.345a; הפכו אותו לפורמט ab:c1:20:f1:34:5a. 2. נתון קלט שנראה כמו מחרוזת טקסט עם תווי הפרדה בין חלק מהאותיות (יכולים להיות בכל מקום), לדוגמה 123.abc.420. הפכו את 4 האותיות הראשונות ל x-ים. יש מיליון דרכים לפתור כל סעיף ואתם יכולים לקפוץ לדף האתגר ולהגיש פיתרון בכל שפה שתרצו. אני אסתפק בסעיף הראשון ובפיתרון באמצעות ביטוי רגולארי כדי ללמוד על הסתכלות קדימה בביטויים רגולאריים. ## הסתכלות קדימה בביטויים רגולאריים בחלק הראשון אנחנו רוצים לשנות את הפורמט של כתובת מק ולהוסיף נקודותיים בין כל שתי ספרות. החלק הקל הוא להוריד את הנקודות:

echo '1ac2.34f0.b1c2' | perl -pe 's/[^a-z0-9]//g'

1ac234f0b1c2

ויש לי גם רעיון איך להוסיף נקודותיים בין כל שני תווים:

echo '1ac2.34f0.b1c2' | perl -pe 's/[^a-z0-9]//g' | perl -pe 's/(..)/$1:/g'

אבל יש בעיה עם הפיתרון הזה. כך נראה הפלט:

1a:c2:34:f0:b1:c2:

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

echo '1ac2.34f0.b1c2' | perl -pe 's/[^a-z0-9]//g' | perl -pe 's/(..)(?=.)/$1:/g'

1a:c2:34:f0:b1:c2

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

echo '1ac2.34f0.b1c2' | perl -pe 's/[^a-z0-9]//g' | perl -pe 's/(..)(.)/$1:$2/g'

1a:c23:4f0:b1c:2

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

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

# טיפ טייפסקריפט: מחליפים if ב switch קוד הטייפסקריפט הבא לא מתקמפל, למרות שאין בו שום דבר לא בסדר:

type AB = "a"|"b";

function test(x: AB): number {
    if (x === "a") {
        return 1;
    } else if (x === "b") {
        return 2;
    }
}

זה הלינק לפלייגראונד אם אתם צריכים הוכחה: https://www.typescriptlang.org/play?#code/C4TwDgpgBAggQlAvFARAQxQHxQIxQbgChCAzAVwDsBjYASwHsKpgIBnYACgA8AuWOAJR8KZALY4IAJygBvQlAVRaJKNySJk6FANnzF+yRGBlJTAIxF9AXygQANq2jLVXdZrw65+g0ZNMATJaKVoRWQA הקו האדום הוא מתחת למילה number בתיאור ערך ההחזר של הפונקציה, בגלל שטייפסקריפט לא משוכנע שבכל המקרים הפונקציה אכן תחזיר ערך מספרי. יכול להיות, הוא חושב, שאף if לא יתקיים והפונקציה תחזיר undefined. אנחנו יודעים שזה לא יכול לקרות כי בדקנו את כל האפשרויות של x, והיינו רוצים לשכנע בזה גם את טייפסקריפט. דרך אחת לעשות את זה היא לעבור ל switch:

function test(x: AB): number {
    switch(x) {
        case "a": return 1;
        case "b": return 2;
    }
}

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

function test(x: AB): number {
    if (x === "a") {
        return 1;
    } else if (x === "b") {
        return 2;
    } else {
        // never happens
        return 0;
    }
}

שמתקן את הבעיה אבל לא מגן עליי משינוי עתידי ב AB. וגם את זה שסובל מאותה בעיה:

// @ts-ignore
function test(x: AB): number {
    if (x === "a") {
        return 1;
    } else if (x === "b") {
        return 2;
    }
}

תיקון אחרון לפוסט שעובד הפעם אבל פחות מומלץ במקרה הכללי הוא:

function test(x: AB): number {
    return {
        "a": 1,
        "b": 2,
    }[x];
}

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

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

# הזמנה לוובינר: היכרות עם GraphQL המחשבה מאחורי REST היתה גאונית בפשטותה - פרוטוקול שאחראי על העברת State משרת ללקוח, ובשמו המלא Representational State Transfer. הלקוח נכנס לקישור שמייצג State מסוים ביישום, והשרת בתגובה שולח את כל המידע של הסטייט הזה בדרך כלל כאוביקט JSON. רסט היה (וכנראה עהוא עדיין) הדרך הרגילה לכתיבת פרוטוקולי תקשורת בעולם ה Web, לפחות מאז שהפסקנו להשתמש ב SOAP ולשלוח XML-ים מצד לצד. אבל הפשטות של REST היא גם הבעיה הכי גדולה איתו, שבאה לידי ביטוי ככל שיישומים הופכים גדולים יותר וככל שמתחזקת ההפרדה בין צוותי הפיתוח: 1. למערכת יש מספר לקוחות (למשל Web ו Mobile), וכל אחד מהם צריך להציג מידע שונה, כלומר State-ים שונים. 2. מאחר וכל State מיוצג ב REST על ידי Endpoint בשרת, אנחנו נשארים לבחור אחת משתי גישות בעייתיות - או שנבנה Endpoints נפרדים בשרת לכל יישום, או שכל יישום יצטרך לגשת לכמה Endpoints כדי למשוך את המידע שהוא צריך. גרף קיו אל הוא דרך חדשה לכתוב פרוטוקולי רשת שמעביר את הכח מהשרת ללקוח, ומאפשר לשרת לייצג "משאבים" וללקוח להחליט איזה משאבים הוא צריך בכל מסך. בעזרת GraphQL אפשר לכתוב קוד צד-שרת ויישומי צד-לקוח בצורה מנותקת אחד מהשני. גרף קיו אל מאפשר לצוותים גדולים לעבוד יחד בלי לפגוע באיכות המוצר ובביצועים, ובלי ליצור תלויות בין הצוותים, וכך הוא מהווה פיתרון מושלם למערכות שמפותחות בגישת Micro Services. ביום חמישי הקרוב בתאריך 6/10 בשעה 10:00 שעון ישראל אעביר וובינר של שעה על GraphQL בו אספר על הפרוטוקול ואראה איך לקחת יישום Node.JS שבנוי בגישת REST ולהפוך אותו ל GraphQL באמצעות כתיבת Schema ו Resolver. הוובינר יעבור בזום ואתם מוזמנים להירשם ולהצטרף בקישור: https://www.tocode.co.il/workshops/123