Client-Server

למה זה חשוב

כמעט כל אפליקציה מודרנית בנויה על מודל Client-Server. כשאתם גולשים באתר, שולחים הודעה ב-WhatsApp, או מזמינים אוכל באפליקציה -- יש צד שמבקש (Client) וצד שמספק (Server). הבנה של הדינמיקה הזו היא הבסיס לכל עבודה ב-Backend, Frontend, ו-DevOps.

(אם פעם תהיתם למה כל כך קשה לבנות אפליקציית צ'אט -- התשובה מתחילה כאן.)

רעיונות מרכזיים

מה זה Client-Server Architecture?

• Client -- הצד שיוזם בקשה. לרוב זה דפדפן, אפליקציית מובייל, או כל תוכנה שמבקשת מידע.
• Server -- הצד שמקשיב לבקשות, מעבד אותן, ומחזיר תשובה. לרוב זה שרת עם קוד Backend.
• המודל הזה מפריד בין מי שצורך את השירות לבין מי שמספק אותו.

┌──────────┐         Request          ┌──────────┐
│          │  ───────────────────────► │          │
│  Client  │                          │  Server  │
│ (Browser)│  ◄─────────────────────  │ (Backend)│
│          │         Response         │          │
└──────────┘                          └──────────┘

מחזור Request-Response

1. ה-Client שולח Request (בקשה) לשרת -- למשל GET /api/users.
2. השרת מקבל את הבקשה, מעבד אותה (שליפה מ-Database, חישוב לוגיקה, וכו').
3. השרת מחזיר Response (תשובה) עם Status Code ו-Body.
4. ה-Client מקבל את התשובה ומציג אותה למשתמש.

Browser כ-Client, Backend כ-Server

• ה-Browser (דפדפן) הוא ה-Client הנפוץ ביותר. הוא שולח HTTP Requests ומציג את ה-Response למשתמש.
• ה-Backend (למשל שרת Node.js, Django, Spring) הוא ה-Server שמעבד לוגיקה עסקית.
• ה-Backend בדרך כלל מתקשר גם עם Database, ובמקרה הזה ה-Backend הופך ל-Client של ה-Database.

┌──────────┐    HTTP     ┌──────────┐    TCP/SQL    ┌──────────┐
│ Browser  │ ──────────► │ Backend  │ ────────────► │ Database │
│ (Client) │ ◄────────── │ (Server/ │ ◄──────────── │ (Server) │
└──────────┘             │  Client) │               └──────────┘
                         └──────────┘
                              │          TCP/HTTP
                              │ ────────────────────► ┌──────────┐
                              └──────────────────────  │ External │
                                                       │   API    │
                                                       └──────────┘

REST API -- הבסיס

REST (Representational State Transfer) הוא סגנון ארכיטקטורה לבניית API-ים:

• משתמש ב-HTTP Methods: GET, POST, PUT, DELETE
• כל Resource מיוצג ב-URL: /api/users/42
• התקשורת מבוססת על פורמטים סטנדרטיים (לרוב JSON)

GET /api/products/7 HTTP/1.1
Host: example.com
Accept: application/json

{
  "id": 7,
  "name": "Mechanical Keyboard",
  "price": 350
}

עקרונות REST שחשוב להכיר

API Versioning -- כשה-API משתנה

כשמשנים API, לא רוצים לשבור Clients קיימים. יש כמה גישות:

גישה 1: URL Versioning (הכי נפוץ)
────────────────────────────────────
GET /api/v1/users/42
GET /api/v2/users/42    ← שדות חדשים, פורמט שונה

גישה 2: Header Versioning
──────────────────────────
GET /api/users/42
Accept: application/vnd.myapi.v2+json

גישה 3: Query Parameter
────────────────────────
GET /api/users/42?version=2

Stateless vs Stateful

מעבר ל-Request-Response: תבניות תקשורת מתקדמות

WebSockets -- תקשורת דו-כיוונית בזמן אמת

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

WebSocket הוא פרוטוקול שמאפשר חיבור פתוח ורציף בין Client ל-Server:

HTTP Request-Response (רגיל):
─────────────────────────────
Client ──Request──►  Server
Client ◄─Response─── Server
(החיבור נסגר)

Client ──Request──►  Server
Client ◄─Response─── Server
(החיבור נסגר שוב)


WebSocket (חיבור רציף):
───────────────────────
Client ──HTTP Upgrade──► Server     ← Handshake (פעם אחת)
       ◄─── 101 ────────

Client ══════════════════ Server    ← החיבור נשאר פתוח
Client ──Message──►       Server    ← Client שולח מתי שרוצה
Client       ◄──Message── Server    ← Server שולח מתי שרוצה
Client ──Message──►       Server
Client       ◄──Message── Server
       ...

ה-WebSocket Handshake

WebSocket מתחיל כ-HTTP Request רגיל עם בקשת Upgrade:

GET /chat HTTP/1.1
Host: example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

אחרי ה-Handshake, התקשורת עוברת ל-WebSocket Protocol (לא HTTP יותר).

// Client-side (Browser)
const ws = new WebSocket('wss://example.com/chat');

ws.onopen = () => {
    ws.send(JSON.stringify({ type: 'join', room: 'general' }));
};

ws.onmessage = (event) => {
    const data = JSON.parse(event.data);
    console.log('New message:', data);
};

// Server-side (Node.js + ws library)
const WebSocket = require('ws');
const wss = new WebSocket.Server({ port: 8080 });

wss.on('connection', (ws) => {
    ws.on('message', (message) => {
        // Broadcast to all connected clients
        wss.clients.forEach(client => {
            if (client.readyState === WebSocket.OPEN) {
                client.send(message);
            }
        });
    });
});

Server-Sent Events (SSE) -- עדכונים חד-כיווניים מהשרת

לפעמים לא צריך תקשורת דו-כיוונית. צריך רק שהשרת ישלח עדכונים ל-Client -- למשל, Feed של חדשות, התקדמות של Task ארוך, או התראות.

SSE (Server-Sent Events):
──────────────────────────
Client ──GET /events──► Server       ← בקשת HTTP רגילה
Client ◄─ data: {...}── Server       ← Server שולח event
Client ◄─ data: {...}── Server       ← Server שולח עוד event
Client ◄─ data: {...}── Server       ← והחיבור נשאר פתוח

// Server-side (Node.js)
app.get('/events', (req, res) => {
    res.setHeader('Content-Type', 'text/event-stream');
    res.setHeader('Cache-Control', 'no-cache');
    res.setHeader('Connection', 'keep-alive');

    // שולח עדכון כל 5 שניות
    const interval = setInterval(() => {
        const data = { price: Math.random() * 100, time: Date.now() };
        res.write(`data: ${JSON.stringify(data)}\n\n`);
    }, 5000);

    req.on('close', () => clearInterval(interval));
});

// Client-side
const source = new EventSource('/events');
source.onmessage = (event) => {
    console.log('Stock update:', JSON.parse(event.data));
};

Long Polling -- הפתרון ה"ישן" שעדיין רלוונטי

לפני WebSocket ו-SSE, השתמשו ב-Long Polling: ה-Client שולח Request, והשרת לא עונה עד שיש מידע חדש (או שעובר Timeout):

Regular Polling (בזבזני):
─────────────────────────
Client ──"יש חדש?"──► Server
Client ◄── "לא" ────── Server
(שנייה אחרי...)
Client ──"יש חדש?"──► Server
Client ◄── "לא" ────── Server
(שנייה אחרי...)
Client ──"יש חדש?"──► Server
Client ◄── "כן! הנה"── Server

Long Polling (יותר חכם):
────────────────────────
Client ──"תגיד לי כשיש חדש"──► Server
               ... ממתין ...
Client ◄── "הנה מידע חדש!" ─── Server  (אחרי 30 שניות)
Client ──"תגיד לי כשיש חדש"──► Server  (מיד שולח שוב)
               ... ממתין ...

השוואה מלאה: מתי לבחור מה?

┌────────────────────────────────────────────────────────────┐
│                 מדריך בחירת פרוטוקול                        │
├────────────────────────────────────────────────────────────┤
│                                                            │
│  צריך עדכונים בזמן אמת?                                   │
│  ├── לא ──► REST (Request-Response רגיל)                   │
│  └── כן                                                    │
│       ├── דו-כיווני? (שני הצדדים שולחים)                   │
│       │   ├── כן ──► WebSocket                              │
│       │   └── לא ──► SSE (Server-Sent Events)              │
│       └── בסביבה מוגבלת? (Firewall, Proxy ישן)             │
│           └── כן ──► Long Polling                           │
│                                                            │
└────────────────────────────────────────────────────────────┘

gRPC -- תקשורת מהירה בין שירותים

מה זה gRPC?

gRPC (Google Remote Procedure Call) הוא Framework לתקשורת בין שירותים שפותח על ידי Google. במקום לשלוח JSON על HTTP כמו ב-REST, gRPC משתמש ב-Protocol Buffers (פורמט בינארי) ו-HTTP/2.

REST:                           gRPC:
─────                           ─────
JSON (טקסט, כבד)                Protocol Buffers (בינארי, קל)
HTTP/1.1 (בקשה אחת בכל פעם)    HTTP/2 (בקשות מרובות במקביל)
קל ללמוד ולדבג                  ביצועים מעולים
נפוץ ל-Client↔Server           נפוץ ל-Server↔Server

הגדרת Service ב-gRPC

ב-gRPC מגדירים חוזה (Contract) בקובץ .proto:

// user_service.proto
syntax = "proto3";

service UserService {
    // Unary RPC -- כמו REST רגיל
    rpc GetUser (GetUserRequest) returns (User);

    // Server Streaming -- השרת שולח stream של תוצאות
    rpc ListUsers (ListUsersRequest) returns (stream User);

    // Client Streaming -- ה-Client שולח stream
    rpc UploadUsers (stream User) returns (UploadResponse);

    // Bidirectional Streaming -- שני הצדדים ב-stream
    rpc Chat (stream ChatMessage) returns (stream ChatMessage);
}

message GetUserRequest {
    int32 id = 1;
}

message User {
    int32 id = 1;
    string name = 2;
    string email = 3;
}

ארבעת סוגי ה-RPC ב-gRPC

1. Unary (כמו REST):
   Client ──Request──► Server
   Client ◄─Response── Server

2. Server Streaming:
   Client ──Request──► Server
   Client ◄─ data ──── Server
   Client ◄─ data ──── Server
   Client ◄─ data ──── Server

3. Client Streaming:
   Client ── data ───► Server
   Client ── data ───► Server
   Client ── data ───► Server
   Client ◄─Response── Server

4. Bidirectional Streaming:
   Client ══ data ═══► Server
   Client ◄═ data ════ Server
   Client ══ data ═══► Server
   Client ◄═ data ════ Server

REST vs GraphQL vs gRPC -- השוואה מפורטת

Over-Fetching (בעיה של REST):
─────────────────────────────
אתם צריכים רק את שם המשתמש,
אבל GET /api/users/42 מחזיר הכל:
{
    "id": 42,
    "name": "Dana",        ← צריך
    "email": "...",         ← לא צריך
    "address": "...",       ← לא צריך
    "phone": "...",         ← לא צריך
    "preferences": {...}    ← ממש לא צריך
}

GraphQL פותר:
─────────────
query {
    user(id: 42) {
        name              ← מקבלים רק מה שביקשנו
    }
}

Microservices Communication Patterns

Synchronous vs Asynchronous Communication

Synchronous (סינכרוני):
───────────────────────
Service A ──Request──► Service B
Service A ◄─Response── Service B
           (A ממתין ל-B)

Asynchronous (א-סינכרוני):
──────────────────────────
Service A ──Message──► Message Queue ──Message──► Service B
           (A לא ממתין, ממשיך לעבוד)

Event-Driven Architecture

┌──────────┐                         ┌──────────────┐
│  Orders  │── OrderCreated event ──►│ Event Bus    │
│  Service │                         │ (Kafka/      │
└──────────┘                         │  RabbitMQ)   │
                                     └──────┬───────┘
                                            │
                            ┌───────────────┼───────────────┐
                            ▼               ▼               ▼
                     ┌──────────┐   ┌──────────┐   ┌──────────┐
                     │ Payment  │   │ Inventory│   │  Email   │
                     │ Service  │   │ Service  │   │ Service  │
                     └──────────┘   └──────────┘   └──────────┘
                     "גבה תשלום"    "הורד מלאי"    "שלח אישור"

Saga Pattern -- טרנזקציות מבוזרות

כשפעולה עסקית כוללת מספר Microservices ומשהו נכשל באמצע:

Order Saga (Choreography):
──────────────────────────

1. Orders Service: צור הזמנה ───► event: OrderCreated
2. Payment Service: גבה תשלום ───► event: PaymentCompleted
3. Inventory Service: הקצה מלאי ───► event: InventoryReserved
4. Shipping Service: צור משלוח ───► event: ShipmentCreated

אם שלב 3 נכשל (אין מלאי):
3. Inventory Service ───► event: InventoryFailed
   ← Payment Service: **החזר תשלום** (Compensating Transaction)
   ← Orders Service: **בטל הזמנה** (Compensating Transaction)

בלבולים נפוצים

• "Server זה מחשב ספציפי" -- לא בהכרח. Server זה תפקיד, לא חומרה. המחשב שלכם יכול להיות Server אם הוא מריץ תוכנה שמקשיבה לבקשות.
• "Client זה תמיד דפדפן" -- לא. Client יכול להיות אפליקציית מובייל, CLI, שרת אחר, או כל תוכנה שיוזמת בקשה.
• "REST זה פרוטוקול" -- REST הוא סגנון ארכיטקטורה (Architectural Style), לא פרוטוקול. הפרוטוקול שמתחת הוא HTTP.
• "Stateless אומר שאין State בכלל" -- יש State, אבל הוא לא נשמר בשרת. הוא נשמר ב-Client (Token) או ב-Database.
• "WebSocket מחליף את HTTP" -- WebSocket משלים את HTTP. ה-Handshake הראשוני הוא HTTP. רוב האפליקציות משתמשות בשניהם.
• "gRPC תמיד עדיף על REST" -- gRPC מצוין ל-Microservices פנימיים, אבל ל-Public API שצריך לעבוד מדפדפן, REST פשוט ונוח יותר.
• "GraphQL פותר את כל הבעיות של REST" -- GraphQL פותר Over/Under Fetching, אבל מוסיף מורכבות (N+1 queries, caching, authorization per field). אין כדור כסף.

דוגמה קטנה

נניח שאתם בונים אפליקציית רשימת מטלות (To-Do App):

Client (React App)                    Server (Node.js + Express)
─────────────────                    ──────────────────────────

1. המשתמש לוחץ "הוסף מטלה"
   POST /api/todos                ──►  מקבל את הבקשה
   Body: {"text": "ללמוד רשתות"}       שומר ב-Database
                                  ◄──  מחזיר: 201 Created
                                       {"id": 1, "text": "ללמוד רשתות"}

2. המשתמש רוצה לראות את כל המטלות
   GET /api/todos                 ──►  שולף מה-Database
                                  ◄──  מחזיר: 200 OK
                                       [{"id": 1, "text": "ללמוד רשתות"}]

3. המשתמש מוחק מטלה
   DELETE /api/todos/1            ──►  מוחק מה-Database
                                  ◄──  מחזיר: 204 No Content

📚 לימוד אקדמי

🛤️ מאיפה מתחילים

1. הבינו את הבסיס -- בנו שרת HTTP פשוט (Node.js Express או Python Flask). כתבו 4 Routes בסיסיים (GET, POST, PUT, DELETE) ותתרגלו עם Postman או curl.

2. למדו HTTP לעומק -- קראו על Status Codes, Headers, ו-Content Types. השתמשו ב-httpbin.org לתרגול.

3. בנו REST API מלא -- צרו API עם CRUD מלא, Validation, Error Handling, ו-Authentication (JWT).

4. הכירו WebSockets -- בנו אפליקציית צ'אט פשוטה עם Socket.IO (Node.js) או שימוש ישיר ב-WebSocket API.

5. התנסו ב-GraphQL -- צרו GraphQL Schema פשוט עם Apollo Server. השוו את החוויה ל-REST.

6. קראו על gRPC -- התקינו gRPC, כתבו קובץ .proto, וצרו שירות פשוט. הבינו מתי gRPC עדיף על REST.

7. צללו ל-Messaging -- הריצו RabbitMQ או Redis Pub/Sub מקומית, ובנו תקשורת א-סינכרונית בין שני שירותים.

8. קראו על Design Patterns -- הכירו את Saga, CQRS, Event Sourcing, ו-API Gateway Pattern.

💼 שאלות לראיון עבודה

קישורים לנושאים אחרים

• 7 שכבות OSI -- Client-Server עובד מעל שכבות הרשת. חשוב להבין את התמונה המלאה.
• TCP/IP & HTTP -- הפרוטוקולים שמאפשרים את התקשורת בין Client ל-Server.
• מחשב מול שרת -- מה ההבדל בין המחשב שלכם לבין שרת שרץ ב-Cloud?