Server side

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

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

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

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

ניתן לממש ולהחליף את השכבות בכל מיני מימושים כרצוננו.

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

1. שולחים בקשת DNS לשרת DNS שזה בעצם פרוטוקול שמקבל URL וממיר אותו לכתובת IP תקינה.
   זה גם פרוטוקול שמשתמש במודל 5 השכבות כדי להעביר מידע ברמות השנות
   
2. ברגע שיש IP נשלח בקשת HTTP לשרת הweb שהוא שרת HTTP (כמו שיש שרת DNS שיודע לטפל בבקשות של הפרוטוקול DNS יש גם שרת HTTP שיודע לטפל בבקשות HTTP).
3. בקשת הHTTP מסוג GET עוברת בשכבות השונות עד שמגיעה לשרת (למשל בשכבת ה Transport נעשה חיבור לשרת באמצעות פרוטוקול TCP ואז המידע נשלח לשכבת הרשת).
4. ברגע שהיא מגיעה לשרת היא מעובדת ומחזירה HTTP Response שמכיל בתוכו את הקובץ HTML המתאים לרינדור.
5. הדפדפן מקבל את התוצאה ומרנדר אותה על המסך.

בקשת GET נראת ככה לרוב

ובאופן כללי יותר התקשורת (בשכבת האפליקצייה) נראת ככה

HTTP

הודעות HTTP הן האופן שבו נתונים מוחלפים בין שרת ללקוח. ישנם שני סוגים של הודעות: בקשות שנשלחו על ידי הלקוח להפעלת פעולה בשרת, ותגובות, התשובה מהשרת.

הודעות HTTP מורכבות ממידע טקסטואלי המקודד ב-ASCII, ומתפרשות על פני מספר שורות. ב-HTTP/1.1 ובגירסאות קודמות של הפרוטוקול, הודעות אלו נשלחו בגלוי דרך החיבור. ב-HTTP/2, ההודעה שפעם הייתה ניתנת לקריאה אנושית מחולקת כעת למסגרות HTTP, מה שמספק אופטימיזציה ושיפורי ביצועים.

בקשות ותשובות בHTTP חולקים מבנה דומה ומורכבים מ

1. שורת התחלה שמתארת את הבקשה או את סטטוס הבקשה.
2. סט אופציונלי של headers שמתארים את הבקשה או התגובה החוזרת
3. body אופציונלי שמכיל מידע שמשוייך לבקשה או לתשובה.

HTTP Request

Start line

בקשות HTTP הן הודעות שנשלחות על ידי הלקוח כדי ליזום פעולה בשרת. קו ההתחלה שלהם מכיל שלושה אלמנטים:
HTTP method
מתאר איזה פעולה הבקשה רוצה לעשות:
GET- מבקשת לקבל משאב מסויים.
HEAD- מבקשת את אותה תגובה כמו בקשת ה GET רק בלי ה body.
POST- שליחה של יישות עבור משאב מסויים במערכת, לעתים זאת משנה את ה state שלו או משפיעה על השרת.
DELETE- מחיקה של משאב מסויים.
PUT-החלפה של משאב מסויים בתוכן הבקשה.
PATCH- ביצוע מודיפיקציה של משאב בשרת.

Request target
בדרך כלל זה URL או נתיב אבסולוטי שמכיל בתוכו queries, פורט וכו׳.
בעצם זה יכול להיות כל נתיב שהוא בעצם מורכב מהמבנה המלא של URL

HTTP version
הגרסה קובעת את המבנה של שאר ההודעה וגם כדי לדעת כיצד לבנות את התגובה.

Headers

כותרות HTTP מייצרות בקשה תחת אותו מבנה בסיסי של Header HTTP: מחרוזת לא תלוית רישיות ואחריה נקודתיים (':') וערך שהמבנה שלו תלוי בHeader. הכותרת כולה, כולל הערך, מורכבת משורה אחת בודדת, שיכולה להיות ארוכה למדי.

זה סוג של metadata על הבקשה.

Body

החלק האחרון של הבקשה הוא הגוף שלה. לא לכל הבקשות יש אחת: בקשות שמביאות משאבים, כמו GET, HEAD, DELETE או OPTIONS, בדרך כלל אינן זקוקות למשאבים כאלה. חלק מהבקשות שולחות נתונים לשרת על מנת לעדכן אותם: כפי שקורה לעתים קרובות בבקשות POST (המכילות נתוני טופס HTML).

HTTP Response

כפי שאמרנו המבנה הוא דומה לRequest.

Status line
שורת ההתחלה של תגובת HTTP, הנקראת שורת המצב, מכילה את המידע הבא:

1. גרסה של הפרוטוקול, בד״כ HTTP/1.1
2. סטטוס קוד שמעיד על הצלחה או כשלון. ישנן קונבנציות הקשורות לקודים האלה למשל $200-299$ מייצג הצלחה $400-499$ מייצג שגיאה הקשורה בצד client.
   $500-599$ זה שגיאה בצד שרת.

Headers
מבנה זהה לחלוטין של headers בבקשת http. ההבדל היחיד הוא בקונטקסט שיש לheaders האלה כלומר מה המשמעות שלהם.

Body
באופן דומה ל HTTP Request. מכילות מידע החוזר מבקשה. הרבה פעמים אנחנו נראה את זה בבקשות מסוג GET.

GET vs POST

ההבדל העיקר הוא שהמידע מועבר ב URL עצמו בבקשות GET דרך ה query , בעוד שבPOST המידע עובר ב body.

HTTP Server

שרת HTTP (Hypertext Transfer Protocol) הוא יישום תוכנה המשרת דפי אינטרנט או משאבים אחרים ללקוחות לפי בקשתם. הוא מקבל בקשות מדפדפני אינטרנט או לקוחות אחרים ומגיב עם התוכן המבוקש, שיכול להיות בצורה של דפי HTML, תמונות, סרטונים, קבצים או משאבים אחרים. שרת ה-HTTP מאזין לבקשות נכנסות ביציאה ספציפית (בדרך כלל יציאה 80 עבור HTTP או יציאה 443 עבור HTTPS) ומקבל חיבורים מלקוחות. כאשר לקוח מגיש בקשה למשאב מסוים (כגון דף אינטרנט), השרת מעבד את הבקשה, מאתר את המשאב המבוקש ושולח אותו בחזרה ללקוח כתגובת HTTP. שרתי HTTP הם מרכיב בסיסי של ה-World Wide Web ואחראים על אספקת תוכן אינטרנט למשתמשים. דוגמאות לתוכנות שרת HTTP פופולריות כוללות Apache HTTP Server, Microsoft IIS (Internet Information Services) ו-Node.js. על חלקם נדבר בהמשך.

שרת שכזה הוא מקרה פרטי של Web Server.
שרת אינטרנט הוא יישום תוכנה או תוכנית המשמשת כעמוד השדרה של ה-World Wide Web ומאפשרת ללקוחות (כגון דפדפני אינטרנט) לגשת ולאחזר תוכן אינטרנט דרך האינטרנט. הוא מטפל בבקשות HTTP מלקוחות ומגיב עם דפי האינטרנט, הקבצים או הנתונים המבוקשים.

Standalone Http Server

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

בפייתון אפשר להרים בקלות שרת http עצמאי

# File: simple_http_server.py
import http.server
import socketserver

PORT = 8000

Handler = http.server.SimpleHTTPRequestHandler

with socketserver.TCPServer(("", PORT), Handler) as httpd:
    print("Serving at port", PORT)
    httpd.serve_forever()

זה שרת בסיסי שמטפל בבקשות get ומביא קבצים מהcurrent directory.

Apache Tomcat

טכנולוגיית open-source web server שמשמשת כ container עבור servlet.
מתייחסים אליה כ standalone HTTP server
לפעמים כי היא מגיעה עם HTTP connector שיכול לטפל בבקשות HTTP בלי צורך בשירותים חיצוניים.

Servlet
servlet הוא רכיב מבוסס Java המשמש להרחבת הפונקציונליות של שרת אינטרנט ויצירת תוכן דינמי עבור יישומי אינטרנט. זוהי טכנולוגיה בצד השרת שמעבדת בקשות HTTP ומייצרת תגובות שניתן לשלוח בחזרה ללקוחות, בדרך כלל לדפדפני אינטרנט. Servlets הם חלק חיוני מפלטפורמת Java, Enterprise Edition (Java EE) לבניית יישומי אינטרנט.

אם כן אז ה flow של standalone server בארכיטקטורה שראינו היא ש

1. השרת HTTP של Apache Tomcat מקבל בקשות HTTP ויודע להפעיל את הפונקציות הרלוונטיות ל ServletCat בהתאם לסוג הבקשה וגם להעביר את המידע הדרוש.
2. Servlet יודעת בהתאם לבקשה להחזיר את התוכן הדרוש ללקוח, זה יכול להיות דפי HTML סטטיים, זה יכול JSON ועוד.

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

public abstract class HttpServlet extends GenericServlet {
	// ...
 protected void doGet(HttpServletRequest req, HttpServletResponse resp);
 
 protected void doPost(HttpServletRequest req, HttpServletResponse resp);
 //...
}

php

אפשר לעשות את אותו דבר עם טכנולוגיה אחרת – php.
php היא שפת סקריפט שתרוץ בצד שרת ושניתן להשתמש בה כדי לקבוע מה יהיה התוכן שחוזר מבקשת אינטרנט.
השרת HTTP יוכל במקום להשתמש ב Servlet.
להחזיר php interpreter ובהתאם לבקשות המגיעות להריץ את הסקיפט php המתאים.
נשים לב שהיא מתוכננת כדי להחזיר HTML.

Embedded server

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

נתבונן בתרשים המדגים ארכיטקטורת שרת שהוא embedded

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

1. יהיה לנו קוד שרת שיודע לקבל בקשות HTTP.
2. יהיה לנו חלק בקוד שיודע לעבד את הבקשה (נתמקד בחלק הזה שזה בידיוק מה ש NodeJS ביחד עם express יתנו לנו)
3. בהתאם לבקשה נוכל לפנות לרכיבים אחרים בשרת לבצע לוגיקות כאלה ואחרות ובהתאם לצורך לרנדר UI.
4. רק לאחר ביצוע כל הדברים הללו נשלח את הלוגיקה בחזרה ללקוח.

NodeJS

Node.js היא סביבת runtime ל javascript שמבוססת על מנוע V8.

אפליקציית Node.js פועלת בתהליך בודד, מבלי ליצור thread חדש לכל בקשה. Node.js מספק קבוצה של פרימיטיבים אסינכרוניים של קלט/פלט בספרייה הסטנדרטית שלו שמונעים מקוד JavaScript לחסום ובאופן כללי, ספריות ב-Node.js נכתבות באמצעות פרדיגמות לא חוסמות, מה שהופך את התנהגות החסימה לחריג ולא לנורמה.

כאשר Node.js מבצע פעולת I/O, כמו קריאה מהרשת, גישה למסד נתונים או למערכת הקבצים, במקום לחסום את הthread ולבזבז מחזורי CPU בהמתנה, Node.js יחדש את הפעולות כאשר התגובה תחזור.
העובדה הזאת מאפשרת ל Nodejs לנהל אלפי חיבורים בשרת יחיד בלי צורך כלל בניהול threads.

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

const http = require('http');

const hostname = '127.0.0.1';
const port = 3000;

const server = http.createServer((req, res) => {
  res.statusCode = 200;
  res.setHeader('Content-Type', 'text/plain');
  res.end('Hello World\n');
});

server.listen(port, hostname, () => {
  console.log(`Server running at http://${hostname}:${port}/`);
});

יצרנו כאן שרת פשוט שכאשר נוצר השרת הוא פשוט מחזיר status code:200 ואת המחרוזת Hello World.

הרעיון הכללי הוא שנוכל להרים שרת HTTP שבעת קבלת בקשה הוא המידע מעובד על ידי הServer code ומוזרק בשתי הפרמטרים request,response לאחר מכן, ניתן לבדוק את אופי הבקשי לפי המידע הנמצא בפרמטרים האלו ולבצע התנהגות בהתאם.

const http = require("http")

function handleRequest(request,response) {
	if (request.url == '/foo') {
 response.write('<html><body><b>foo</b></body></html>')
 }
 else if(request.url == '/bar') {
  response.write('<html><body><u>bar</u></body> </html>')
 }
 else 
	 response.statusCode = 404
response.end()
}

 const server = http.createServer(handleRequest)
 server.listen(80)

כאן כבר ראינו דוגמה יותר מעניינת שבודקת את הurl. באותה מידה יכלנו לכתוב json, ויכלנו גם לבצע בדיקות על מידע אחר מהבקשה.

Express

זה framework שכתוב ב-JavaScript ומתארח בסביבת זמן הריצה של Node.js.
הוא מייצר ממשק שיותר נוח לעבודה , בקוד nodejs מקודם, עלינו היה לפרסר את הurl ולראות מי שלח את הבקשה כדי לדעת מה להחזיר

const express = require('express')
const app = express()
const port = 12345

app.get('/', (req, res) => {
	res.send('<html><body><h1>Hello World!</h1></body></html>')
})

ניתן לראות כאן שבניגוד לקוד NodeJS טהור יש לנו API יותר סוכרי מבחינתי הסינתקס. במקום שנצטרך לפרסר את ה (request,respone) ולהבין מהי הבקשה ובהתאם לכך לבצע קוד, נוכל להצמיד handler לendPoint ספציפי (לדוגמה יכולנו לבנות גם handler עבור הסיומת $/bar$ ) מה שייצור קוד יותר נוח ויאפשר שימוש בתבניות עיצוב מורכבות יותר שנדבר עליהם כמו MVC שנדבר עליו בהמשך.

תקשורת סינכרונית ותקשורת אסינכרונית

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

סינכרוני

הדפדפן קיבל תשובה מהשרת (את כל עמוד הhtml, למרות שלא צריך את כולו) כתוצאה מכך הדפדפן מרפרש את העמוד בשביל לטעון את המידע.

אסינכרוני

הדפדפן מקבל תשובה מהשרת (רק את המידע הנצרך) כתוצאה מכך הדפדפן טוען את המידע לעמוד בלי לעשות ריפרש.
ניתן לעשות זאת על ידי העברה של JSON שמייצג את המידע שהקומפוננטות בReact ישתמשו בהן כדי לעדכן את המידע.

Web Service

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

Web Server ו Web Services הם שתי רכיבים שיכולים להזין את ה client שלנו במידע ובממשק משתמש שמתעדכן בצורה דינמית. בעוד ש Web Server הוא לרוב מוגדר באמצעות פרוטוקול HTTP, שירותי רשת צריכים להגדיר API או חוזה כלשהו כדי לאפשר את תקשורת המידע בינהם.

RPC

Remote Procedure Call Web Service
היא טכנולוגיה לתקשורת בין יישומים המאפשרת לתוכנית מחשב אחת להפעיל פונקצייה בתוכנית מחשב אחרת באופן שקוף, כלומר ללא צורך ביישום פרטני של פרוטוקול התקשורת.

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

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

אחד המימושים המוכרים הוא gRPC שמגדיר protocol buffers והstubs מיוצרים על ידי המפתחים שלהם בהתאם למה שכתוב בprotocol buffers.

WSDL

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

מרכיבי המפתח של מסמך WSDL כוללים:

type: הסעיף "סוגים" מגדיר את סוגי הנתונים המשמשים את שירות האינטרנט, בדרך כלל באמצעות XML Schema Definition (XSD) כדי לציין את המבנה והאילוצים של פרמטרי הקלט והפלט.

message: הסעיף "הודעה" מגדיר את סוגי הנתונים המופשטים עבור הודעות קלט ופלט שהוחלפו בין הלקוח לשירות האינטרנט. הוא מתאר את מבנה הנתונים המועברים.

PortType: הסעיף "PortType" מגדיר את הממשק המופשט של שירות האינטרנט, ומפרט את הפעולות בהן שירות האינטרנט תומך ואת הודעות הקלט והפלט עבור כל פעולה.

Binding: הסעיף "binding" מפרט את הפרטים הקונקרטיים של האופן שבו פעולות שירות האינטרנט קשורות לפרוטוקול תקשורת או פורמט הודעה ספציפיים. הוא מגדיר את פורמט ההודעות ואת אופן החלפת ההודעות.

Service: הקטע "service" מספק את המידע על נקודות הקצה שבהן ניתן לגשת לשירות האינטרנט. הוא מתאר את מיקום הרשת (URL) של שירות האינטרנט ואת הפרוטוקול המשמש לתקשורת איתו.

<definitions xmlns="http://schemas.xmlsoap.org/wsdl/"
             xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
             targetNamespace="http://example.com/calculator"
             xmlns:tns="http://example.com/calculator">

    <!-- Types: Define the data types used by the web service -->
    <types>
        <schema targetNamespace="http://example.com/calculator"
                xmlns="http://www.w3.org/2001/XMLSchema">
            <element name="AddRequest">
                <complexType>
                    <sequence>
                        <element name="num1" type="int"/>
                        <element name="num2" type="int"/>
                    </sequence>
                </complexType>
            </element>

            <element name="AddResponse">
                <complexType>
                    <sequence>
                        <element name="result" type="int"/>
                    </sequence>
                </complexType>
            </element>

            <element name="SubtractRequest">
                <complexType>
                    <sequence>
                        <element name="num1" type="int"/>
                        <element name="num2" type="int"/>
                    </sequence>
                </complexType>
            </element>

            <element name="SubtractResponse">
                <complexType>
                    <sequence>
                        <element name="result" type="int"/>
                    </sequence>
                </complexType>
            </element>
        </schema>
    </types>

    <!-- Message: Define the abstract data types for input and output messages -->
    <message name="AddInput">
        <part name="parameters" element="tns:AddRequest"/>
    </message>

    <message name="AddOutput">
        <part name="parameters" element="tns:AddResponse"/>
    </message>

    <message name="SubtractInput">

WSDL משויך לתקני שירותי אינטרנט כמו SOAP (Simple Object Access Protocol) ומאפשר ללקוחות לתקשר עם שירותי אינטרנט באמצעות הודעות SOAP. עם זאת, עם הפופולריות של שירותי אינטרנט של RESTful המשתמשים ב-HTTP ו-JSON, WSDL נמצא פחות בשימוש בארכיטקטורות מודרניות של שירותי אינטרנט של RESTful, שכן ממשקי API של RESTful הם בדרך כלל תיאוריים עצמיים וניתן לגלות אותם דרך נקודות הקצה של ה-API עצמם באמצעות טכנולוגיות כמו OpenAPI/Swagger או סכימת JSON.

Rest

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

RESTful API (Representational State Transfer API) הוא סגנון ארכיטקטוני לעיצוב יישומים ברשת, במיוחד שירותי אינטרנט, המשתמשים בשיטות HTTP סטנדרטיות (GET, POST, PUT, DELETE) כדי לבצע פעולות CRUD (יצירה, קריאה, עדכון, מחק) על המשאבים השונים. ממשקי API של RESTful בנויים על עקרונות REST, שהיא גישה לבניית שירותי אינטרנט ניתנים להרחבה וstateless

עקרונות מפתח של REST:

1. Stateless: כל בקשה חייבת להכיל את כל המידע הדרוש כדי להבין ולעבד את הבקשה. השרת לא שומר את המידע הרלוונטי עבור בקשה ברגע שהיא נשמרת הוא רק מחזיר תשובה.
2. CRUD: באמצעות פעולות HTTP שדיברנו עליהם נוכל לבצע פעולות CRUD.
3. כל דבר הוא משאב המזוהה על ידי URI, במקרה של REST זה יהיה URL שמחזיק בסכמה שלו את הפרמטרים הדרושים למשיכה.
4. State Codes: שירותי REST משתמשים בסטנדרט של HTTP בשביל להחזיר סטטוס בקשות.

Server to Client Communication

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

Polling

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

AJAX Polling

Asynchronous javascript and XML, בעצם זה המנגנון מאחורי fetch API של JS.
אנחנו מבצעים Polling למידע הדרוש ולא לכל הממשק משתמש כך שאנחנו עדיין נשארים עם מרבית החסרונות של עקרון הpolling.

Long Polling

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

Streaming

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

WebSockets

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

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

Socket.IO

Socket.IO היא ספריית JavaScript המאפשרת תקשורת דו-כיוונית בזמן אמת בין לקוחות (בדרך כלל דפדפני אינטרנט) ושרתים. הוא מתבסס על פרוטוקול WebSockets אך תומך גם במנגנוני חזרה אחרים כמו long polling ומשתמש ב-API מאוחד המפשט תקשורת בזמן אמת על פני פלטפורמות ודפדפנים שונים.

נסתכל על המימוש הבא :

//backend
 const express = require('express');
 const app = express();
 const http = require('http');
 const server = http.createServer(app);
 const { Server } = require("socket.io");
 const io = new Server(server);

 app.get('/', (req, res) => { res.sendFile(__dirname + '/index.html');
 });

 io.on('connection', (socket) => {
	 io.emit('hello', { foo : 'bar' });
	 socket.broadcast.emit('hi');
	 socket.on('disconnect', () => {
		 console.log('disconnected');
	 });
	 socket.on('foo', (msg) => {
		 console.log('message: ' + msg);
	 });
 });

 server.listen(3000);

בקוד הזה אפשר לראות שיצרנו אובייקט שרת מהשרת http שיצרנו. בעצם הצמדנו לשרת את הapi של socket.io וכעת אפשר להרשם ולשלוח אירועים ללקוח.

//client
 <html>
	<body>
	  <script src="/socket.io/socket.io.js"></script>
	  <script>
		  var socket = io();
		 socket.emit('foo', 'bar');
		 socket.on('hello', function(msg) {
			 console.log(msg);
		 });
    </script>
  </body>
</html>

SocketIO מאפשרת לנו ניהול אירועים ברמה רחבה יותר מסתם שליחה ובקשה, למשל נוכל לרשום לקוחות לאירוע מסויים ורק עבורם להפיץ event מסויים.

io.on("connection", (socket) => {
    console.log(`User Connected: ${socket.id}`);

    socket.on("join_room", (data) => {
        socket.join(data);
        console.log(`User with ID: ${socket.id} joined room: ${data}`);
    });

    socket.on("send_message", (data) => {
        socket.to(data.room).emit("receive_message", data);
    });

    socket.on("create_contact", (data) => {
        socket.broadcast.emit("add_new_contact", data);
    });

    socket.on("disconnect", () => {
        console.log("User Disconnected", socket.id);
    });

    socket.on("delete_contact", (data) => {
        socket.to(data.room).emit("recived_delete", data);
        socket.leave(data.room);
    });
});