Ось готовий урок, згенерований за твоїм майстер-промптом.

🏛 Тема: Архітектура сучасного веб-сервера

Привіт, друзі! Це CS50 (умовно 😉), і сьогодні ми зазирнемо під капот інтернету.

1. 🔥 Вступ: проблема та мотивація

Уявіть ситуацію. Ви написали геніальний код для стартапу. На вашому ноутбуці все літає: ви натискаєте кнопку — сторінка відкривається миттєво. Ви запускаєте проєкт у світ, про нього пише популярний блогер, і до вас одночасно заходить 10 000 користувачів.

І що відбувається? Ваш сервер падає. Або, що ще гірше, він починає працювати так повільно, що користувачі бачать білий екран і йдуть до конкурентів.

Чому так сталося? Адже код був правильний!

Справа в тому, що вміння писати код (PHP, Python, JS) і розуміння того, як цей код виконується під навантаженням — це різні речі.

Уявіть собі кав'ярню. * Варіант А: Є один бариста. Він приймає замовлення, сам йде молоти каву, сам збиває молоко, сам видає, приймає оплату. Поки він робить лате для одного клієнта, черга з 20 людей стоїть і чекає. Ніхто навіть замовити не може! * Варіант Б: Є касир (приймає замовлення) і є бариста (робить каву). Касир видає чек і кричить "Наступний!". Черга рухається миттєво, навіть якщо кава ще готується.

Сучасний веб-сервер — це саме Варіант Б. Якщо ви не зрозумієте його архітектуру, ваші програми назавжди залишаться у повільній черзі "Варіанту А".

2. 🧠 Теоретична база (без сухої академічності)

Давайте розберемося з поняттями. Коли ми кажемо "Веб-сервер", ми часто плутаємо дві речі: 1. Залізо (Hardware): фізичний комп'ютер десь у дата-центрі. 2. Софт (Software): програма (наприклад, Nginx, Apache, Caddy), яка слухає інтернет і відповідає на запити.

Сьогодні ми говоримо про Софт.

Як це працює "під капотом"?

У класичному розумінні веб-сервер робить три речі: 1. Приймає Request (запит від браузера). 2. Обробляє його (шукає файл або передає задачу вашому коду). 3. Віддає Response (відповідь — HTML, картинку, JSON).

Але диявол криється в деталях. Як обробити 10 000 запитів одночасно?

🚦 Дві головні моделі (запам'ятайте це!):

1. Thread/Process-based (Класика, як старий Apache):

   • На кожного нового користувача сервер створює окремий "потік" (thread) або процес.
   • Аналогія: На кожного клієнта в кав'ярні ви наймаєте окремого офіціанта.
   • Проблема: Якщо прийде 10 000 людей, у вас закінчаться офіціанти (пам'ять сервера).

2. Event-driven / Asynchronous (Сучасність, як Nginx або Node.js):

   • Є один головний цикл (Event Loop), який дуже швидко приймає "квитки" із замовленнями. Він не готує каву сам, він роздає задачі й одразу біжить до наступного клієнта.
   • Аналогія: Один супер-швидкий касир і багато кухарів на кухні. Касир ніколи не чекає.
   • Перевага: Може тримати десятки тисяч з'єднань з мінімальними витратами пам'яті.

3. 🧪 Приклади (від простого до реального)

Приклад 1: Статика (Найпростіший рівень)

Користувач просить файл logo.png.

• Сервер: Бачить запит. Дивиться на жорсткий диск. Знаходить файл. Віддає.
• Риторичне питання: Чи треба тут запускати Python або PHP?
• Відповідь: Ні! Це зайве навантаження. Сучасні сервери (Nginx) віддають статику "з коробки" неймовірно швидко.

Приклад 2: Динаміка (Рівень розробника)

Користувач хоче сторінку "Мій профіль". Тут дані лежать у базі даних.

Помилкове очікування: Веб-сервер сам піде в базу даних. Реальність: Веб-сервер (Nginx) виступає як Reverse Proxy (Зворотний проксі).

Він каже: "Гей, Python (Gunicorn/Uvicorn), тут прийшов запит на профіль. Зроби магію, а я поки потримаю з'єднання з клієнтом".

1. Клієнт -> Nginx (швидкий, тримає удар).
2. Nginx -> Ваш додаток (повільніший, робить логіку).
3. Ваш додаток -> Nginx.
4. Nginx -> Клієнт.

Чому так? Бо якщо ви пустите клієнтів напряму до вашого повільного Python-скрипта, перший же "важкий" запит заблокує вхід для всіх інших. Nginx буферизує ці процеси.

4. 🛠 Практична частина

Час перевірити, як ви це зрозуміли.

🔹 Завдання 1: Роль проксі

Уявіть, що ви налаштовуєте сервер для Instagram. Клієнт завантажує важке відео (100 Мб). У вас є Nginx (вхідні ворота) і бекенд на Python. Питання: Хто має займатися прийомом цього файлу — тримати з'єднання 30 секунд, поки файл летить по повільному 3G інтернету? 1. Python-процес 2. Nginx Поясніть чому.

🔹 Завдання 2: "Вузьке місце" (Bottleneck)

Ваш сервер почав гальмувати. Ви дивитесь моніторинг: процесор (CPU) завантажений на 5%, а оперативна пам'ять (RAM) забита на 100%. Яку архітектурну модель, швидше за все, використовує цей сервер — Event-driven (події) чи Process-based (процеси)? Чому?

🔹 Завдання 3: Міні-кейс

До вас прийшов замовник: "У нас завтра розпродаж, буде 50 000 людей за годину. Зараз у нас один сервер, де крутиться і база даних, і веб-сервер, і картинки". Намалюйте (опишіть словами) план порятунку. Що треба винести на окремі машини в першу чергу?

🔹 Завдання 4: А що, якщо...

Що станеться, якщо ваш веб-сервер налаштований ідеально, але база даних може обробляти лише 1 запит на секунду? Як користувач відчує це? (Підказка: згадайте про таймаути).

5. 💡 Мислення як у розробника

Новачки часто думають: "Мій код працює, значить робота зроблена". Досвідчений інженер (Senior) думає: "Що станеться з моїм кодом, якщо його запустять 1000 разів одночасно?".

Типові помилки:

1. Serving static files with backend: Змушувати Node.js або Django віддавати картинки та CSS. Це як змушувати шеф-кухаря мити підлогу. Для цього є Nginx або CDN.
2. Blocking the Event Loop: У Node.js написати важку математичну функцію, яка рахується 5 секунд. У цей час сервер "помирає" для всіх інших.

Порада від профі:

Завжди ставте між світом і своїм кодом прошарок (Nginx, Load Balancer). Це ваш щит. Він візьме на себе SSL-шифрування, стиснення (gzip), кешування і захист від простих атак. Нехай ваш код займається бізнес-логікою, а не інфраструктурою.

6. 🧩 Підсумок

Отже, сьогодні ми з'ясували: 1. Веб-сервер — це менеджер залу, який керує потоками клієнтів. 2. Синхронність — зло для високих навантажень. Асинхронність та події — наш вибір. 3. Reverse Proxy — це найкращий друг вашого бекенду, який захищає його від прямого контакту з хаосом інтернету.

Тепер ви не просто "кодери", ви починаєте мислити як архітектори.

Що далі? Ми навчилися приймати запити. Але де зберігати мільйони записів про користувачів, щоб це було швидко? На наступному уроці ми пірнемо у світ Баз Даних та SQL. Готуйтеся, буде багато таблиць!

Побачимось! 👋