Workers ו-Storage — קיר ה-10ms, ובחירת KV / D1 / R2 / Durable Objects

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

פתחו את ממשק הטרמינל (Terminal) שלכם והריצו את הפקודות הבאות צעד אחר צעד:

1. צרו פרויקט Worker חדש בעזרת כלי הפיגומים הרשמי c3 (Create Cloudflare CLI):

   npm create cloudflare@latest my-vibe-worker -- --template hello-world

   הפקודה תוריד את הקבצים הנדרשים ותכין סביבת פיתוח נקייה בתיקייה בשם my-vibe-worker.
2. היכנסו לתיקיית הפרויקט החדשה שנוצרה:

   cd my-vibe-worker

3. הריצו את שרת הפיתוח המקומי בעזרת כלי ה-CLI הרשמי Wrangler:

   npx wrangler dev

   כלי זה מריץ סימולטור מקומי סופר-מהיר בשם Miniflare המדמה את התנהגות האדג' של קלאודפלייר אצלכם במחשב.

פלט נראה לעין שתסיים איתו: בטרמינל תופיע שורה המודיעה שהשרת המקומי רץ בכתובת http://localhost:8787. אם תפתחו את הכתובת הזו בדפדפן, תראו מייד את הטקסט "Hello World!" מודפס על המסך ללא כל עיכוב או השהיית אתחול.

היכנסו ל-Cloudflare Dashboard שלכם, בחרו ב-Worker פעיל, והביטו בגרף ה-CPU Time (ולא ב-Duration). אתם תגלו שגם ב-Workers שמבצעים פניות אסינכרוניות ארוכות ל-APIs של AI והחזרת תגובה שלוקחת שניות ארוכות, זמן ה-CPU הממוצע נע לרוב בין 0.5ms ל-2ms בלבד.

בצעד זה נשכתב קוד טיפוסי של מפל מים (Waterfall) המבצע קריאות משנה מרובות ל-API חיצוני ונקצר את זמן הריצה שלו דרמטית באמצעות עבודה מקבילית נכונה.

1. פתחו את קובץ ה-Worker הראשי שלכם (למשל index.js או src/index.ts) בפרויקט המקומי שלכם או בתוך עורך ה-Cursor.
2. החליפו את קוד הטיפול הקיים שלכם בקוד הבא, המציג סימולציה של פנייה ל-3 מקורות מידע שונים במקביל:

export default {
  async fetch(request, env, ctx) {
    const startTime = Date.now();

    // הגדרת רשימת ה-URLs שאנו רוצים לתשאל (למשל, קריאות ל-API או ל-KV)
    const urls = [
      "https://api.cloudflare.com/client/v4/ips",
      "https://httpbin.org/delay/1", // קריאה שמדמה השהיה של שנייה
      "https://httpbin.org/user-agent"
    ];

    try {
      // במקום לבצע await לכל fetch בנפרד, אנו יוצרים מערך של Promises
      const promises = urls.map(url => fetch(url).then(res => res.json()));

      // הרצה מקבילית אמיתית - כל 3 קריאות המשנה יוצאות לדרך בו-זמנית!
      const [cloudflareIPs, delayedData, userAgent] = await Promise.all(promises);

      const duration = Date.now() - startTime;

      return new Response(JSON.stringify({
        message: "Success!",
        durationMs: duration,
        data: {
          ipsCount: cloudflareIPs.result?.ipv4_cidrs?.length || 0,
          userAgent: userAgent["user-agent"]
        }
      }), {
        headers: { "Content-Type": "application/json" }
      });

    } catch (error) {
      return new Response(JSON.stringify({ error: error.message }), {
        status: 500,
        headers: { "Content-Type": "application/json" }
      });
    }
  }
};

3. הריצו את השרת המקומי באמצעות פקודת ה-Wrangler הבאה בטרמינל (הפקודה תפעיל את מנוע Miniflare המובנה שמדמה את סביבת הענן באופן מקומי):

   npx wrangler dev

   הפלט הצפוי בטרמינל יציג הודעה שהשרת רץ בכתובת local host (למשל http://localhost:8787).
4. פתחו את הדפדפן או שלחו בקשת curl לכתובת שקיבלתם. שימו לב לערך durationMs המוחזר ב-JSON. תראו שהוא עומד על כ-1000ms בלבד (בגלל ההשהיה המובנית של הבקשה השנייה), למרות שביצענו שלוש קריאות רשת נפרדות שהיו אמורות לקחת במצטבר הרבה יותר זמן!

פלט נראה לעין שתסיים איתו: תקבלו תשובת JSON מסודרת מה-Worker המציגה את התוצאות משני השרתים השונים ואת זמן הריצה המהיר ביותר האפשרי עבור קריאות אלו.

כדי להבין כיצד פועל פיתוח מקומי מול רכיבי האחסון של קלאודפליי, נקים כעת פרויקט מינימלי ונבדוק כתיבה וקריאה מ-KV מקומי בעזרת Wrangler CLI (כלי הפיתוח הרשמי של Cloudflare).

1. פתחו את מסוף הפקודות (Terminal) והריצו את הפקודה הבאה כדי ליצור פרויקט Worker חדש (ודאו שמותקן אצלכם Node.js):

   npm create cloudflare@latest my-storage-vibe -- --framework=hono

   במהלך ההתקנה, בחרו בברירות המחדל (TypeScript, ויצירת פרויקט חדש).
2. היכנסו לתיקייה שנוצרה והתקינו את התלויות:

   cd my-storage-vibe

3. פתחו את הקובץ wrangler.toml הממוקם בשורש הפרויקט והוסיפו את קישור ה-KV (הנקרא Binding) על ידי הוספת השורות הבאות בסוף הקובץ:

   [[kv_namespaces]]
   binding = "MY_KV"
   id = "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" # מזהה דמוי עבור הפיתוח המקומי

4. פתחו את הקובץ src/index.ts והחליפו את תוכנו בקוד הבא, המאפשר כתיבה וקריאה של מידע מה-KV:

   import { Hono } from 'hono'
   
   type Bindings = {
     MY_KV: KVNamespace
   }
   
   const app = new Hono<{ Bindings: Bindings }>()
   
   app.get('/write', async (c) => {
     const timestamp = new Date().toISOString()
     await c.env.MY_KV.put('last_access', timestamp)
     return c.text(`Saved timestamp: ${timestamp}`)
   })
   
   app.get('/read', async (c) => {
     const value = await c.env.MY_KV.get('last_access')
     return c.text(`Stored value: ${value || 'No value found yet'}`)
   })
   
   export default app

5. הריצו את השרת המקומי באמצעות Wrangler:

   npx wrangler dev

   השרת המקומי יפתח בכתובת http://localhost:8787.
6. פתחו את הדפדפן וגשו לכתובת http://localhost:8787/write. אתם אמורים לראות את הפלט המאשר את שמירת זמן הכתיבה. לאחר מכן, גשו לכתובת http://localhost:8787/read כדי לראות את שליפת הנתון ששמרתם.

פלט נראה לעין שתסיים איתו: בדפדפן יוצג הטקסט Stored value: 2026-05-29T12:00:00.000Z (בהתאם לזמן המדויק שבו הרצתם את פקודת הכתיבה). במסוף של Wrangler תוכלו לראות את תיעוד הבקשות ואת השימוש בממשק Local Explorer המאפשר לכם לצפות פיזית בערכים השמורים ב-KV המקומי שלכם דרך הדפדפן.

בצעו את הצעדים הבאים כדי להגדיר תיקיית KV מקומית, לכתוב אליה ערך ולשלוף אותו בהרצה מקומית מלאה:

1. פתחו את קובץ ההגדרות
   בינוני5 דקותחינםdatabase-indexing

   D1 SQLite ב-Edge: שאילתות רלציוניות ומחלת ה-Rows Read שתשבית לכם את המסד

   כשאתם בונים אפליקציות מודרניות על גבי התשתית של Cloudflare, אחד הכלים החזקים ביותר שעומדים לרשותכם הוא D1. זהו מסד נתונים רלציוני מבוסס SQLite, הפועל ישירות בתוך ה-Edge (קצה הרשת — רשת שרתים עולמית הפרוסה ביותר מ-300 ערים בעולם ומקרבת את החישוב פיזית אל המשתמש). המשמעות היא שרמת השהיית הגישה (Latency — הזמן שלוקח למידע לעבור מהשרת למשתמש) היא אפסית. ה-Workers שלכם (רכיבי Serverless המבוססים על V8 Isolate — סביבת הרצה מבודדת וקלת משקל המאפשרת הפעלה מיידית ללא השהיית עלייה המכונה Cold Start) מתקשרים עם D1 בצורה מהירה ויעילה במיוחד. עם זאת, העבודה בסביבת קצה מביאה איתה מודל תמחור ומגבלות ייחודיים שאתם חייבים להבין לעומק כדי לא להתעורר בוקר אחד ולגלות שהאפליקציה שלכם הושבתה. בעוד שבמסדי נתונים מסורתיים אתם משלמים על זיכרון ומעבד, ב-D1 המדד המרכזי שקובע אם תעברו למסלול בתשלום הוא כמות השורות שנקראו (Rows Read) וכמות השורות שנכתבו (Rows Written). בתוכנית החינמית אתם מקבלים מגבלה נדיבה של 5 מיליון שורות שנקראו ביום ו-100,000 שורות שנכתבו ביום. כאן בדיוק טמונה המלכודת הגדולה שנקראת Full-Table Scan (סריקת טבלה מלאה). כאשר אתם מריצים שאילתת SQL עם תנאי סינון מסוים, מנוע SQLite נדרש למצוא את השורות המתאימות. אם השדה שאתם מסננים לפיו אינו מוגדר כ-Index (אינדקס — מבנה נתונים מיוחד המאפשר למסד למצוא שורות במהירות מבלי לסרוק את כולן), המנוע ייאלץ לקרוא כל שורה ושורה בטבלה שלכם מתחילתה ועד סופה. אם יש לכם 50,000 שורות בטבלה, חיפוש של שורה בודדת ללא אינדקס מתאים יעלה לכם ב-50,000 Rows Read, למרות שהקוד שלכם יקבל חזרה רק שורה אחת! הרצה של שאילתה כזו 100 פעמים בלבד ביום תביא אתכם למגבלת ה-5 מיליון ותשתק את האפליקציה שלכם לחלוטין.

   ההבדל הקריטי בין שורות שחזרו לשורות שנקראו

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

   SELECT * FROM users WHERE email = 'x'SELECT * FROM users WHERE email = 'x'SELECT * FROM posts LIMIT 10SELECT * FROM posts ORDER BY views DESC LIMIT 10

   סוג השאילתה	מצב האינדקס בטבלה	שורות מוחזרות (Returned)	שורות שנקראות בפועל (Rows Read)
   ללא אינדקס (Full-Table Scan)	1	N (כל השורות בטבלה)
   קיים אינדקס על העמודה email	1	1
   ללא סינון (סריקה פשוטה עם מגבלה)	10	10
   ללא אינדקס על העמודה views	10	N (סריקה ומיון של כל הטבלה)

   טעות נפוצה: הרצת שאילתות SELECT ללא סעיף WHERE על טבלאות צומחות ב-D1

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

   למה זה טעות: פעולה זו גורמת ל-Full-Table Scan מלא בכל פנייה. ככל שקהל המשתמשים שלכם גדל וכמות הנתונים נצברת, כל קריאה בודדת למסד הנתונים תעלה לכם במיליוני Rows Read. המכסה החינמית של 5 מיליון שורות ביום תישרף תוך דקות בודדות, והאפליקציה תחזיר שגיאות קריטיות לכל המשתמשים.

   מה לעשות במקום: הגדירו תמיד מגבלות LIMIT קשיחות בקוד השאילתה, והקפידו ליצור INDEX מוגדר על כל השדות שמופיעים בתוך סעיפי ה-WHERE או ה-ORDER BY שלכם.

   בדקו את תוכנית השאילתה שלכם עכשיו! 3 דקות

   פתחו את ממשק הטרמינל (Terminal) שלכם והריצו את פקודת ה-Explain של Wrangler כדי לבדוק האם השאילתה הכי נפוצה באפליקציה שלכם מבצעת סריקת טבלה מלאה ומסוכנת:

   npx wrangler d1 execute my-database-name --remote --command="EXPLAIN QUERY PLAN SELECT * FROM users WHERE email = 'user@example.com';"

   אם בפלט של הפקודה אתם רואים את המילים SCAN TABLE, המשמעות היא שאתם מבצעים סריקה מלאה ומבזבזים משאבים. אם מופיע SEARCH TABLE USING INDEX, השאילתה שלכם מוגנת ויעילה!

   מתודולוגיית ניהול והגבלת Rows Read ב-D1

   שלב 1: הוספת Index מדויק על השדות בשאילתות ה-WHERE.

   • ללא אינדקס, חיפוש שדה יסרוק את כל הטבלה. יצירת אינדקס בעזרת CREATE INDEX הופכת את עלות החיפוש מ-O(N) (סריקת כל השורות) ל-O(log N) (סריקה של שורות בודדות בלבד).

   שלב 2: הגבלת כמות השורות המוחזרות באמצעות LIMIT קשיח.

   • לעולם אל תסמכו על כך שהטבלה קטנה. הגדירו LIMIT 100 או ערך הגיוני אחר בכל שאילתת קריאה כדי למנוע מצב שבו באג בקוד הלקוח ימשוך מיליוני שורות בטעות.

   שלב 3: הרצת EXPLAIN באופן קבוע לבחינת תוכניות השאילתה.

   • לפני שאתם משחררים קוד לייצור (Production), הריצו EXPLAIN QUERY PLAN SELECT ... ב-CLI של Wrangler. השתמשו בפלט כדי לוודא שמופיעה המילה "USING INDEX" ולא "SCAN TABLE".

   שלב 4: שימוש ב-KV כשכבת Caching מעל D1 לשאילתות כבדות וחוזרות.

   • שאילתות מורכבות שמחשבות נתונים סטטיסטיים לא צריכות לרוץ על D1 בכל טעינת דף. שמרו את התוצאה ב-Workers KV (שבו יש 100,000 קריאות חינם ביום) עם תוקף (TTL) של מספר שעות, וקראו משם.
   בניית מחשבון "פיצוץ מגבלות" חינמי שיחשב מתי ה-Isolate שלכם יעלה כסף 25 דקות

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

   1. בדיקה והתקנה של דרישות קדם:

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

      node -v

      הפלט הצפוי הוא גרסה כגון v18.x.x או v20.x.x. אם הפקודה אינה מזוהה, עליכם להוריד ולהתקין את Node.js מהאתר הרשמי שלהם לפני שתמשיכו.

   2. התחברות לחשבון Cloudflare שלכם:

      כדי שתוכלו לעבוד עם הכלים של Cloudflare מהמחשב האישי, בצעו הרשמה וחיבור לחשבון שלכם על ידי הרצת הפקודה:

      npx wrangler login

      פלט צפוי: הטרמינל יפתח חלון דפדפן אינטרנט שמבקש מכם לאשר את החיבור ל-Wrangler. לאחר שתלחצו על "Allow", הטרמינל יציג הודעת הצלחה: Successfully logged in.

   3. יצירת פרויקט חדש והתקנת חבילות:

      הריצו את הפקודות הבאות כדי ליצור תיקייה חדשה,

      מתחיל5 דקותחינםstorage-configuration

      R2 Object Storage: אחסון קבצים ללא דמי תעבורה (Zero Egress) וחישוב מחלקות אופרציה A ו-B

      שירות האחסון Cloudflare R2 הוא פתרון אחסון אובייקטים (Object Storage — מערכת לאחסון קבצים לא מובנים כמו תמונות, וידאו, קובצי קול ומסמכים) התואם לחלוטין לפרוטוקול S3 הפופולרי של אמזון. היתרון הגדול ביותר שלו, שמבדיל אותו מכל שירותי הענן המסורתיים כמו AWS S3 או Google Cloud Storage, הוא מודל ה-Zero Egress (אפס עלויות תעבורה יוצאת). בעולם הענן המסורתי, אתם משלמים לא רק על נפח האחסון הפיזי, אלא קנס כבד בכל פעם שמשתמש מוריד קובץ, או כשאתם מעבירים קובץ מהשרת שלכם ליעד אחר באינטרנט. עלויות תעבורה יוצאת אלה (Egress Fees) הן ה"מלכודת" הפיננסית שמונעת פיתוח חופשי של אפליקציות עתירות מדיה. ב-R2, העברת קבצים החוצה לרשת האינטרנט או לתוך ה-Workers שלכם היא חינמית לחלוטין וללא הגבלה, מה שהופך אותו למושלם עבור אפליקציות AI שמייצרות או מעבדות כמויות עצומות של קבצי מדיה, כגון מחוללי תמונות, מערכות המרת קול לטקסט (Transcriptions), או סוכני AI שצריכים לשלוף קבצי PDF גדולים לצורך RAG (Retrieval-Augmented Generation — שיטה להעשרת מודלי שפה במידע חיצוני ייעודי).

      הסוד של R2: מה זה Zero Egress ולמה זה משנה את חוקי המשחק?

      עלויות Egress הן החשבון המפתיע ביותר שמפתחים מקבלים בסוף החודש. נניח שאתם מריצים אפליקציית AI שמייצרת קובצי אודיו מותאמים אישית למשתמשים שלכם, ונפח הקבצים הכולל הוא 100 גיגה-בייט. באמזון S3, האחסון עצמו יעלה לכם דולרים בודדים. אך אם המשתמשים שלכם יקשיבו לקבצים הללו מספר פעמים, ויגרמו להורדה של 1 טרה-בייט (TB) של מידע בחודש, אמזון תגבה מכם כ-90 דולר רק על עצם מעבר המידע מהשרתים שלה אליהם! ב-Cloudflare R2, עלות התעבורה הזו היא $0.00 עגול. אתם משלמים אך ורק על נפח האחסון הפיזי בפועל ($0.015 לגיגה-בייט בחודש לאחר חריגה מ-10 הגיגה-בייט החינמיים שלכם). זה מאפשר לכם לבנות אפליקציות מבלי לחשוש שהצלחה ויראלית של המוצר שלכם תגרור חובות ענק לענקיות הענן.

      חישוב עלויות: ההבדל הקריטי בין Class A ל-Class B Operations

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

      • Class A Operations (פעולות מסוג א'): אלו הן פעולות שמשנות את המצב של האחסון או דורשות משאבים כבדים לניהול המטא-דאטה. הדוגמה הקלאסית היא PutObject (העלאת קובץ חדש או דריסת קובץ קיים), CopyObject (העתקת קובץ בתוך הבאקט), ופעולות של יצירת העלאה בחלקים (Multipart Upload). בנוסף, פקודות כמו ListObjects שמבקשות לקבל רשימה של הקבצים בתיקייה נחשבות גם הן ל-Class A. המסלול החינמי של R2 מעניק לכם 1 מיליון פעולות מסוג זה בחודש, ומעבר לכך העלות היא $4.50 לכל מיליון פעולות נוספות.
      • Class B Operations (פעולות מסוג ב'): אלו הן פעולות קריאה בלבד שאינן משנות דבר במערכת. הדוגמה המרכזית היא GetObject (הורדה או שליפה של קובץ כדי להציגו למשתמש או לעבד אותו ב-Worker) וכן HeadObject (שליפת המידע הטכני על הקובץ, כמו הגודל שלו או תאריך היצירה, מבלי להוריד את הקובץ עצמו). מכיוון שפעולות אלו זולות בהרבה לביצוע, המסלול החינמי נדיב במיוחד ומעניק 10 מיליון פעולות בחודש, ומעבר לכך תשלמו $0.36 בלבד לכל מיליון פעולות.

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

      אחסון בתדירות נמוכה (Infrequent Access) — מתי הוא חוסך כסף?

      החל משנת 2025/2026, Cloudflare מאפשרת להגדיר קבצים תחת קלאס אחסון מיוחד שנקרא Infrequent Access (גישה לא תכופה). במסלול זה, עלות האחסון הפיזי יורדת מ-$0.015 ל-$0.01 בלבד לגיגה-בייט בחודש. אולם, יש לכך מחיר: פעולות Class A ו-Class B עולות כפול (Class A עולה $9.00 למיליון, Class B עולה $0.90 למיליון), ונוספת עלות אחזור (Retrieval Fee) של $0.01 לכל גיגה-בייט של מידע שאתם קוראים. כלל האצבע הוא פשוט: אם יש לכם קבצים שאתם חייבים לשמור מטעמי רגולציה, גיבויים היסטוריים או קובצי ארכיון של שיחות משתמשים ישנות, שהסיכוי שמישהו יבקש לקרוא אותם נמוך מפעם בחודש — העבירו אותם ל-Infrequent Access. לקבצים פעילים שנמצאים בשימוש שוטף של האפליקציה, השאירו אותם תמיד באחסון ה-Standard הרגיל.

      יצירת באקט R2 וחיבורו ל-Worker 10 דקות

      בצעד זה ניצור באקט R2 חדש באמצעות כלי הפיתוח Wrangler, נגדיר עבורו קישור מהיר (Binding) בקובץ הקונפיגורציה, ונכתוב קוד קצר שמדגים העלאה (Class A) וקריאה (Class B) של קבצים.

      1. ראשית, ודאו שאתם מחוברים לחשבון ה-Cloudflare שלכם דרך ה-CLI:

         npx wrangler login

      2. צרו באקט R2 חדש בשם vibe-storage על ידי הרצת הפקודה הבאה במסוף שלכם. הפלט יאשר שהבאקט נוצר בהצלחה באזור הגיאוגרפי הקרוב ביותר אליכם:

         npx wrangler r2 bucket create vibe-storage

      3. פתחו את קובץ ה-wrangler.toml בפרויקט שלכם והוסיפו את הגדרת הקישור הבאה בקצה הקובץ. קישור זה חושף את הבאקט ישירות לקוד ה-Worker תחת המשתנה הגלובלי env.MY_BUCKET:

         [[r2_buckets]]
         binding = "MY_BUCKET"
         bucket_name = "vibe-storage"

      4. החליפו את קוד ה-Worker שלכם בקובץ src/index.ts בקוד הבא, המטפל בבקשות POST להעלאת קבצים ובבקשות GET לשליפתם:

         export default {
           async fetch(request, env) {
             const url = new URL(request.url);
             const key = url.pathname.slice(1); // חילוץ שם הקובץ מנתיב ה-URL
         
             if (!key) {
               return new Response("אנא ספקו שם קובץ בנתיב (למשל: /document.txt)", { status: 400 });
             }
         
             // פעולת Class A: כתיבת אובייקט (PutObject)
             if (request.method === "POST") {
               const body = await request.text();
               await env.MY_BUCKET.put(key, body, {
                 headers: { "Content-Type": "text/plain; charset=utf-8" }
               });
               return new Response(`הקובץ ${key} נשמר בהצלחה ב-R2! (בוצעה פעולת Class A)`, { status: 200 });
             }
         
             // פעולת Class B: קריאת אובייקט (GetObject)
             if (request.method === "GET") {
               const object = await env.MY_BUCKET.get(key);
               if (object === null) {
                 return new Response("הקובץ המבוקש לא נמצא בבאקט", { status: 404 });
               }
               
               const headers = new Headers();
               object.writeHttpMetadata(headers);
               headers.set("Access-Control-Allow-Origin", "*");
               
               return new Response(object.body, { headers });
             }
         
             return new Response("שיטה לא נתמכת. השתמשו ב-GET לקריאה או POST לכתיבה", { status: 405 });
           }
         };

      5. הפעילו את שרת הפיתוח המקומי שלכם כדי לבדוק שהכל מוגדר כהלכה:

         npx wrangler dev

      פלט נראה לעין שתסיים איתו: לאחר שתריצו את ה-Worker מקומית, תוכלו להשתמש בכלי כמו Postman או Curl כדי לשלוח בקשת POST עם תוכן טקסט כלשהו לנתיב http://localhost:8787/

      מתקדם5 דקותחינםstateful-architecture

      Durable Objects: ניהול State עקבי בזמן אמת, SQLite backend ומלכודת ה-GB-Seconds

      בפיתוח אפליקציות מבוססות בינה מלאכותית וכלים בזמן אמת, אנו נתקלים במהירות במה שמכונה "קיר ה-10ms" — מגבלת זמן העיבוד (CPU Time) של השרתים החינמיים. בעוד שרכיבי חישוב ללא שרת (Serverless Compute) סטנדרטיים מצטיינים בפעולות מהירות ונטולות מצב (Stateless), ניהול מצב עקבי בזמן אמת דורש גישה ארכיטקטונית שונה לחלוטין. כאן נכנסים לתמונה Durable Objects (אובייקטים עמידים).

      Durable Objects הם רכיבי קוד ייחודיים בעלי כתובת גלובלית יחידה (Globally Addressable), המשלבים כוח עיבוד יחד עם אחסון קבוע וצמוד. בניגוד ל-Workers רגילים שמתעוררים ונעלמים עם כל בקשת רשת, אובייקט עמיד נשאר דולק בזיכרון כל עוד מתבצעת מולו אינטראקציה. הייחודיות הגדולה ביותר שלו היא הרצת קוד בחוט יחיד (single-threaded execution). מנגנון זה מבטיח כי כל הבקשות המופנות לאובייקט ספציפי יעובדו באופן סדרתי, אחת אחרי השנייה. בכך נמנעות לחלוטין בעיות סנכרון נתונים מורכבות (Race Conditions) ומבוטל הצורך במנגנוני נעילת מסדי נתונים מורכבים (Database Locks). זהו פתרון מושלם לניהול צ'אטים קבוצתיים, משחקי רשת, סנכרון מסמכים בזמן אמת או ניהול זיכרון של סוכני בינה מלאכותית (Agent Memory).

      עליית ה-SQLite Backend ומודל האחסון המקומי

      עד לתחילת שנת 2026, ניהול המצב בתוך Durable Objects התבסס בעיקר על ממשק מפתח-ערך (Key-Value) פשוט ומוגבל. השינוי הדרמטי שהושלם ב-2026 הוא השילוב המובנה של Durable Objects מבוססי SQLite backend. כעת, לכל מופע (

      בינוני5 דקותחינםevent-driven-architecture

      צינורות העבודה של האדג': Workflows, Queues ו-Cron Triggers לתזמון משימות ב-$0

      // יצירת משימה אסינכרונית עם מזהה ייחודי const taskPayload = { jobId: crypto.randomUUID(), timestamp: Date.now(), action: "PROCESS_AI_DATA" }; // שליחת המשימה לתור לטיפול אסינכרוני ברקע await env.MY_QUEUE.send(taskPayload); console.log(`[Cron Trigger] Successfully pushed job ${taskPayload.jobId} to Queue.`); }, async queue(batch: MessageBatch, env: Env, ctx: ExecutionContext): Promise { console.log(`[Queue Consumer] Received a batch of ${batch.messages.length} messages.`); for (const message of batch.messages) { const payload = message.body; console.log(`[Queue Consumer] Processing Job ID: ${payload.jobId} (Action: ${payload.action})`); // כאן יכולה לבוא לוגיקה כבדה, קריאה ל-APIs או עיבודי נתונים // המתנה סימולטיבית (לא צורכת CPU באדג') await new Promise(resolve => setTimeout(resolve, 500)); // אישור שהודעה טופלה בהצלחה והסרתה מהתור message.ack(); }

      מתחיל5 דקותחינםdebug-and-security

      Hyperdrive וסביבת הפיתוח: קישור בסיסי נתונים חיצוניים, בדיקות עם Wrangler וסימולציות

      כשאתם בונים אפליקציות מבוססות בינה מלאכותית, אתם לרוב צריכים לשמור נתוני משתמשים, היסטוריית שיחות או הגדרות מערכת בבסיס נתונים רלציוני חזק כמו PostgreSQL (למשל באמצעות Supabase או Neon). אולם, כאן אתם נתקלים בבעיה ארכיטקטונית קשה המכונה "קיר ה-10ms" ומגבלות החיבורים של שרתים שאינם שרתים פיזיים קבועים (Serverless). קוד ה-Worker שלכם מבוסס על ארכיטקטורת V8 Isolate — סביבת ריצה מבודדת וקלת משקל במיוחד שקמה לתחייה בשבריר מילי-שנייה כדי לענות על בקשה של משתמש, ונסגרת מיד לאחר מכן. בסיסי נתונים מסורתיים, לעומת זאת, לא תוכננו לקצב מהיר כזה של חיבור וניתוק. כל חיבור חדש לבסיס הנתונים דורש תהליך לחיצת יד (TCP/TLS Handshake) שלוקח זמן יקר ומכלה את משאבי הזיכרון של שרת ה-Database שלכם. אם 1,000 משתמשים יפעילו את ה-Worker שלכם בו-זמנית, בסיס הנתונים פשוט יקרוס מעומס חיבורים.

      כדי לפתור את הבעיה הזו בדיוק נוצר **Hyperdrive** — מנהל חיבורים (Database Connection Pooler) ומטמון שאילתות גלובלי המובנה ברשת של Cloudflare. Hyperdrive פועל כגשר חכם: הוא מחזיק בריכת חיבורים פתוחה וקבועה מול בסיס הנתונים המרוחק שלכם. כאשר ה-Worker שלכם מבקש לשלוח שאילתה, הוא לא פותח חיבור חדש מול בסיס הנתונים, אלא משתמש בחיבור קיים ש-Hyperdrive כבר מחזיק עבורו. בנוסף, Hyperdrive מציע יכולת שמירת שאילתות במטמון (Query Caching) ישירות בנקודות הקצה של Cloudflare. שאילתות קריאה (SELECT) זהות לא יגיעו כלל לבסיס הנתונים שלכם, אלא יוחזרו ישירות מהמטמון הקרוב ביותר למשתמש תוך מילי-שניות בודדות.

      חשוב לזכור מגבלה קריטית אחת במסלול החינמי: Cloudflare מאפשרת עד 100,000 שאילתות ביום דרך Hyperdrive בחינם. כל הצהרת SQL נספרת במכסה הזו, כולל שאילתות שנשלפו ישירות מהמטמון ולא הגיעו לבסיס הנתונים שלכם פיזית. באפליקציות עתירות תנועה, המגבלה הזו עשויה להיגמר מהר, ולכן מומלץ לתכנן נכון את תדירות השאילתות או לשדרג למסלול בתשלום המבטל מגבלה זו לחלוטין.

      סביבת פיתוח מקומית ובדיקות עם Wrangler

      כדי לפתח, לבדוק ולנהל את החיבורים הללו, אנחנו משתמשים ב-**Wrangler** — כלי ה-CLI (ממשק שורת הפקודה) הרשמי של Cloudflare. במהלך הפיתוח המקומי, הפקודה wrangler dev מקימה שרת סימולציה מקומי המבוסס על מנוע Miniflare. מנוע זה מדמה את סביבת הריצה של ה-Worker ואת כל הקישורים שלו (Bindings) ל-KV, D1 ו-R2 בצורה מקומית לחלוטין במחשב שלכם. עבור Hyperdrive, סביבת הפיתוח המקומית יודעת לבצע מעקף חכם ולחבר אתכם ישירות לבסיס הנתונים המוגדר לצורך פיתוח, ללא צורך בהקמת שרת פרוקסי מורכב במחשב האישי.

      כאשר אתם צריכים לאבטח מידע רגיש כמו סיסמאות חיבור לבסיס הנתונים, אסור לכתוב אותן ישירות בקוד או בקובץ ההגדרות wrangler.toml שלכם. במקום זאת, נשתמש בפקודה wrangler secret put אשר מצפינה את המפתח ושומרת אותו בצורה מאובטחת בשרתי Cloudflare. בזמן הריצה בייצור, הסוד יהיה זמין ל-Worker שלכם כמשתנה סביבה מוצפן. לבסוף, כדי לראות מה קורה בזמן אמת בייצור ולאתר תקלות חמקמקות שאינן משתחזרות במחשב המקומי, תוכלו להשתמש בפקודה wrangler tail. פקודה זו פותחת ערוץ הזרמת לוגים חי ישירות מכל נקודות הקצה של Cloudflare ברחבי העולם אל תוך מסך המסוף שלכם, כך שכל הודעת שגיאה או console.log יוצגו לכם באופן מיידי.

      חיבור בסיס נתונים חיצוני והרצתו מקומית 15 דקות

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

      תנאים מקדימים: וודאו שמותקן אצלכם Node.js במחשב, שיש לכם חשבון Cloudflare, ושיש ברשותכם מחרוזת חיבור (Connection String) לבסיס נתונים PostgreSQL פעיל (למשל, בסיס נתונים חינמי מ-Neon.tech או Supabase).

      1. פתחו את מסוף הפקודות והתקינו את Wrangler באופן גלובלי (אם עדיין לא מותקן) ובצעו התחברות לחשבון שלכם:

         npm install -g wrangler
         wrangler login

         הדפדפן ייפתח ויבקש מכם לאשר את החיבור לחשבון Cloudflare שלכם. לאחר האישור, המסוף יציג הודעת הצלחה: Successfully logged in.

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

         npm create cloudflare@latest hyperdrive-demo -- --type=simple

         בחרו ב-TypeScript כאשר תישאלו על שפת הפיתוח, ואשרו את יצירת תיקיית הפרויקט.

      3. היכנסו לתיקיית הפרויקט והתקינו את חבילת החיבור לבסיס הנתונים pg ואת הגדרות הטיפוסים שלה עבור TypeScript:

         cd hyperdrive-demo
         npm install pg
         npm install --save-dev @types/pg

      4. כעת, ניצור את חיבור ה-Hyperdrive שלכם מול בסיס הנתונים החיצוני. החליפו את מחרוזת החיבור הפקטיבית במחרוזת האמיתית שלכם:

         wrangler hyperdrive create my-db-link --connection-string="postgres://user:password@ep-cool-pool-1234.eastus.neon.tech/neondb"

         פלט צפוי: המסוף יפלוט אובייקט JSON המכיל מזהה ייחודי ארוך תחת השדה id. שמרו את המזהה הזה בצד, נשתמש בו מיד.

      5. פתחו את הקובץ wrangler.toml שבשורש הפרויקט שלכם, ומחקו את תוכנו. הדביקו במקומו את הגדרות הפרויקט והגדרת ה-Hyperdrive החדש שלכם (החליפו את ה-id במזהה שקיבלתם בשלב הקודם):

         #:schema node_modules/wrangler/config-schema.json
         name = "hyperdrive-demo"
         main = "src/index.ts"
         compatibility_date = "2026-05-01"
         
         [[hyperdrive]]
         binding = "DB"
         id = "מחקו_והדביקו_כאן_את_ה-ID_שקיבלתם"

      6. פתחו את הקובץ src/index.ts והחליפו את כל הקוד הקיים בקוד הבא, המבצע חיבור לבסיס הנתונים דרך Hyperdrive ושולף את השעה הנוכחית בשרת:

         import { Client } from 'pg';
         
         export interface Env {
             DB: Hyperdrive;
         }
         
         export default {
             async fetch(request: Request, env: Env, ctx: ExecutionContext): Promise<Response> {
                 // Hyperdrive מספק לנו את מחרוזת החיבור המותאמת שלו דרך ה-Binding
                 const client = new Client({ connectionString: env.DB.connectionString });
                 
                 try {
                     await client.connect();
                     const result = await client.query('SELECT NOW() as current_time;');
                     
                     return new Response(JSON.stringify({
                         success: true,
                         database_time: result.rows[0].current_time,
                         message: "Connected to PostgreSQL via Hyperdrive successfully!"
                     }), {
                         headers: { 'Content-Type': 'application/json' }
                     });
                 } catch (err: any) {
                     return new Response(JSON.stringify({ 
                         success: false, 
                         error: err.message 
                     }), {
                         status: 500,
                         headers: { 'Content-Type': 'application/json' }
                     });
                 } finally {
                     // סגירת החיבור בצורה אסינכרונית לאחר החזרת התגובה למשתמש
                     ctx.waitUntil(client.end());
                 }
             },
         };

      7. הריצו את שרת הפיתוח המקומי שלכם לצורך בדיקה וסימולציה:

         wrangler dev

         פלט צפוי: השרת המקומי יתחיל לרוץ ויציג לכם כתובת מקומית, לרוב http://localhost:8787. פתחו את הדפדפן וגשו לכתובת זו.

      פלט נראה לעין שתסיים איתו: דף דפדפן המציג קובץ JSON תקין עם השעה המדויקת של שרת בסיס הנתונים שלכם: {"success":true,"database_time":"2026-05-29T14:32:01.123Z","message":"Connected to PostgreSQL via Hyperdrive successfully!"}. זהו אישור מוחלט לכך שהסימולציה המקומית הצליחה לפנות בצורה תקינה אל ה-Database החיצוני דרך הגדרות ה-Wrangler שלכם.

      שגרת עבודה

      תדירות	פעולה
      לפני כל פריסה (Deploy)	הרצת wrangler dev --remote כדי לוודא שכל ה-bindings (קישורים לשירותי הענן) והשירותים האמיתיים מתנהגים כמצופה בענן, ולא רק בסימולציה המקומית של המחשב שלכם.
      בסיום פיתוח פיצ'ר	הרצת wrangler tail ובדיקת הלוגים בזמן אמת כדי לוודא שאין חריגה ממגבלת ה-10ms CPU (זמן עיבוד המעבד) ושאין שגיאות נסתרות ב-Subrequests (בקשות משנה).
      פעם בשבוע	כניסה ל-Cloudflare Dashboard ובדיקת ה-Metrics (מדדים) של ה-Storage. מעקב אחרי קריאות D1, כתיבות KV וצריכת זיכרון של Durable Objects כדי לזהות חריגות תקציב מוקדם ככל הניתן.
      לפני מעבר ל-Production	העברת כל מפתחות ה-API, הסיסמאות והטוקנים משרת הפיתוח למערכת הניהול המאובטחת של Cloudflare בעזרת wrangler secret put.

      דבר אחד שכדאי לעשות עכשיו

      הפעולה היחידה בעלת המינוף הגבוה ביותר למניעת קריסת האפליקציה שלכם תחת עומס היא ייעול שאילתות ה-D1 (בסיס הנתונים שלכם). פתחו את קוד ה-Worker שלכם וודאו שאין בו אף שאילתת SELECT ללא מגבלת LIMIT או תנאי WHERE מוגדר היטב. הוספת אינדקס (Index - מפתח ייחוס לחיפוש מהיר) פשוט על עמודות חיפוש נפוצות תציל אתכם מלהגיע למגבלת ה-5 מיליון שורות שנקראו (Read Rows) בתוך יום אחד.

      בדוק את עצמך — 5 שאלות

      1. מדוע Worker יכול לבצע קריאת fetch חיצונית שלוקחת 2 שניות, ועדיין לא לחרוג ממגבלת ה-10ms CPU של המסלול החינמי? (רמז: חשבו על ההבדל בין זמן ביצוע מעבד - CPU Execution Time, לבין זמן המתנה אסינכרוני - Wait Time שבו ה-Isolate פנוי לעבודות אחרות).
      2. אפליקציית הצ'אט שלכם משתמשת ב-KV כדי לשמור הודעות חדשות של משתמשים (כתיבה בכל הודעה). למה זו החלטה ארכיטקטונית שתגרום לחסימת האפליקציה במהירות? (רמז: זכרו את מגבלת ה-1,000 פעולות כתיבה ביום במסלול החינמי של KV לעומת העלות שלו).
      3. הרצתם שאילתת SELECT * FROM users WHERE active = 1 על טבלת D1 המכילה 50,000 שורות, והחזרתם רק 10 שורות. כמה שורות נקראו (Rows Read) בפועל מבחינת מכסת החיוב של Cloudflare? (רמז: ללא אינדקס מוגדר על עמודת active, בסיס הנתונים נאלץ לבצע סריקה מלאה - Full Table Scan).
      4. מהו רכיב ה-Storage היחיד ב-Cloudflare Workers שמאפשר עקביות חזקה בזמן אמת (Strong Consistency) ומונע מצב שבו שתי בקשות ממקומות שונים בעולם מעדכנות את אותו משתנה בו-זמנית? (רמז: חפשו את הרכיב שמנתב את כל הבקשות לכתובת גלובלית יחידה ומריץ תהליך חד-חוטי - Single-threaded).
      5. מדוע פיתוח ובדיקות מקומיות בלבד באמצעות הסימולטור המקומי (Miniflare) עלולים להטעות אתכם רגע לפני העלייה לאוויר? (רמז: חשבו על הבדלים בגישה ל-Secrets אמיתיים, זמני תגובה גלובליים, והתנהגות של Eventual Consistency ב-KV בענן לעומת המחשב האישי).

      סיכום הפרק

      בפרק זה העמקנו אל מאחורי הקלעים של מודל ה-Isolate של Cloudflare Workers, והבנו כיצד ארכיטקטורה ללא שרת (Serverless) המסוגלת לפעול בתוך פחות ממילישנייה אחת, משנה את כללי המשחק של מהירות האפליקציה. למדנו לתמרן בין מגבלת ה-10ms CPU הקשוחה לבין ביצוע Subrequests חכמים במקביל (Promise.all), וראינו כיצד לבנות ארכיטקטורת נתונים נכונה באמצעות כלי האחסון השונים של Cloudflare.

      ניתחנו את ההבדלים הקריטיים בין KV המיועד לקריאות מהירות ואינטנסיביות, D1 המביא את כוחו של ה-SQL היחסתי לקצה, R2 שמבטל את עלויות תעבורת הנתונים (Egress Fees), ו-Durable Objects המאפשרים ניהול מצב (State) מורכב בזמן אמת. בעזרת מחשבון המגבלות שניתחנו וקובץ ה-wrangler.toml המאוחד, יש לכם כעת תבנית עבודה מלאה לבניית אפליקציות חסינות שברור לכם בדיוק מתי הן ידרשו מעבר למסלול בתשלום.

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

      צ'קליסט — סיכום

      • הבנתי את מודל ה-Isolate והסיבות לכך שאין בו Cold Starts (אתחול קר) או גישה ישירה למערכת הקבצים המקומית.
      • הגדרתי את קובץ ה-wrangler.toml עם 4 bindings פעילים עבור KV, D1, R2 ו-Durable Objects.
      • הגבלתי את זמן עיבוד ה-CPU של ה-Worker על ידי הימנעות מלולאות ארוכות ועיבודי regex כבדים ללא צורך.
      • החלפתי קריאות שרשרת (Cascade Fetch) בקריאות מקביליות באמצעות Promise.all כדי למנוע חריגה ממכסת ה-Subrequests.
      • יצרתי Namespace של KV והגדרתי אותו כראוי לשימוש עבור נתונים בעלי קצב קריאה גבוה וכתיבה נמוכה (Read-heavy).
      • הקמתי בסיס נתונים D1 ב-Cloudflare וקישרתי אותו ל-Worker שלי לצורך שאילתות SQL יחסיות בקצה.
      • הוספתי אינדקסים (Indexes) לעמודות החיפוש ב-D1 כדי למנוע סריקות טבלה מלאות (Full-table scans) שמבזבזות את מכסת ה-Rows Read.
      • הגדרתי Bucket (מאגר) של R2 לאחסון קבצים ומדיה גדולים כדי ליהנות מאפס עלויות Egress (תעבורה יוצאת).
      • מימשתי Durable Object עבור רכיב הדורש סנכרון בזמן אמת ועקביות נתונים חזקה (Strong Consistency).
      • העברתי את כל מפתחות ה-API והסודות הרגישים של האפליקציה למערכת ה-Secrets המאובטחת באמצעות wrangler secret put.
      • בדקתי את הקוד בענן האמיתי באמצעות פקודת wrangler dev --remote כדי לוודא שאין פערים מול הסימולציה המקומית.
      • הרצתי wrangler tail כדי לנטר את השרת בזמן אמת ולאתר שגיאות חריגה של 10ms CPU במהלך השימוש באפליקציה.

      תרגיל מעשי: הקמת ה-KV הראשון שלכם ב-Cloudflare Workers 15 דקות

      בתרגיל זה נקים סביבת פיתוח מקומית של Cloudflare Workers, נחבר אותה למסד נתונים מסוג KV (מפתח-ערך המותאם לקריאה מהירה במיוחד), נכתוב קוד שקורא וכותב אליו, ונריץ בדיקה מקומית.

      1. התקנת הכלים והתחברות לחשבון Cloudflare:

         פתחו את הטרמינל (Terminal) והריצו את פקודת ההתקנה וההתחברות. אם אין לכם חשבון Cloudflare עדיין, הפקודה תנחה אתכם לפתוח אחד בחינם.

         npx wrangler login

         הפלט הצפוי: דפדפן ייפתח ויבקש מכם לאשר את החיבור לחשבון שלכם. לאחר האישור, בטרמינל תופיע ההודעה: Successfully logged in to Cloudflare CLI!

      2. יצירת פרויקט Worker חדש:

         נשתמש בכלי ה-CLI של Cloudflare שנקרא Wrangler כדי לייצר פרויקט חדש בשם vibe-kv-store:

         npm create cloudflare@latest vibe-kv-store -- --framework=none --type=common --js

         במהלך ההתקנה תשאלו האם להשתמש ב-Git (בחרו Yes) והאם לעשות Deployment (בחרו No, נעשה זאת בהמשך).

         הפלט הצפוי: תיקייה חדשה תיווצר עם קבצי הבסיס של ה-Worker, ובטרמינל תופיע ההודעה: Success: Created project vibe-kv-store.

      3. כניסה לתיקיית הפרויקט ויצירת בסיס הנתונים (KV Namespace) המקומי:

         נעבור לתיקייה שיצרנו ונריץ פקודה ליצירת מרחב שמות (Namespace) עבור ה-KV שלנו:

         cd vibe-kv-store
         npx wrangler kv:namespace create MY_KV

         הפלט הצפוי: הפלט יציג קוד קונפיגורציה שצריך להוסיף לקובץ ההגדרות שלכם, הדומה לזה:

         [[kv_namespaces]]
         binding = "MY_KV"
         id = "xxxx_your_kv_id_xxxx"

      4. עדכון קובץ ההגדרות wranger.json:

         פתחו את הקובץ wrangler.json (או wrangler.toml אם נוצר) בתיקיית השורש של הפרויקט, והחליפו את תוכנו בקוד הבא כדי לחבר את ה-Worker ל-KV שיצרנו:

         {
           "name": "vibe-kv-store",
           "main": "src/index.js",
           "compatibility_date": "2024-01-01",
           "kv_namespaces": [
             {
               "binding": "MY_KV",
               "id": "LOCAL_DEV_ID"
             }
           ]
         }

         הפלט הצפוי: שמירת הקובץ תגדיר ל-Worker שקיים לו משתנה גלובלי (Binding) בשם MY_KV שדרכו ניתן לפנות ל-Storage.

      5. כתיבת קוד ה-Worker (קריאה וכתיבה מ-KV):

         פתחו את הקובץ src/index.js והחליפו את כל תוכנו בקוד הבא. הקוד בודק אם קיים מפתח בשם visits ב-KV. אם לא, הוא מייצר אותו עם ערך 1. אם כן, הוא מעלה את הערך ב-1 ומחזיר את התוצאה למשתמש:

         export default {
           async fetch(request, env, ctx) {
             // קריאת הערך הנוכחי מה-KV באמצעות ה-Binding שהגדרנו
             let visits = await env.MY_KV.get("visits");
             
             if (visits === null) {
               visits = 1;
             } else {
               visits = parseInt(visits) + 1;
             }
             
             // שמירת הערך המעודכן בחזרה ל-KV
             await env.MY_KV.put("visits", visits.toString());
             
             return new Response(`שלום Vibe Coder! ביקרת כאן ${visits} פעמים.`, {
               headers: { "content-type": "text/plain; charset=utf-8" },
             });
           },
         };

      6. הרצת שרת הפיתוח המקומי ובדיקה:

         נריץ את ה-Worker במצב פיתוח מקומי (Local Development Mode) המדמה את סביבת הענן של Cloudflare:

         npx wrangler dev

         הפלט הצפוי: הטרמינל יציג הודעה שהשרת רץ בכתובת המקומית: http://localhost:8787. לחצו על הקישור או פתחו אותו בדפדפן. ברענון הראשון תראו את ההודעה "שלום Vibe Coder! ביקרת כאן 1 פעמים.". בכל רענון נוסף (F5), מספר הביקורים יעלה בזמן אמת מתחת ל-10ms בזכות השימוש ב-KV המקומי!

      פלט נראה לעין שתסיים איתו: דפדפן פתוח בכתובת http://localhost:8787 המציג את הטקסט הדינמי המבוסס על הנתונים שנשמרו ב-KV שלכם: "שלום Vibe Coder! ביקרת כאן 5 פעמים." לאחר 5 רענונים של העמוד.

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

      למה זה מפתה: שירות Cloudflare KV (שירות אחסון מפתח-ערך מהיר במיוחד - Key-Value Store) נראה כמו הדרך הכי קלה וזולה לשמור מידע של האפליקציה שלכם. קל פשוט לזרוק לשם אובייקטים גדולים של JSON, וכשצריך לחפש או לסנן נתונים, פשוט למשוך את הכל לתוך ה-Worker ולתת לקוד JavaScript (שג'נרטור ה-AI כתב לכם בשניות) לבצע לופים וסינונים בזיכרון.

      למה זה טעות: הגישה הזו תתנגש במהירות ב"קיר ה-10ms" — מגבלת זמן ה-CPU (זמן מעבד פעיל, לא כולל המתנה לרשת) הנוקשה של Cloudflare Workers במסלול החינמי. עיבוד נתונים, סינון מערכים גדולים או פענוח JSON כבד בתוך קוד ה-Worker ישרפו את ה-10ms הללו ברגע, ויגרמו ל-Worker שלכם לקרוס עם שגיאת מערכת (Error 1102). בנוסף, ל-KV יש תכונה שנקראת Eventual Consistency (עקביות בסופו של דבר), מה שאומר ששינוי שכתבתם לא יופיע מיד בכל השרתים בעולם, ומשתמשים עלולים לקבל מידע ישן ולא מעודכן.

      מה לעשות במקום: התאימו את כלי האחסון לסוג המשימה. אם אתם צריכים לבצע שאילתות, סינונים וחיפושים, השתמשו ב-D1 (מסד הנתונים היחסי מבוסס SQL של Cloudflare) — הוא יבצע את הסינון בצד השרת ויחזיר ל-Worker רק את השורות המדויקות, בלי לבזבז זמן CPU יקר. השתמשו ב-KV אך ורק לנתונים סטטיים יחסית שנקראים המון ונכתבים לעיתים רחוקות מאוד (כמו הגדרות מערכת או תרגומי שפות).