ToCode

תרגיל SQL - מחיקת שורות כפולות נתונה טבלה עם פריטים שנוצרה על ידי הפקודה:

create table items(id integer primary key, name text);

INSERT INTO items (name) VALUES
    ('Item A'),
    ('Item B'),
    ('Item C'),
    ('Item A'),
    ('Item D'),
    ('Item E'),
    ('Item B'),
    ('Item F'),
    ('Item G'),
    ('Item A'); 

מחקו את כל השורות הכפולות, כלומר השאירו מקסימום שורה אחת לכל שם של פריט. פיתרון התרגיל הזה היה נראה לי ממש פשוט בקריאה ראשונה אבל אחרי זה כשהתחלתי לכתוב את הקוד זה הסתבך, אני לא יודע אם הבעיה היא אני או SQL אז מפרסם כאן עם הפיתרון שלי. אם יש לכם כיוונים פשוטים יותר אל תתביישו לשתף. התחלתי את הפיתרון עם row_number ו partition וככה אפשר לראות בקלות ערכים כפולים - אלה שה row_number אצלכם גדול מ-1:

select
    id,
    name,
    row_number() over (partition by name) as rn
from items

עכשיו בשביל להציג רק את המזהים של השורות הכפולות צריך להשתמש ב rn בתוך תנאי where, וזה דורש הגדרת CTE. סך הכל כך אני מציג את השורות הכפולות בלבד (מלבד הראשונה):

with items_rn as (
  select
    id,  
    name,
    row_number() over (partition by name) as rn
  from items)
select id from items_rn where rn > 1

ואפילו זה לא הסוף כי בשביל למחוק אותן צריך להשתמש בכל הבלוק הזה בתור sub query, מה שמביא אותנו ל:

delete from items where id in

(with items_rn as (
  select
    id,
    name,
    row_number() over (partition by name) as rn
  from items)
select id from items_rn where rn > 1);

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

לא יודע לתכנת נכנסתי ללינקדאין אתמול אחרי הרבה זמן שלא הייתי מחובר ואחד הפוסטים שתפסו את תשומת לבי היה של בחור שכתב בוט לווטסאפ. הפוסט התחיל בהבהרה - אני לא יודע לתכנת אבל היה לי רעיון לבוט אז נעזרתי ב AI כדי לבנות אחד ולהעלות אותו. וזה ממש לא הסיפור הראשון שאני שומע על אנשים שלימדו את עצמם לתכנת ובנו פרויקט בעל משמעות בתוך מספר שבועות. הסיפורים האלה מדהימים כל פעם מחדש. יותר משהם מלמדים אותנו על עתיד תפקידנו כמתכנתים (אני חושב שהיום ש AI יכתוב קוד למערכות אמיתיות עדיין מאוד רחוק), הם מלמדים אותנו על תהליכי למידה, מוטיבציה ושימוש נכון בכלים: 1. מעולם לא היה קל יותר לבנות מוצר תוכנה מאפס. הסיפור של ההפצה נפתר מזמן כשהאינטרנט הגיעה לתפוצה רחבה, אבל היום עם ה AI נפתרה גם בעיית הבנייה. השילוב הזה פותח דלת לעתיד מאוד מעניין. 2. מעולם לא היה קל יותר ללמוד תכנות. היכולת ללמוד משהו תוך כדי עבודה על פרויקט אמיתי, ולקבל מערך שיעור מותאם עבורך עם מורה פרטי שמלווה אותך בכל שורת קוד היא בלתי נתפסת. לימוד תכנות דרך AI זו שיטת הלימוד הטובה ביותר שראיתי עד כה ולדעתי בעתיד הקרוב היא תחליף את הלימוד דרך וידאו שכל כך התרגלנו אליו. 3. לא ברור איזה פרויקטים מתכנתים מתחילים יצטרכו לכתוב כדי להוכיח יכולת ולהתקבל לעבודה. עד לפני כמה שנים היה ברור שלהגיע לראיון עם פרויקט משמעותי שכתבת נותן ערך מוסף משמעותי למועמד ומגדיל את סיכויי הקבלה לעבודה. היום כשאפשר בלי ידע בתכנות לבנות מוצר די מוצלח, הפרויקט שאותו ג'וניור יצטרך להראות כדי להוכיח יכולת עבודה צריך להבהיר למעסיק שיש פה בן אדם עם ידע בהנדסת תוכנה ולא מישהו שלימד את עצמו תכנות בשבועיים. היכולת של AI לעזור לנו לכתוב קוד מאוד מסבכת את הראיונות. לדעתי יש סיכוי לא מבוטל שבקרוב נפסיק לחפש פרויקטים כהוכחת יכולת ונחזור להסתכל על גיליונות ציונים או להתמקד בשאלות תכנות על הלוח.

ספריות בסיסי נתונים וטיפול בהבדלים בין בסיסי הנתונים ב Rails יצרתי טבלה בבסיס הנתונים עם קוד שנראה בערך כך:

create_table :users do |t|
  t.string :username
  t.string :email
  t.timestamps
end

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

'use strict';

module.exports = {
  up: async (queryInterface, Sequelize) => {
    await queryInterface.createTable('Users', {
      id: {
        type: Sequelize.INTEGER,
        autoIncrement: true,
        primaryKey: true,
        allowNull: false
      },
      username: {
        type: Sequelize.STRING,
        allowNull: false
      },
      email: {
        type: Sequelize.STRING,
        allowNull: false
      },
      createdAt: {
        type: Sequelize.DATE,
        allowNull: false,
        defaultValue: Sequelize.NOW
      },
      updatedAt: {
        type: Sequelize.DATE,
        allowNull: false,
        defaultValue: Sequelize.NOW
      }
    });
  },

  down: async (queryInterface, Sequelize) => {
    await queryInterface.dropTable('Users');
  }
};

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

export const users = mysqlTable('users', {
  id: bigint('id', { mode: 'number' }).primaryKey().autoincrement(),
  fullName: varchar('full_name', { length: 256 }),
}, (users) => ({
  nameIdx: index('name_idx').on(users.fullName),
}));

וזו מיגרציה בקיסלי שכתובה בצורה מפורשת עבור Postgresql:

  await db.schema
    .createTable('person')
    .addColumn('id', 'serial', (col) => col.primaryKey())
    .addColumn('first_name', 'varchar', (col) => col.notNull())
    .addColumn('last_name', 'varchar')
    .addColumn('gender', 'varchar(50)', (col) => col.notNull())
    .addColumn('created_at', 'timestamp', (col) =>
      col.defaultTo(sql\now()\).notNull(),
    )
    .execute()

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

טיפ Hono שימו לב לנתיבים שלא מסתיימים בלוכסן את הקוד הבא לקחתי מתוך התיעוד של hono כדי להגיש קבצים סטטיים:

app.use('/client/*', serveStatic({ root: './'}));

אם ניגשים לנתיב /client/foo.js יוגש הקובץ foo.js מתוך תיקיית client. אם ניגשים ל /client/index.html יוגש הקובץ index.html ואם ניגשים לנתיב /client/ יוגש גם כן הקובץ index.html כצפוי. אבל מה קורה אם ניגשים ל /client (בלי לוכסן בסוף)? הונו מנסה ללכת לקראתנו ואוטומטית מגיש שוב את תוכן הקובץ index.html. הבעיה היא שה URL נשאר בלי הלוכסן, ולכן אם index.html כולל הפניה לקובץ אחר ההפניה תהיה יחסית ל / ולא יחסית ל /client. לדוגמה נניח שבתוך index.html מופיעה השורה:

<link rel="stylesheet" href="style.css" />

גישה לאתר דרך הנתיב /client/ מחזירה את תוכן הקובץ index.html. בגלל שהנתיב מסתיים ב / הדפדפן מנסה לקבל את קובץ העיצוב מהנתיב /client/style.css והכל עובד. לעומת זאת גישה לאתר דרך /client עדיין מחזירה את תוכן הקובץ index.html, אבל הפעם בגלל שהתיקייה האחרונה בנתיב היא התיקייה הראשית / הדפדפן ינסה לטעון את /style.css בלי התחילית client, ייכשל והעיצוב לא יוצג. פיתרון מהיר הוא להוסיף הפניה מ /client ל /client/ עם הקוד הזה:

app.get('/client', (c) => {
  return c.redirect('/client/', 301); // Permanent redirect
});
app.use('/client/*', serveStatic({ root: './'}));

ואם אתם מכירים פיתרונות אחרים אל תתביישו לשתף בתגובות.

איך לקרוא Code Review של Chat GPT הבעיה עם Chat GPT ו Code Reviews היא שאין ל GPT עדיין מספיק קונטקסט בשביל להבין למה בניתי דברים כמו שבניתי ולכן הוא ימליץ על Best Practices כלליים, גם כשזה לא הכרחי, וגם יכול לטעות ולחשוב שלא השתמשתי ב Best Practice מסוים אפילו שכן. הנה שתי דוגמאות קטנות שעזרו לי לראות מה GPT רואה ומה הוא מפספס. שיפור קוד רובי שלחתי לו לבדיקה את הפונקציה הבאה ברובי:

require 'set'

def count_valid_requests(uniqueCodes, requests)
    uniqueCodesSet = Set.new(uniqueCodes)
    return requests.count { |r| uniqueCodesSet.include?(r) }
end

הקוד עובד ולא כתוב רע אבל אפילו בשתי שורות של קוד יש פה כמה דברים שמתכנתי רובי לא אוהבים לראות - הסטנדרט לגבי שמות המשתנים ברובי הוא להשתמש בקו תחתי להפרדה בין המילים ולא להשתמש ב return בצורה מפורשת. ChatGPT שם לב לשתי הבעיות ויצר גירסה מתוקנת של הפונקציה בלי בעיה:

require 'set'

def count_valid_requests(unique_codes, requests)
  unique_codes_set = Set.new(unique_codes)
  requests.count { |request| unique_codes_set.include?(request) }
end

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

def cancel
    wi = WorkshopInstance.find(params[:id])
    authorize! :attend, wi
    wi.users.delete(current_user)

    render json: {
             attending: attending
           }
  end

כאן הפלט כבר היה הרבה יותר ארוך - ה GPT שם לב שאין לי קוד טיפול בשגיאות, ש find עלולה לזרוק שגיאה והמליץ להחליף אותה ב find_by ואחריה קוד לבדיקה שגיאה. אני לא אוהב את ההמלצה הזאת כי אם find כבר ממילא זורק שגיאה אז לא ברור למה להחליף אותו בפונקציה שלא זורקת שגיאה ואז להוסיף בדיקה ולזרוק את השגיאה בצורה יזומה. הוא כן שם לב שהשתמשתי במשתנה attending שלא מוגדר בפונקציה, והמליץ להחליף את delete ב delete_by שבפועל קוראת ל delete_all המהירה בהרבה - שני טיפים שכדאי ליישם. קוד JavaScript אחרי זה נתתי לו לקרוא את הקוד הבא ב JavaScript:

const evtSource = new EventSource("/count");
const ti = document.querySelector('input');

evtSource.onmessage = (event) => {
  ti.value = event.data;
};

document.querySelector('button').addEventListener('click', async () => {
  await fetch('/count', {
    method: "POST",
    body: JSON.stringify({ value: ti.value }),
    contentType: 'application/json',
  });
});

ושוב הוא התלונן קודם כל על זה שאין קוד טיפול בשגיאות (במקרה הזה הוא לא נחוץ), וטען (לדעתי לא בצדק) שאפשר לשפר ביצועים אם עושים את ה querySelector במרוכז ושומרים את התוצאות במשתנים. הוא גם חשב שצריך להפעיל parseInt על value ולבדוק שהתקבל מספר, למרות שאין לזה זכר בקוד שהדבקתי. מצד שני הוא מצד יפה את הטעות שלי בהגדרת הכותרת contentType, שצריכה להיות Content-Type. סך הכל אחוז ה False Positives הוא עדיין גבוה. באופן כללי כשיש זמן אני חושב שרצוי להדביק חלקים מהקוד שלנו ל Chat GPT כדי לקבל טיפים מועילים וללמוד יותר על הקוד, אבל לקחת בחשבון שתצטרכו להשקיע זמן לפענח את התשובה שלו ולהפריד עיקר מטפל.

אבל מי יתחזק את זה? כמה סימנים חשודים שכדאי לשים לב כבר בזמן כתיבת הקוד שממש עוד רגע אי אפשר יהיה לתחזק אותו: 1. צריך להתקין תוכנות מיוחדות בשביל להריץ את הפרויקט, והתוכנות האלה חדשות במיוחד או משתנות לעתים קרובות. 2. הפרויקט משתמש בטכניקת עבודה שאף אחד לא חשב עליה קודם (זה גאוני! ידעתי שהיינו צריכים לבנות ORM בעצמנו). 3. הפרויקט משתמש בשפת תכנות ממש מיוחדת ואיזוטרית, או עדיין חדשה ומתעדכנת לעתים קרובות (כן Julia אני מסתכל עלייך). 4. אין דרך להפעיל את הפרויקט על מחשב פיתוח, הכל רץ רק בענן. הרצה מקומית משתמשת בסטאבים. 5. בחודשים האחרונים כל פעם שהיה תיקון קטן המפתחים לא הוסיפו בדיקה יחד עם התיקון כי לא היה זמן. 6. קוד משתנה אבל התיעוד שמלווה אותו נשאר ללא שינוי. 7. אף אחד לא יודע איך או מתי צריך לשדרג תלויות. כל אלה סימנים שאפשר לזהות אפילו לפני שמתחילים לעבוד על פרויקט, ויכולים לתת לכם אינדיקציה כמה זמן עוד אפשר יהיה להוסיף קוד בלי שהכל יתמוטט.

בחירת כלים לפרויקט צד מישהו שיתף השבוע ברדיט פרויקט שולה מוקשים שכתב ביום. הסטאק הטכנולוגי? tailwind ו next.js, וכן זה כולל חיבור לדומיין והעלאה לרשת. הייתי שמח לראות את הקוד אבל אפילו בלי אני מהמר שאין שם ריאקט ראוטר וגם לא רידאקס, לא בדיקות ולא תיעוד. כשהמטרה היא לבנות משהו מהר לא צריך לשבור את הראש על כלים מתוחכמים מספיק להפעיל IDE ולהתחיל לכתוב קוד. כן צריך לשים לב לשתי טעויות שאנשים עושים סביב הצלחות כאלה- 1. מפתחים רבים חושבים שאם הם הצליחו לבנות פרויקט צד מהיר בסטאק טכנולוגי "פשוט", אז כדאי להשתמש באותו סטאק טכנולוגי גם לפרויקטים מסובכים. 2. מפתחים רבים אחרים חושבים שאין מצב לבנות משהו ביום כי רק התקנת הכלים והגדרות לפרויקט חדש כדי שיהיה בנוי כמו שיש להם בפרויקט המסובך בעבודה (רידאקס, טייפסקריפט, קוברנטס, בדיקות, תיעוד) לוקח שבוע. 3. מפתחים רבים אחרים חושבים שאם כבר הם בונים פרויקט צד עדיף לבנות משהו בסטאק טכנולוגי שהם לא מכירים, ושוב מבזבזים ימים ושבועות רק על בחירת הכלים. הגמישות שמאפשרת להתאים את הכלי לפרויקט, לבחור פרויקט קטן ולהצליח לבנות אותו ביום היא מרשימה - גם אם התוצאה היא בסך הכל משחק שולה מוקשים.

אז OpenAI עברו לרמיקס הרשת גועשת סביב המעבר של OpenAI מ next ל remix. כולם משתפים חוויות ומסבירים כמה גם להם היה קשה לעבוד עם next ואיך ה App Router החדש מסובך מדי. אנסה לעשות קצת סדר: 1. אפליקציות עמוד-יחיד (SPA) זה מסובך. זה תמיד היה. ספריות לפיתוח SPA כמו react-router קיימות בדיוק בגלל שזה מסובך ושלאף אחד אין כח לטפל בלחיצות על כפתור "אחורה" וסימניות בדפדפן. אנחנו בונים SPA כי לפעמים זה נותן חווית שימוש טובה יותר. 2. רינדור בצד שרת (SSR) זה אפילו עוד יותר מסובך, כי יש לנו את כל הסיבוך של SPA ובנוסף צריכים להתמודד עם ניהול Cache בצד שרת ולוודא שהקוד של הקומפוננטות לא מפעיל דברים שצריכים את window כשהוא רץ בשרת. אנחנו מרנדרים בצד שרת כי מנועי חיפוש, קוראי מסך ועוד כלים רבים אחרים אוהבים לקבל את ה HTML מוכן גם אם הם לא מריצים JavaScript. 3. קומפוננטות צד שרת (RSC) זה אפילו עוד יותר מסובך מרינדור צד שרת. ברינדור צד שרת רגיל כל הקוד של האפליקציה משמש לבניית ה HTML ואז נשלח לדפדפן כדי להוסיף את ה JavaScript וקוד הטיפול באירועים. במבנה של קומפוננטות צד שרת צריך לבחור מראש איזה קומפוננטות כוללות קוד JavaScript שצריך לרוץ בדפדפן (אלה ה"איים" או הקומפוננטות צד לקוח) ואת הקוד שלהן אנו שולחים לדפדפן, ויש קומפוננטות אחרות שאין להן קוד טיפול באירועים ולכן נעדיף לא לשלוח את הקוד שלהן לדפדפן. ככה באפליקציה גדולה אפשר לשלוח לדפדפן פחות קוד ולקבל שיפור בזמני הטעינה ובחווית המשתמש. הנטיה של יותר מדי מפתחים היא לבחור את שיטת העבודה הכי מסובכת כי אולי נצטרך את זה בעתיד. זה מה שקרה ב OpenAI, שבונים אפליקציית SPA אבל השתמשו ב next.js שמתאים לקומפוננטות צד שרת. בשלב מסוים הם כנראה הבינו שהם משלמים יותר מדי על הבחירה הטכנולוגית שלהם ועברו לאפליקציית SPA רגילה עם רמיקס, שאגב הספיק לאחרונה להתמזג חזרה לתוך React Router. מי שמחפש תחמושת לאיזה ויכוח דמיוני בין next.js ל react router לדעתי לא ימצא אותה כאן. אם כבר יש פה רק חידוד של ההבדל בין שני הכלים והבנה יותר מדויקת של מה מתאים למה. באופן כללי התאמה של שיטת העבודה לאתגר איתו אנחנו מתמודדים ולאילוצים הטכנולוגיים של המערכת שלנו זאת הדרך הטובה ביותר לבחור ספריות לפרויקט הבא שלנו.

ניסוי Hono - סינכרון ערך בין דפדפנים התמיכה של דינו ב Web Standards הביאה לזה שמאוד קל לכתוב קוד הונו שמשתמש ב Streams כדי לקבל הודעות מגולשים ולדווח אותן הלאה לגולשים האחרים באתר, הכל ב SSE. בואו נראה איך לחבר את החוטים בפרויקט דינו ו Hono. מה אנחנו בונים האתר יכיל תיבת טקסט וכפתור. אם יש מספר גולשים שמחוברים לאתר ואחד מהם לוחץ על הכפתור אז הערך בתיבת הטקסט יישלח לכל הדפדפנים של הגולשים האחרים ויעודכן על המסך שלהם. קוד צד שרת קוד צד השרת מורכב משני נתיבים - אחד מטפל בעידכון והשני מטפל ברישום. כל גולש שנכנס לאתר פותח חיבור לנתיב הרישום, וכל פעם שלוחצים על הכפתור הגולשים שולחים הודעת POST לנתיב העידכון. אני מתחיל בהגדרת מערך של כל הגולשים שכרגע מחוברים:

const clients: Array<SSEStreamingApi> = [];

הממשק SSEStreamingApi מגיע מ Hono ומאפשר לשלוח אירועי צד שרת ללקוחות שממתינים להם. נתיב הרישום נראה כך:

app.get('/count', (c) => {
  return streamSSE(c, async (stream) => {
    stream.writeln("data: Start\n\n");
    clients.push(stream);
    const id = clients.length - 1;

    stream.onAbort(() => {
      clients.splice(id, 1);
      console.log(\removed client ${id}\);
    });
    
    while(true) {
      await stream.sleep(1000);
    }
  })
})

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

app.post('/count', async (c) => {
  console.log(\POST /count\);
  const { value } = await c.req.json();
  console.log(\Got ${value}\);

  clients.forEach(c => {
    c.writeSSE({ data: value });
  })
  
  return c.json({ message: 'Value received' });
})

קוד זה נקרא כל פעם שנשלחת בקשת POST לנתיב העידכון. הקוד רץ על כל הלקוחות במערך וכותב לכל אחד מהם את הערך שנשלח. העליתי את הקוד המלא של main.ts עם כל ה import-ים לגיטהאב מוזמנים למצוא אותו בדף הפרויקט: https://github.com/ynonp/hono-sync-counter-demo קוד צד לקוח בצד הלקוח אני רוצה להתחבר לנתיב הרישום בעלייה, ואחרי זה לשלוח הודעות POST לנתיב העדכון כל פעם שלוחצים על הכפתור. זה קובץ ה JavaScript שאני שולח ללקוח:

// client/sync.js

const evtSource = new EventSource("/count");
const ti = document.querySelector('input');

evtSource.onmessage = (event) => {
  ti.value = event.data;
};

document.querySelector('button').addEventListener('click', async () => {
  await fetch('/count', {
    method: "POST",
    body: JSON.stringify({ value: ti.value }),
    contentType: 'application/json',
  });
});

העבודה עם SSE בדפדפן מאוד נוחה ואני מעדיף אותו על פני Web Sockets עבור עידכונים אסינכרוניים מצד שרת.