יסודות פיתוח ווב - איך תוכנות מדברות אחת עם השנייה?

כשבונים עם קלוד קוד או כלי AI, הם כותבים קוד אמיתי.

יש הבדל בין לבקש “תבנה לי אפליקציה” לבין להבין מה בנית. בלי היסודות - קשה לדעת מה לבקש ולגרום לזה לעבוד.

במאמר הזה:

• ממשקי תקשורת (CLI vs GUI)
• ארכיטקטורת client-server
• פרוטוקולי תקשורת (HTTP vs WebSocket)
• סביבות הרצה (runtime)
• ארגון קוד (module systems)

CLI vs GUI - שתי דרכים לדבר עם המחשב

קודם הבסיס של הבסיס - המחשב יודע לקבל פקודות בשתי דרכים: דרך GUI (ממשק גרפי) ודרך CLI (שורת הפקודה).

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

למשל mkdir project כדי ליצור תיקייה חדשה במקום לנווט בתפריטים, או cp להעתקת קובץ במקום קליק ימני והדבק.

קלוד קוד הוא תוכנת CLI - מדברים איתו דרך הטרמינל. עוד דוגמאות לתוכנות CLI: עיבוד וידאו עם ffmpeg, הורדת חבילות עם npm/bun, וניהול גרסאות קוד עם git.

מה הופך תוכנה ל-CLI? שמפעילים אותה עם טקסט בטרמינל.

דוגמה מפרויקט שלי

בניתי CLI ו-GUI שמדברים עם אותו data עם web UI משותף. שניהם עובדים על אותם נתונים ומסונכרנים ב-WebSocket.

איך האפליקציה עובדת - השרת

לכל אפליקציה צריך שרת - תוכנה שמקשיבה לבקשות ומגיבה. הדפדפן (client) שולח בקשה לשרת, ה-CLI (client) שולח בקשה לשרת, והשרת מקשיב, מעבד, ומחזיר.

לשרת של האפליקציה יש שני פרוטוקולים:

פרוטוקול HTTP - תקשורת לבקשה-תשובה. השרת מאזין לבקשות בפורט ומחזיר תשובות. פורט זה כמו מספר דירה - המחשב יכול להריץ כמה שרתים במקביל, כל אחד מקשיב בפורט אחר.

פרוטוקול WebSocket - תקשורת לעדכונים בזמן אמת.

מה השרת עושה?

שרת HTTP מגיש לדפדפן שני דברים: קבצים סטטיים (תמונות, CSS, HTML) ובקשות דינמיות דרך API - דרך מובנית לתקשורת בין תוכנות.

למשל API באפליקציית ניהול משימות:

• GET /tasks - מחזיר רשימת משימות
• POST /tasks - יוצר משימה חדשה
• DELETE /tasks/5 - מוחק משימה

מה זה WebSocket?

פרוטוקול HTTP עובד כמו מכתבים: שולחים בקשה, מקבלים תשובה, הקשר נסגר. אם אני רוצה לדעת מה השתנה אני צריכה כל הזמן לשאול “יש חדש? יש חדש?” - זה נקרא polling וזה לא יעיל.

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

השרת יכול להגיד “מישהו הוסיף משימה!” ברגע שזה קורה, בלי שהדפדפן ישאל. כל הקליינטים של השרת מקבלים עדכון בו זמנית - זה נקרא broadcast.

שרת אחד, שני פרוטוקולים

ה-WebSocket ו-HTTP משלימים אחד את השני: API לפעולות (להוסיף משימות) ו-WebSocket לעדכונים (להציג את השינוי בממשק).

איך השרת מופעל? פקודת server ב-CLI שמרימה אותו - מתחיל HTTP server לדבר עם API וקבצים, מתחיל WebSocket לסנכרון, ומנגיש את הממשק הגרפי.

איך קבצים מדברים ביניהם - Module System

כשיש הרבה קבצים בתוכנה צריך לייצא ולייבא קוד ביניהם. לא משנה אם זה אתר, CLI או שרת - כל פעם שיש יותר מקובץ אחד וצריך לייבא פונקציה זה module system.

CommonJS - השיטה הישנה של Node.js.

ESM (ECMAScript Modules) - התקן החדש והרשמי של JavaScript.

קוד משותף בין frontend ל-backend עדיף ב-ESM כי זה הסטנדרט שעובד בכל מקום.

איפה מריצים את הקוד - Runtime

מישהו צריך לקרוא ולבצע את הקוד - Runtime זאת התוכנה שעושה את זה.

צד שרת (backend) - הקוד שרץ על השרת המרוחק. למשל Node.js ו-Bun הם runtime של JS בצד שרת.

צד לקוח (frontend) - הקוד שרץ אצל המשתמש, מה שהוא רואה ולוחץ. הדפדפן הוא runtime של JS בצד לקוח.

איך זה מתבטא ב-CLI שבניתי

הטרמינל - client (שולח פקודות). ה-Web UI - client (בדפדפן). השרת - server (מקבל, מעבד, משדר לכולם).

יש לי שני clients של אותו שרת, לכן הם מסונכרנים.

בלי קשר לפיתוח, לשימוש ב-CLI יש יתרונות בפני עצמו: מהירות, שליטה, עבודה עם סוכני AI ועוד - שווה להתנסות.