Загальні

Повне пояснення

Що це і навіщо HTTP‑методи визначають тип операції над ресурсом. Вони потрібні для розмежування читання, створення, оновлення та видалення даних.

Ключові принципи/терміни

• GET – читання, без побічних ефектів.
• POST – створення нового ресурсу; сервер повертає його ідентифікатор.
• PUT – повне заміщення ресурсу; id вказується у URL.
• PATCH – часткове оновлення; передається лише змінені поля.
• DELETE – видалення ресурсу; повертає статус 204 при успіху.

Як це працює Клієнт формує HTTP‑запит, сервер обробляє його відповідно до методу і повертає статус‑коди (200, 201, 204, 404 тощо).

Практика і реалізація

async function createUser(data: User) {
  const res = await fetch('/users', {method:'POST', headers:{'Content-Type':'application/json'}, body:JSON.stringify(data)});
  return res.json();
}

Тестування У Jest можна мокати fetch:

global.fetch = jest.fn(() => Promise.resolve({json: () => Promise.resolve({id:1})}));

Безпека і приватність

• Використовувати HTTPS.
• Перевіряти вхідні дані на сервері, щоб уникнути SQL‑ін’єкцій.
• Для POST/PUT/PATCH застосовувати CSRF‑token.

Оптимізація

• Кешувати GET‑запити за допомогою Cache-Control.
• Для PATCH передавати лише мінімальний набір полів.

Часті помилки

1. Використання GET для створення ресурсів.
2. Необхідність вказувати Content-Type при POST/PUT/PATCH.
3. Необроблені 4xx/5xx відповіді.

Cheatsheet

• GET – читання
• POST – створення
• PUT – повне оновлення
• PATCH – часткове оновлення
• DELETE – видалення

Повне пояснення

Що це і навіщо HTTP (HyperText Transfer Protocol) – протокол прикладного рівня, що забезпечує обмін даними між клієнтом і сервером у веб‑середовищі. Кожна версія вводить нові можливості, покращуючи продуктивність і зручність.

Ключові принципи/терміни

• Persistent connection – збереження TCP‑з’єднання після одного запиту.
• Pipelining – надсилання кількох запитів без очікування відповідей.
• Chunked encoding – розбиття відповіді на частини, коли довжина невідома.
• Multiplexing – одночасна передача кількох потоків даних по одному TCP‑з’єднанню.
• Header compression – зменшення розміру заголовків у HTTP/2.
• Server push – сервер може надсилати ресурси до клієнта без явного запиту.

Як це працює

1. Клієнт відкриває TCP‑з’єднання.
2. Відправляє HTTP‑запит (метод, URL, заголовки).
3. Сервер обробляє запит і повертає HTTP‑відповідь.
4. У HTTP/1.1 з’єднання залишається відкритим, що дозволяє надсилати наступні запити без повторного встановлення TCP‑з’єднання.
5. У HTTP/2 використовується двійковий формат, що дозволяє одночасно передавати кілька запитів/відповідей по одному з’єднанню.

Практика і реалізація

• У Node.js можна створити сервер HTTP/1.1 за допомогою модуля http:

const http = require('http');
http.createServer((req, res) => {
  res.end('Hello');
}).listen(3000);

• Для HTTP/2 використовується модуль http2:

const http2 = require('http2');
const server = http2.createServer();
server.on('stream', (stream) => {
  stream.respond({ 'content-type': 'text/plain' });
  stream.end('Hello');
});
server.listen(3000);

Тестування

• Unit: перевірка правильності формування заголовків за допомогою Jest.
• Integration: використання supertest для тестування HTTP‑запитів до локального сервера.
• E2E: Playwright може виконувати запити і перевіряти відповіді.

Безпека та приватність

• Використання HTTPS (TLS) над HTTP/1.1 і HTTP/2 забезпечує шифрування.
• У HTTP/2 заборонено одразу відкривати нові TCP‑з’єднання, що зменшує ризик атак типу "slowloris".

Оптимізація та edge cases

• У HTTP/1.1 важливо закривати Connection: close, коли не потрібна persistent connection.
• У HTTP/2 слід уникати надмірного використання server push, оскільки це може збільшити навантаження.

Часті помилки

• Неправильне використання Transfer-Encoding: chunked у HTTP/1.1.
• Відсутність підтримки ALPN при налаштуванні TLS для HTTP/2.

Cheatsheet

• HTTP/1.0: один запит → одне з’єднання.
• HTTP/1.1: persistent connection, pipelining, chunked encoding.
• HTTP/2: multiplexing, header compression, server push, двійковий формат.

Повне пояснення

Що це і навіщо HTTP‑статуси – числові відповіді сервера, що сигналізують про стан обробки запиту. Вони потрібні для синхронізації клієнта і сервера, визначення подальших дій.

Ключові принципи/терміни

• 1xx – інформативні (наприклад, 100 Continue)
• 2xx – успішні (200 OK, 201 Created)
• 3xx – перенаправлення (301 Moved Permanently, 302 Found)
• 4xx – помилки клієнта (400 Bad Request, 401 Unauthorized, 404 Not Found)
• 5xx – помилки сервера (500 Internal Server Error, 502 Bad Gateway)

Як це працює Після отримання HTTP‑запиту сервер формує відповідь, вибираючи код за результатом логіки обробки. Клієнт читає код і вирішує, чи повторювати запит, перенаправлятися або показувати помилку.

Практика і реалізація У Node.js/Express: res.status(404).send('Not Found'); У React‑Query: queryClient.invalidateQueries(['posts']); після отримання 401.

Тестування Jest + Supertest:

const request = require('supertest');
it('returns 200', async () => {
  const res = await request(app).get('/api');
  expect(res.statusCode).toBe(200);
});

Безпека і приватність Не розголошувати внутрішні помилки через 500; використовуйте загальний Internal Server Error і логування.

Оптимізація Кешуйте 200‑повіді з Cache-Control; використовуйте 304 Not Modified для ресурсів, що не змінилися.

Часті помилки

• Відсутність Content-Type у відповіді
• Неправильний код 404 замість 403
• Перевантаження сервера через 5xx без ретрансляції

Cheatsheet

• 200 OK – успішний GET/POST
• 201 Created – новий ресурс
• 204 No Content – успішний DELETE
• 301/302 – перенаправлення
• 400 Bad Request – синтаксична помилка
• 401 Unauthorized – автентифікація потрібна
• 403 Forbidden – доступ заборонено
• 404 Not Found – ресурс не знайдено
• 500 Internal Server Error – внутрішня помилка сервера

Повне пояснення

Що це і навіщо CORS – протокол, що розширює політику безпеки браузера, дозволяючи обмін даними між різними доменами. Без CORS запити з іншого origin блокуються, що обмежує інтеграцію API.

Ключові принципи/терміни

• Access-Control-Allow-Origin – визначає, які домени мають доступ.
• preflight (OPTIONS) – запит, що перевіряє дозволи перед реальним.
• credentials – включає cookie/HTTP‑auth у запитах.

Як це працює

1. Браузер надсилає запит.
2. Якщо origin не відповідає заголовкам, браузер блокує відповідь.
3. Сервер додає потрібні заголовки, після чого браузер приймає дані.

Практика і реалізація (Node.js/Express)

const cors = require('cors');
app.use(cors({ origin: 'https://example.com', credentials: true }));

app.get('/data', (req, res) => {
  res.setHeader('Access-Control-Allow-Origin', '*');
  res.json({ msg: 'ok' });
});

Тестування

• Unit: перевірити, що сервер повертає правильний заголовок.

test('CORS header present', async () => {
  const res = await request(app).get('/data');
  expect(res.headers['access-control-allow-origin']).toBe('*');
});

Безпека

• Не використовуйте * у production, обмежуйте конкретні домени.
• Якщо потрібен доступ з cookie, встановіть Access-Control-Allow-Credentials: true і вказуйте конкретний origin.

Оптимізація

• Кешуйте preflight‑запити за допомогою Access-Control-Max-Age.
• Уникайте надмірних заголовків, що збільшують розмір відповіді.

Часті помилки

1. Відсутність заголовка Access-Control-Allow-Origin → 403.
2. Невірний формат заголовка (наприклад, Access-Control-Allow-Origin: https://example.com/) → блокування.
3. Забудьте про OPTIONS preflight, коли використовуєте нестандартні методи.

Cheatsheet

• Access-Control-Allow-Origin: * – відкритий доступ.
• Access-Control-Allow-Credentials: true + конкретний origin – доступ з cookie.
• Access-Control-Max-Age: 86400 – кеш preflight на 24 години.

Follow‑up питання

• Як обмежити CORS лише для певних маршрутів?
• Які ризики пов’язані з використанням * у production?

Повне пояснення

Що це і навіщо Cookie – ключовий механізм зберігання даних на стороні клієнта, що дозволяє серверу ідентифікувати користувача між запитами. Використовується для сесійної аутентифікації, персоналізації контенту та відстеження поведінки.

Ключові принципи/терміни

• Domain – домен, до якого cookie прив’язаний.
• Path – шлях, де cookie доступний.
• Expires / Max-Age – термін дії.
• Secure – передається лише по HTTPS.
• HttpOnly – недоступний через JavaScript, підвищує безпеку.

Як це працює Після встановлення cookie браузер зберігає його у вигляді рядка. При кожному HTTP‑запиті до відповідного домену браузер додає заголовок Cookie, що містить всі cookie, що відповідають домену та шляху.

Практика і реалізація (JavaScript/TypeScript)

// Встановлення cookie
function setCookie(name: string, value: string, days?: number) {
  const expires = days ? `; expires=${new Date(Date.now() + days * 864e5).toUTCString()}` : '';
  document.cookie = `${name}=${encodeURIComponent(value)}${expires}; path=/; secure`;
}

// Читання cookie
function getCookie(name: string) {
  const match = document.cookie.match(new RegExp('(?:^|; )' + name.replace(/([.$?*|{}()\[\]\\/+^])/g, '\$1') + '=([^;]*)'));
  return match ? decodeURIComponent(match[1]) : null;
}

Тестування Для unit‑тестів можна використовувати jsdom у Jest:

import { JSDOM } from 'jsdom';
const dom = new JSDOM('', { url: 'https://example.com' });
document.cookie = 'test=123';
expect(document.cookie).toContain('test=123');

Безпека і приватність

• Використовуйте HttpOnly для токенів, що не повинні бути доступними через JavaScript.
• Уникайте зберігання конфіденційних даних у cookie без шифрування.
• Після виходу користувача очищуйте cookie, встановлюючи expires у минуле.

Особливості в контексті веб‑розробки

• У Next.js 14/15 cookie можна читати на сервері через next/headers.
• У React‑приложеннях часто комбінують cookie з react-cookie або js-cookie для простішого API.

Оптимізація і типові помилки

• Не перевантажуйте cookie великими даними; розмір обмежений приблизно 4 KB.
• Уникайте дублювання cookie з однаковим ім’ям, що призводить до непередбачуваних результатів.

Диагностика

• Якщо cookie не приходить на сервер, перевірте Domain і Path.
• У Chrome DevTools вкладка Application → Cookies дозволяє переглядати значення та атрибути.

Альтернативи

• LocalStorage/SessionStorage – зберігають дані лише на стороні клієнта.
• Server‑side sessions – зберігають стан у пам’яті або базі даних, передаючи лише ID в cookie.

Повне пояснення

Що це і навіщо Cookie використовується для зберігання стану, аутентифікації та персоналізації. Кожен cookie має назву, значення і атрибути (path, domain, expires, secure тощо).

Ключові принципи/терміни

• Max‑Age / Expires – час життя cookie.
• SameSite – політика доступу між сайтами.
• Secure / HttpOnly – безпека передачі.

Як це працює Браузер додає cookie до HTTP-запиту, якщо домен і шлях збігаються. Сервер може встановити cookie через заголовок Set-Cookie.

Практика і реалізація

document.cookie = 'token=abc123; Max-Age=3600; Secure; SameSite=Lax';

Тестування У Jest можна перевірити cookie через jsdom:

document.cookie = 'id=1';
expect(document.cookie).toContain('id=1');

Безпека і приватність Використовуйте Secure та HttpOnly, щоб запобігти XSS‑атак. Для великих даних краще зберігати у localStorage або на сервері.

Обмеження/ліміти

• 4 КБ на cookie.
• Браузери мають максимум 20–50 cookie за доменом (залежно від реалізації).
• При перевищенні розміру сервер повертає Set-Cookie з обмеженим значенням або відкидає.

Часті помилки

• Перевищення 4 КБ → обтинка даних.
• Забудова атрибуту SameSite → блокування міжсайтових запитів.
• Зберігання паролей у cookie → ризик XSS.

Повне пояснення

Що це і навіщо

• use strict – директива, що включає strict mode у JavaScript. Вона змушує інтерпретатор виконувати код з жорсткішими правилами, що запобігає типові помилки.

Ключові принципи/терміни

• Strict mode блокує створення неявних глобальних змінних.
• Забороняє використання eval без явного параметру.
• Підвищує точність перевірки типів (наприклад, delete на властивості об’єкта не дозволено).

Як це працює

• Директива розміщується на початку скрипту або функції.
• Якщо вона присутня, інтерпретатор застосовує суворі правила до всього блоку.

Практика і реалізація

// У файлі script.js
'use strict';
function calculate() {
  let result = 0;
  for (let i = 1; i <= 10; i++) {
    result += i;
  }
  return result;
}

Тестування

• У Jest можна перевірити, що код не створює глобальних змінних:

test('no implicit globals', () => {
  expect(() => { eval("x = 5;"); }).toThrow();
});

Безпека і приватність

• use strict зменшує ризик XSS, оскільки обмежує використання eval.
• Підвищує надійність коду, що важливо для бекенд‑сервісів (наприклад, у NestJS).

Особливості в контексті JavaScript/TypeScript

• У TypeScript директива автоматично включається, якщо компілятор налаштований на target: es5 або вище.
• У ES6+ модулі (import/export) вже працюють у суворому режимі без явної директиви.

Оптимізація, типові помилки та edge cases

• Необхідно розміщувати директиву на початку кожної функції, якщо потрібен локальний strict mode.
• Помилка: delete на властивості об’єкта в strict mode піднімає TypeError.
• Edge case: eval у strict mode не створює нові змінні в зовнішньому контексті.

Диагностика і отладка

• Якщо код піднімає ReferenceError: x is not defined, перевірте, чи не створювалися неявні глобальні.
• У браузері відкрийте DevTools → Console, щоб побачити повідомлення про помилки strict mode.

Альтернативи

• У сучасних проектах можна просто використовувати ES6+ модулі, що автоматично включають strict mode.
• Якщо потрібен контроль над режимом у старих скриптах, залишайте директиву вручну.

Повне пояснення

Що це і навіщо

• JavaScript – універсальна мова, що застосовується як у браузері (front‑end), так і на сервері (back‑end) через Node.js. Вона дозволяє створювати динамічні UI‑компоненти та обробляти серверну логіку.

Ключові принципи/терміни

• Event loop – цикл обробки подій, спільний для обох середовищ.
• DOM – Document Object Model, доступний лише у браузері.
• libuv – бібліотека Node.js для асинхронного I/O.
• Modules – ES‑modules у браузері, CommonJS/ESM у Node.js.

Як це працює

• У браузері код виконується в контексті window або worker, має доступ до document і API, таких як fetch.
• У Node.js код запускається в процесі V8‑рушія, має доступ до fs, net і інших серверних модулів.

Практика та реалізація

• Front‑end: document.querySelector('.btn').addEventListener('click', () => console.log('clicked'));
• Back‑end: const fs = require('fs'); fs.readFile('data.json', 'utf8', (err, data) => { if (!err) console.log(JSON.parse(data)); });

Тестування

• Front‑end: Jest + Testing Library – render(<Button />); fireEvent.click(screen.getByText('Submit')); expect(console.log).toHaveBeenCalled();
• Back‑end: Jest + Supertest – request(app).get('/api').expect(200);

Безпека та приватність

• На front‑end обмежений доступ до файлової системи; безпечність забезпечується CORS, CSP.
• На back‑end слід обмежувати доступ до файлової системи через ролі, використовувати process.env для конфігурації.

Оптимізація

• Front‑end: мінімізувати кількість DOM‑операцій, використовувати requestAnimationFrame.
• Back‑end: пул з’єднань, кешування, асинхронні обробники.

Диагностика

• Front‑end: консоль браузера, DevTools → Network.
• Back‑end: логування через console.log або Winston, профілювання з node --inspect.

Альтернативи

• Для front‑end: WebAssembly, TypeScript.
• Для back‑end: Deno, Go, Python – але JS через Node.js залишається найпоширенішим.

Часті помилки

1. Виклик document у Node.js → ReferenceError.
2. Невірне використання require в ES‑module → SyntaxError.
3. Переповнення стеку через синхронні I/O у Node.js → блокування.
4. Перевищення CORS‑політики при fetch → 403/401.
5. Неправильне оброблення колбеків → callback hell.
6. Відсутність async/await у Node.js → неочікувані проміси.
7. Перевантаження DOM у front‑end → низька продуктивність.
8. Неправильне налаштування process.env → витік конфіденційних даних.

Повне пояснення

Що це і навіщо

• Статична типізація – визначення типів змінних, параметрів і повертаємих значень на етапі компіляції. Це дозволяє виявити помилки ще до запуску коду, підвищуючи надійність і читабельність.
• Динамічна типізація – визначення типів під час виконання. JavaScript, Python, Ruby тощо працюють динамічно, що забезпечує гнучкість, але збільшує ризик runtime‑помилок.

Ключові принципи/терміни

• Тип – опис структури даних (наприклад, number, string, Array<string>).
• Типова система – набір правил, що визначає, які операції допустимі для конкретного типу.
• TypeScript – надбудова над JavaScript, що додає статичну типізацію.
• JSDoc – коментарі, що дозволяють інструментам типізувати JavaScript.

Як це працює

• У статичній типізації компілятор (наприклад, tsc) аналізує код, порівнює типи і генерує помилки при несумісності.
• У динамічній типізації браузер або V8 виконують код, визначаючи типи під час кожної операції.

Практика і реалізація (JavaScript/TypeScript)

// TypeScript – статична типізація
function sum(a: number, b: number): number {
  return a + b;
}

// JavaScript – динамічна типізація
function sum(a, b) {
  return a + b;
}

Тестування

• Для TypeScript можна використовувати Jest з ts-jest для типового тестування.
• Для JavaScript – Jest без додаткових налаштувань, але можна перевіряти типи через typeof.

Безпека та приватність

• Статична типізація допомагає уникнути небажаних типових помилок, що може зменшити вразливості.
• Динамічна типізація потребує ретельної валідації вводу, особливо у бекенді.

Оптимізація

• Статичні типи дозволяють інструментам оптимізувати код під час компіляції.
• Динамічні типи можуть призвести до додаткових перевірок у runtime.

Часті помилки

1. Невідповідність типу – передача string там, де очікується number.
2. Неявне типування – використання any, що знижує переваги статичної типізації.
3. Втрата типу при розпакуванні – неправильне використання as у TypeScript.
4. Перевантаження функцій – в JavaScript немає перевантажень, тому треба обробляти різні сигнатури вручну.

Cheatsheet

• number, string, boolean, Array<T>, Record<K, V>, unknown, any.
• interface, type, enum – для складних типів.

Follow‑up питання

• Як працює unknown у TypeScript? – відповідає, що це тип безпеки, який потребує перевірки перед використанням.
• Чому any слід уникати? – бо він відключає перевірку типів, що порушує переваги статичної типізації.

Повне пояснення

Що це і навіщо REST (Representational State Transfer) — архітектурний стиль, що дозволяє створювати масштабовані веб‑сервіси. Він забезпечує просту, стандартизовану взаємодію між клієнтом і сервером.

Ключові принципи/терміни

• URI (Uniform Resource Identifier) – унікальний ідентифікатор ресурсу.
• HTTP‑методи – GET, POST, PUT, PATCH, DELETE, HEAD.
• Безстанність (statelessness) – кожен запит містить всю необхідну інформацію.
• Кешованість (cacheability) – відповіді можуть бути кешовані для зменшення навантаження.
• Класифікація ресурсів – ресурси представлені у вигляді об’єктів.

Як це працює Клієнт надсилає HTTP‑запит до URI, сервер обробляє його і повертає представлення ресурсу. Сервер не зберігає стан між запитами, тому кожен запит обробляється незалежно.

Практика і реалізація (JavaScript/TypeScript)

import axios from 'axios';
const getUser = async (id: number) => {
  const { data } = await axios.get(`/api/users/${id}`);
  return data;
};

Тестування (Jest + Supertest)

import request from 'supertest';
import app from './app';

test('GET /api/users/1', async () => {
  const res = await request(app).get('/api/users/1');
  expect(res.status).toBe(200);
  expect(res.body).toHaveProperty('id', 1);
});

Безпека і приватність

• Використовувати HTTPS.
• Аутентифікація через JWT або OAuth2.
• Валідація вхідних даних, щоб уникнути SQL‑ін’єкцій і XSS.

Оптимізація

• Кешування відповіді за допомогою заголовків Cache-Control.
• Пагінація, сортування і фільтрація через query‑параметри.

Часті помилки

1. Повернення 200 OK при створенні ресурсу – краще 201 Created.
2. Відсутність Content-Type: application/json у відповіді.
3. Необхідність в підтримці ETag для оптимізації оновлень.

Cheatsheet

• GET – читання
• POST – створення
• PUT/PATCH – оновлення
• DELETE – видалення
• HEAD – метадані

Повне пояснення

Що це і навіщо Мутабельність (mutable) означає, що після створення об’єкта його внутрішнє стан можна змінювати. Іммутабельність (immutable) гарантує, що об’єкт не піддається змінам; будь‑яка «зміна» створює новий об’єкт.

Ключові принципи/терміни

• Reference type (object, array, function) – мутабельні.
• Primitive type (number, string, boolean, null, undefined, symbol) – іммутабельні.
• Reassignment змінює посилання, а не саму структуру.

Як це працює При мутабельному типі зміни вносяться без створення копії: obj.a = 2;. Для іммутабельного типу будь‑яка операція повертає новий об’єкт: const newStr = str + '!';.

Практика і реалізація (JS/TS)

const obj = { a: 1 };
obj.a = 2; // мутабельність

const str = 'hi';
const newStr = str + '!'; // іммутабельність, оригінал залишається

Тестування У Jest можна перевірити, що об’єкт не змінюється:

expect(() => { obj.a = 3; }).not.toThrow();
expect(str).toBe('hi');

Оптимізація та edge‑cases

• Для великих масивів використовуйте Object.freeze() або бібліотеки типу Immutable.js.
• У React state слід тримати іммутабельним, щоб забезпечити правильний рендер.

Часті помилки

• Необережне мутування state в Redux.
• Використання Object.assign() без копії.

Cheatsheet

• Mutable: object, array, function.
• Immutable: number, string, boolean, null, undefined, symbol.

Повне пояснення

Що це і навіщо Дебагер (debugger) — інструмент, що дозволяє розбивати виконання програми на контрольовані точки (breakpoints) і аналізувати стан у будь‑який момент. Це ключовий механізм для виявлення логічних помилок, неочікуваних значень і некоректного потоку.

Ключові принципи

• Breakpoints – зупинка виконання на конкретному рядку.
• Watch‑поля – відстеження змін значень виразів.
• Call stack – історія викликів, що допомагає зрозуміти контекст.
• Console – простий спосіб виводу інформації, але менш контрольований.

Як це працює

1. Відкривається DevTools (Ctrl+Shift+I або F12).
2. Перехід до вкладки Sources → вибір файлу.
3. Клік по лінії коду створює breakpoint.
4. При досягненні точки виконання скрипт зупиняється, і можна перевірити значення.

Практика та реалізація (JavaScript/TypeScript)

function calculate(a: number, b: number) {
  const result = a + b;
  debugger; // зупинка на цьому рядку
  return result;
}

console.log('Start calculation');
const sum = calculate(5, 7);
console.log('Result:', sum);

Тестування Для unit‑тестів можна використовувати Jest з --runInBand і debugger у тестах, а для e2e – Playwright з page.pause().

Оптимізація та edge cases

• Перевірка undefined/null перед використанням.
• Уникайте занадто глибоких рекурсій, що призводять до stack overflow.
• Пам’ятайте про asynchronous код: використовуйте await у breakpoints.

Часті помилки

1. Забувають видалити debugger перед продакшн‑деплоєм.
2. Неправильне розташування breakpoint у мініфікованому коді.
3. Не враховують closure при спостереженні змінних.

Дизайн‑рішення

• Для великих проектів створюйте debug config у VS Code, що автоматично відкриває потрібний файл.
• Використовуйте source maps для TypeScript, щоб бачити оригінальний код.

Питання після відповіді

• Як налаштувати breakpoint лише при певному значенні змінної?
• Які інструменти підтримують remote‑debugging для Node.js?

Повне пояснення

Що це і навіщо

Відомі особи JS — ключові діячі, що формують технологічний ландшафт JavaScript. Їх внесок допомагає розуміти історію, стандарти та практики.

Ключові принципи/терміни

• Brendan Eich – автор мови, створив 1995 рік.
• Ryan Dahl – винахідник Node.js, що запровадив асинхронний I/O.
• Kent C. Dodds – експерт з React, тестування та документації.
• Dan Abramov – розробник Redux і React Hooks.
• Addy Osmani – експерт з продуктивності веб‑додатків.

Як це працює

Кожен з цих розробників впровадив інновації, що змінюють спосіб написання коду: від синтаксису до архітектури.

Практика і реалізація

У проектах часто застосовують патерни, запропоновані цими особами: Redux‑store, React Hooks, async/await.

Тестування

Багато з них пропонують бібліотеки для тестування: Jest (Dan), Testing Library (Kent).

Дизайн‑рішення і моделі даних

Вони впроваджують практики SOLID, DRY та інші принципи.

Безпека і приватність

Використовують OWASP‑рекомендації, наприклад, для захисту від XSS.

Альтернативи і порівняння

Наприклад, React vs Vue – обидва підтримують компонентний підхід, але React має ширший екосистему.

Часті помилки

1. Не читати документацію Eich щодо ECMAScript.
2. Використовувати Node.js без async/await.
3. Не застосовувати React Hooks правильно.
4. Залишати глобальний стан без Redux/Zustand.
5. Не тестувати компонентів із Testing Library.
6. Переважати класові компоненти над функціональними.
7. Не оптимізувати рендеринг у React.
8. Залишати несанкціонований доступ до API.

Повне пояснення

Що це і навіщо Піраміда тестування описує пропорції між різними типами автоматизованих тестів, що допомагає оптимізувати час розробки та забезпечити стабільність продукту.

Ключові принципи

• Unit‑тести перевіряють окремі функції/методи.
• Integration‑тести оцінюють взаємодію між модулями.
• End‑to‑end (E2E) тестують повний сценарій користувача.

Як це працює Починаємо з unit‑тестів, що швидко виявляють локальні помилки. Після їх стабілізації додаємо integration‑тести, щоб перевірити взаємодію. Нарешті, E2E тестуємо реальні сценарії.

Практика і реалізація

// unit test (Jest)
test('sum', () => {
  expect(sum(1,2)).toBe(3);
});

// integration test (Vitest)
test('user service', async () => {
  const user = await getUser(1);
  expect(user.id).toBe(1);
});

// e2e test (Playwright)
test('login flow', async ({ page }) => {
  await page.goto('/login');
  await page.fill('#email', 'test@example.com');
  await page.click('button[type=submit]');
  await expect(page).toHaveURL('/dashboard');
});

Тестування

• Unit: Jest, Vitest.
• Integration: Supertest, Prisma Test Utils.
• E2E: Playwright, Cypress.

Оптимізація Зосереджуємося на 70% unit‑тестів, щоб швидко виявляти дефекти. Integration‑тести виконуються частіше, ніж E2E, що зменшує час CI.

Часті помилки

1. Надмірна кількість E2E тестів → збільшує час.
2. Недостатня крихкість unit‑тестів → пропускаються локальні баги.
3. Відсутність моків у integration‑тестах → залежності зберігаються.

Дизайн‑рішення Використовувати shared test utils, щоб уникнути дублювання коду. Підтримувати CI‑pipeline з паралельним запуском тестів.

Безпека Тестувати валідацію даних у unit‑тестах, щоб запобігти SQL‑ін’єкціям та XSS.

Висновок Піраміда тестування забезпечує збалансований підхід, що дозволяє швидко виявляти помилки на ранніх етапах і зберігати якість продукту.

Повне пояснення

Що це і навіщо – Тестування забезпечує надійність коду, виявляє регресії і підтримує швидку розробку. Ключові принципи – ізоляція, повторюваність і швидкість виконання. Як це працює – unit‑тести перевіряють окремі функції, integration‑тести взаємодію між модулями, E2E – повний сценарій користувача. Практика – у TS проекті unit‑тести пишуться з Jest + ts-jest, інтеграційні – Vitest + React Testing Library (або Angular TestBed), E2E – Playwright з TypeScript. Тестування: Jest‑примірник:

import { sum } from './calc';
describe('sum', () => {
  it('adds numbers', () => {
    expect(sum(1,2)).toBe(3);
  });
});

Vitest‑примірник:

import { render, screen } from '@testing-library/react';
import App from './App';
test('renders welcome', () => {
  render(<App />);
  expect(screen.getByText(/welcome/i)).toBeInTheDocument();
});

Playwright‑примірник:

import { test, expect } from '@playwright/test';
test('homepage loads', async ({ page }) => {
  await page.goto('http://localhost:3000');
  expect(await page.title()).toBe('My App');
});

Дизайн‑рішення – використання TypeScript забезпечує типову безпеку, а бібліотеки з підтримкою TS мінімізують ручну конфігурацію. Производительность – Vitest компілює лише потрібні файли, Jest кешує результати. Безпека – Playwright із sandbox‑режимом запобігає небажаному доступу до системи. Оптимізація – паралельне виконання тестів у CI, використання --watch для швидкого feedback. Альтернативи – Mocha/Chai, Cypress (E2E), але Playwright має кращу підтримку багатоплатформності. Часті помилки – неправильне мокання, залежність від DOM‑структури, неочікувані асинхронні таймаути. Cheatsheet – Jest: describe/it, Vitest: test, Playwright: page.goto.

Повне пояснення

Що це і навіщо

Unit‑тест – це автоматизований перевірка окремого елемента програми (функція, метод, клас), що гарантує його коректну роботу в ізольованому середовищі. Вони допомагають швидко виявляти логічні помилки, підтримувати рефакторинг і забезпечують документацію поведінки коду.

Ключові принципи

• Ізоляція – тест не залежить від зовнішніх ресурсів (БД, мережі).
• Повторюваність – результат тесту однаковий при кожному запуску.
• Мінімальність – тест охоплює один аспект функціоналу.
• Читабельність – назва тесту описує очікуваний результат.

Як це працює

1. Підготовка – створюються моки/стабіти для залежностей.
2. Виконання – викликається функція/метод з тестовими даними.
3. Перевірка – порівнюються фактичний і очікуваний результат.
4. Звіт – тестове фреймворк видає успішний/неуспішний статус.

Практика і реалізація (JavaScript/TypeScript)

// sum.ts
export function sum(a: number, b: number): number {
  return a + b;
}

// sum.test.ts
import { sum } from './sum';

test('sum adds two numbers', () => {
  expect(sum(2, 3)).toBe(5);
});

Тестування: unit vs інші рівні

• Unit – 70–80 % тестового набору, швидкі.
• Integration – перевірка взаємодії між модулями, 10–20 %.
• E2E – повний сценарій користувача, 5–10 %.

Дизайн‑рішення

• Використовувати Jest або Vitest для швидкого запуску.
• Мокати зовнішні API через jest.mock або vi.fn().

Оптимізація

• Писати parameterized tests для різних вхідних даних.
• Уникати дублікації коду у beforeEach/setup.

Часті помилки

1. Тестування всього коду (integration в unit).
2. Залежність від глобальних змінних.
3. Неочікувані побічні ефекти (наприклад, зміна глобального стану).
4. Відсутність моків для зовнішніх сервісів.
5. Тести, що не повертають результат (наприклад, return пропущено).
6. Тести, що не очищають стан після виконання.
7. Перевірка лише позитивних сценаріїв без негативних.
8. Тести, що не документують очікувану поведінку (неякісні назви).

Cheatsheet

• expect(value).toBe(expected) – строгий рівність.
• expect(value).toEqual(object) – глибоке порівняння.
• jest.fn() / vi.fn() – створення мок-функцій.

Follow‑up питання

1. Як забезпечити ізоляцію unit‑тесту від зовнішніх сервісів?
2. Які переваги має vitest над jest у контексті TS?
3. Як впровадити parameterized tests у Jest?

Повне пояснення

Що це і навіщо

• Кешування HTTP‑запитів зберігає відповіді у браузері, що пришвидшує повторні запити. У випадках, коли дані змінюються часто або містять конфіденційну інформацію, потрібно вимкнути кеш.

Ключові принципи/терміни

• Cache-Control – заголовок, що керує кешуванням.
• no-store, no-cache, must-revalidate – директиви, що забороняють зберігання і вимушують перевірку.
• Pragma: no-cache – зворотна сумісність із HTTP/1.0.
• Expires: 0 – встановлює дату закінчення терміну у минулому.

Як це працює

• Сервер надсилає відповідь з вказаними заголовками.
• Браузер читає їх і не зберігає відповідь у кеш, а також перевіряє сервер при кожному запиті.

Практика і реалізація

• У Node.js/Express:

app.get('/data', (req, res) => {
  res.set('Cache-Control', 'no-store, no-cache, must-revalidate');
  res.set('Pragma', 'no-cache');
  res.set('Expires', '0');
  res.json({msg: 'Fresh data'});
});

• У fetch API:

fetch('/data', { cache: 'no-store' })
  .then(r => r.json())
  .then(console.log);

Тестування

• Використовуючи Chrome DevTools → Network, можна перевірити, що у відповіді немає Cache-Control‑заголовків.
• У Jest можна мокати fetch і перевірити, що опція cache встановлена.

Безпека та приватність

• Забороняючи кеш, зменшується ризик витоку конфіденційних даних через локальний кеш.
• Однак це збільшує навантаження на сервер, тому слід балансувати між продуктивністю і безпекою.

Оптимізація

• Якщо потрібна часткова кешування, використовуйте Cache-Control: max-age=0 або ETag.
• Для статичних ресурсів залишайте кешування, а динамічні запити – без.

Часті помилки

• Забувають додати Pragma для HTTP/1.0.
• Неправильно використовують no-cache (замість no-store).
• Не оновлюють заголовки при зміні коду.

Cheatsheet

• no-store – повне заборонення кешу.
• no-cache – дозволяє кешувати, але обов’язково перевіряти.
• must-revalidate – примушує браузер перевіряти після закінчення терміну.
• Expires: 0 – швидка сумісність.

Повне пояснення

Що це і навіщо

XSS (Cross‑Site Scripting) – тип веб‑атак, що дозволяє зловмиснику виконувати скрипти у контексті браузера користувача. Це використовується для крадіжки даних, підробки UI або розповсюдження шкідливого коду.

Ключові принципи

• Injection – вставка скрипту в HTML‑вміст.
• Execution context – код виконується з правами поточної сторінки.
• DOM manipulation – зміну структури DOM, доступу до куків та localStorage.

Як працює

1. Користувач вводить дані (наприклад, у форму коментаря).
2. Сервер повертає ці дані без escaping.
3. Браузер інтерпретує вставлений скрипт як частину DOM.
4. Скрипт виконується, отримуючи доступ до сесійних даних.

Практика і реалізація (JavaScript/TypeScript)

// Приклад небезпечного рендеру
const comment = '<script>alert("XSS")</script>';
document.getElementById('comments').innerHTML = comment; // XSS

// Захищений рендер за допомогою textContent
const safeComment = document.createElement('div');
safeComment.textContent = comment;
document.getElementById('comments').appendChild(safeComment);

Тестування

• Unit: перевірка функцій escaping за допомогою Jest.

import { escapeHtml } from './utils';
expect(escapeHtml('<script>')).toBe('&lt;script&gt;');

• Integration: Cypress тест, що перевіряє відсутність виконання скриптів у DOM.

Безпека і приватність

• Content‑Security‑Policy: script-src 'self' обмежує джерела скриптів.
• HTTPOnly cookies: запобігає доступу до куків через JavaScript.
• Sanitization libraries: DOMPurify, xss-filters.

Альтернативи і порівняння

• Server‑side rendering з escaping vs. Client‑side rendering без sanitization.
• React: JSX автоматично escaping, але dangerouslySetInnerHTML потребує ручного очищення.

Часті помилки

1. Використання innerHTML без escaping.
2. Неправильна CSP, що дозволяє inline‑скрипти.
3. Залишення куків без HTTPOnly.
4. Необхідність очищати дані на сервері, а не лише в клієнті.

Cheatsheet

• escapeHtml(str) → <script>.
• CSP header: Content-Security-Policy: default-src 'self'; script-src 'self'.
• React: dangerouslySetInnerHTML={{ __html: safeHtml }} після очищення.

Follow‑up питання

• Як працює CSP разом з nonce?
• Які ризики пов’язані з використанням eval у контексті XSS?

Повне пояснення

Що це і навіщо Observer дозволяє створити односторонню залежність: коли subject змінюється, всі observers отримують оновлення. Pub/Sub розділяє підписників і видавця через broker, що забезпечує анонімність та масштабованість.

Ключові принципи/терміни

• Subject / Observable – об’єкт, що генерує події.
• Observer / Subscriber – отримувачі оновлень.
• EventEmitter / Broker – механізм доставки повідомлень.

Як це працює

1. Підписник реєструється у subject (Observer) або в broker (Pub/Sub).
2. Після зміни стану subject викликає колбек або публікує повідомлення.
3. Підписники отримують оновлення і виконують логіку.

Практика та реалізація

• React Context: const ThemeContext = React.createContext(); – підписники читають контекст.
• Redux: store.subscribe(listener) – Observer‑подібний підписник.
• RxJS: const obs = new Subject(); – Observable‑публікація.
• EventTarget API: element.addEventListener('click', fn) – вбудований Observer.

Тестування

• Jest + jest.fn() для моків колбеків.
• Vitest з vi.spyOn для спостереження за викликами.

Дизайн‑рішення та моделі даних

• У Pub/Sub часто використовується topic (стрічка), що дозволяє фільтрувати повідомлення.
• У Observer‑патерні підписники отримують повний об’єкт, що змінюється.

Производительность і масштабування

• Pub/Sub з брокером (наприклад, Redis Streams) дозволяє розподіляти навантаження між серверами.
• Observer‑патерн в браузері обмежений однопотоковим виконанням, тому важливо не блокувати UI.

Безпека і приватність

• Публікація через брокер може включати аутентифікацію та авторизацію.
• У браузері EventTarget не передає приватні дані, якщо вони не вказані явно.

Особливості у контексті фреймворків

• Angular: EventEmitter у компонентах.
• NestJS: @Injectable() з RxJS Observable для сервісів.
• Next.js: useEffect + EventSource для SSE (Server‑Sent Events).

Оптимізація, типові помилки та edge cases

• Не забувайте видаляти підписки (unsubscribe) у componentWillUnmount або useEffect cleanup.
• У Pub/Sub перевіряйте, що брокер підтримує потрібний рівень доставки (at‑least‑once vs. exactly‑once).

Диагностика і отладка

• Перевірте, що підписник реєструється до моменту публікації.
• Використовуйте console.log або DevTools для відстеження подій.

Альтернативи, порівняння

• Observer vs. Pub/Sub: Observer – пряме спостереження, Pub/Sub – розподілене повідомлення.
• EventEmitter vs. RxJS: EventEmitter простий, RxJS надає оператори для складної обробки.

Крайні випадки і часті помилки

1. Підписник не видаляється → memory leak.
2. Брокер недоступний → повідомлення втрачаються.
3. Підписник отримує старі дані → кешування без очищення.
4. Перевантаження підписників → throttling або debounce потрібні.
5. Несинхронність між видавцем і підписником → використання async/await.
6. Підписник отримує помилку → обробка через catch у RxJS.
7. Підписник отримує duplicate → використання distinctUntilChanged.
8. Публікація в циклі → перевірка на рекурсію.

Повне пояснення

Що це і навіщо

• fetch‑listener – це обробник події у Service Worker, який реагує на кожен HTTP‑запит, що надходить з веб‑сторінки.
• Його основна мета – забезпечити контроль над мережевим трафіком: кешування, модифікація запитів/відповідей, офлайн‑режим, аутентифікація тощо.

Ключові принципи/терміни

• Service Worker – background‑скрипт, що працює окремо від UI.
• event.request – об’єкт Request, що містить URL, метод, заголовки.
• event.respondWith() – спосіб повернути власну Response.

Як це працює

1. Коли сторінка робить fetch, браузер передає запит Service Worker.
2. Listener виконується, отримує event з request і respondWith.
3. Можна перевірити кеш, змінити заголовки або відправити новий запит.

Практика і реалізація (JavaScript)

self.addEventListener('fetch', event => {
  const url = new URL(event.request.url);
  if (url.pathname.startsWith('/api/')) {
    event.respondWith(fetch(event.request)); // просто проксі
  } else {
    event.respondWith(caches.match(event.request).then(res => res || fetch(event.request)));
  }
});

Тестування – можна використовувати jest з service-worker-mock або workbox-build для генерації моків.

Безпека – переконайтеся, що не передаєте конфіденційні дані у заголовках без шифрування, і обмежте доступ до API за допомогою CORS.

Оптимізація – кешуйте статичні ресурси, використовуйте Cache First або Network First політики залежно від типу контенту.

Часті помилки – забуваєте викликати event.respondWith(), що призводить до блокування запиту; не перевіряєте event.request.mode для CORS‑запитів.

Чеклист діагностики

• Симптом: запити не виконуються.
• Причина: respondWith не викликано або повертається неправильний Response.
• Дія: перевірити логіку у listener‑і, додати console.log(event.request.url).

Альтернативи – можна використовувати проксі‑сервер (наприклад, Nginx) або бібліотеку axios з інтерцепторами для клієнтської частини, але Service Worker дає контроль на рівні браузера без мережевих налаштувань.

Повне пояснення

Що це і навіщо Event loop — внутрішній цикл, що забезпечує неблокуючий I/O в JavaScript‑руші. Він дозволяє виконувати асинхронні операції без блокування головного потоку.

Ключові принципи/терміни

• Macro-task queue – черга макрозадач (setTimeout, setInterval, I/O callbacks).
• Micro-task queue – черга мікрозадач (Promise handlers, process.nextTick, MutationObserver).
• Execution stack – стек викликів.

Як це працює

1. Стек викликів очищується.
2. Якщо мікрозадачі в черзі, вони виконуються послідовно.
3. Після порожнього мікрозадачного черги, береться наступна макрозадача.
4. Повторюється крок 1.

Практика і реалізація (JS/TS)

async function fetchData() {
  const data = await fetch('/api'); // Promise → micro-task
  console.log(data);
}
setTimeout(fetchData, 0); // macro-task

Тестування

• Jest/Vitest: await Promise.resolve(); перевіряє, що мікрозадачі виконуються.
• Playwright: page.waitForTimeout(0) демонструє макрозадачу.

Дизайн‑рішення

• Використання queueMicrotask замість setTimeout(fn,0) для швидших мікрозадач.
• У NestJS async/await автоматично розміщує обробку у мікрозадачі.

Оптимізація та edge cases

• Надмірна кількість мікрозадач може блокувати макрозадачі → розбивайте логіку.
• setImmediate (Node.js) – альтернативна макрозадача після мікрозадач.

Часті помилки

• Очікування Promise.resolve() без await → мікрозадача не завершується.
• Використання setTimeout(fn,0) замість мікрозадачі → зайве затримання.

Cheatsheet

• Promise.resolve().then(fn) → мікрозадача.
• setTimeout(fn,0) → макрозадача.
• queueMicrotask(fn) → мікрозадача (Node.js, браузер).

Повне пояснення

Що це і навіщо

Code coverage вимірює, який відсоток рядків, умов чи шляхів у коді виконується під час запуску тестів. Це допомагає оцінити, наскільки повно тестовий набір охоплює логіку програми.

Ключові принципи

• Line coverage – кількість виконаних рядків.
• Branch coverage – охоплення усіх гілок умов (if/else, switch).
• Function coverage – виконання всіх функцій.

Як це працює

Тестовий runner (наприклад, Jest) підключає інструмент збірки коду (babel/tsc), вставляє трекери у виконуваний код, а потім під час тестування збирає статистику. Після завершення генерується звіт у форматі HTML, LCOV тощо.

Практика і реалізація

// jest.config.js
module.exports = {
  collectCoverage: true,
  coverageDirectory: 'coverage',
};

Запуск:

npm test -- --coverage

Тестування

• Unit – перевірка окремих функцій.
• Integration – тестування взаємодії між модулями.
• E2E – повний сценарій користувача (наприклад, Playwright).

Безпека і приватність

Покриття не гарантує відсутності вразливостей. Важливо тестувати edge‑case, наприклад, некоректні вхідні дані.

Особливості у контексті JavaScript/TypeScript

• TypeScript‑компілятор генерує мапи source map, що полегшують трасування.
• Для React‑компонентів корисно використовувати react-testing-library з jest-dom.

Оптимізація

• Не треба прагнути 100 %; фокус на критичних шляхах.
• Використовуйте --coverageThreshold для мінімальних порогів.

Часті помилки

1. Підрахунок лише рядків – ігнорує гілки.
2. Неправильні source maps – помилкові лінії у звіті.
3. Тестування лише позитивних сценаріїв – пропускає edge‑case.
4. Відсутність coverageDirectory – звіт зникає після CI.
5. Невикористання threshold – не виявляє падіння покриття.
6. Тестування у продакшн‑середовищі – може бути повільним.
7. Занадто багато моків – знижує реальність тесту.
8. Невідповідність версій Jest і Babel – помилки збірки.

Cheatsheet

• npm test -- --coverage – запуск з збіркою покриття.
• --coverageThreshold – встановлення мінімальних порогів.
• jest --watchAll – автоматичне оновлення при зміні коду.

Follow‑up питання

• Які типи покриття існують і коли їх використовувати?
• Як інтегрувати coverage у CI/CD pipeline?

Повне пояснення

Що це і навіщо Клієнт (frontend) взаємодіє з сервером через мережу, надсилаючи HTTP‑запити і отримуючи відповіді. Це основний механізм обміну даними між користувачем і бекендом.

Ключові принципи/терміни

• HTTP request / response – протокол, що визначає структуру запиту і відповіді.
• REST / GraphQL – стилі API, що впливають на формат запитів.
• CORS – політика крос‑доменної взаємодії, що обмежує доступ.

Як це працює

1. Клієнт формує запит (URL, метод, заголовки, тіло).
2. Запит надсилається через TCP‑соединення до сервера.
3. Сервер обробляє логіку, звертається до БД, формує відповідь.
4. Сервер повертає HTTP‑статус і тіло (JSON, HTML, XML).
5. Клієнт парсить відповідь і оновлює UI.

Практика та реалізація (JavaScript/TypeScript)

// fetch приклад
const res = await fetch('/api/users', {
  method: 'GET',
  headers: { 'Accept': 'application/json' }
});
const data = await res.json();

// axios приклад
import axios from 'axios';
const { data } = await axios.post('/api/login', {
  email, password
});

Тестування

• Unit: мокати fetch/axios за допомогою jest‑mock.
• Integration: Supertest + Jest для тестування реального API.
• E2E: Playwright, Cypress – симулюють повний цикл клієнт‑сервер.

Безпека та приватність

• HTTPS – шифрує трафік.
• JWT / OAuth2 – авторизація.
• Input validation – запобігає SQL‑ін’єкціям, XSS.

Оптимізація

• Cache‑контроль (ETag, Cache‑Control) – зменшує кількість запитів.
• Lazy loading – завантажує дані лише при потребі.

Часті помилки

1. Невірний CORS‑заголовок → 403.
2. Необроблений Promise → uncaught rejection.
3. Перевантаження API – rate‑limit.
4. Поганий JSON‑парсинг → SyntaxError.

Cheatsheet

• fetch(url, {method, headers, body})
• axios.get/post/put/delete(url, data)
• response.ok → статус 200‑299.

Follow‑up питання

• Як реалізувати WebSocket‑комунікацію?
• Які переваги REST над GraphQL?

Повне пояснення

Що це і навіщо

• Функціональне програмування (FP) — парадигма, що підкреслює використання чистих функцій і незмінності даних. Це зменшує кількість помилок, пов’язаних із станом, і полегшує паралельне виконання.

Ключові принципи

• Чисті функції: однаковий вхід → однаковий вихід, без побічних ефектів.
• Неперемінність: об’єкти/масиви не змінюються, створюється новий екземпляр.
• Функції‑вищого порядку: функція приймає іншу функцію як аргумент або повертає її.
• Рекурсія: замість циклів часто використовується рекурсивний виклик.

Як це працює

• Дані проходять через послідовність функцій, кожна з яких повертає новий результат. Це створює ланцюжок «потоку» даних.
• Приклад: const doubled = nums.map(n => n * 2); const sum = doubled.reduce((a,b)=>a+b,0); – map створює новий масив без зміни оригіналу, а reduce агрегує значення.

Практика і реалізація (JavaScript/TypeScript)

• Використання Array.prototype.map, filter, reduce.
• Створення функцій‑вищого порядку: const withLogging = fn => (...args) => { console.log(args); return fn(...args); }.
• Застосування Object.freeze або бібліотек типу Immutable.js для забезпечення незмінності.

Тестування

• Чисті функції легко тестувати: expect(add(2,3)).toBe(5);.
• Використання Jest або Vitest для unit‑тестів.

Безпека та приватність

• Відсутність побічних ефектів зменшує ризик непередбачуваних змін стану, що важливо при роботі з конфіденційними даними.

Оптимізація та edge‑cases

• Пам’ять: рекурсія може викликати переповнення стеку; використовуйте хвостову рекурсію або ітеративні підходи.
• Паралелізм: FP легко комбінувати з Promise.all або Web Workers.

Часті помилки

• Зміна оригінальних об’єктів замість створення копій.
• Використання глобального стану всередині чистих функцій.

Cheatsheet

• map – трансформує масив.
• filter – відбирає елементи.
• reduce – агрегує.
• compose(f,g) – виконує f(g(x)).

Повне пояснення

Що це і навіщо TDD (Test‑Driven Development) – метод розробки, де тест створюється до коду. BDD (Behavior‑Driven Development) – розширення TDD, що описує поведінку через сценарії користувача.

Ключові принципи

• Red‑Green‑Refactor: спочатку тест падає (red), потім код проходить (green), після чого рефакторинг.
• Покриття: тест охоплює всі граничні випадки і помилки.
• Документація: тест сам по собі описує вимоги.

Як це працює

1. Написати тест, що описує бажану поведінку.
2. Запустити тест – він падає.
3. Реалізувати мінімальний код, щоб пройти тест.
4. Перевірити, що всі тести проходять.
5. Рефакторинг коду без зміни поведінки.

Практика і реалізація (JavaScript/TypeScript)

// BDD‑сценарій з Jest
describe('User login', () => {
  it('should authenticate valid credentials', async () => {
    const res = await login({email: 'a@b.com', pwd: '123'});
    expect(res.success).toBe(true);
  });
});

Тестування

• Unit: Jest, Vitest.
• Integration: Supertest для API.
• E2E: Playwright, Cypress.

Безпека і приватність Тести перевіряють, що паролі не зберігаються у відкритому вигляді і що API відповідає на CSRF‑запити.

Оптимізація і типові помилки

• Перевантаження тестів: фокус на критичних шляхах.
• Залежність від зовнішніх сервісів: використання моків.

Часті помилки

1. Тест не охоплює граничних значень.
2. Тест залежить від порядку виконання.
3. Неправильне використання моків, що призводить до «зелених» тестів.

Cheatsheet

• TDD: test → code → refactor.
• BDD: scenario → step → outcome.

Follow‑up питання

1. Як впровадити TDD у великий проект?
2. Які інструменти найкраще підходять для BDD у Node.js?

Повне пояснення

Що це і навіщо HTTPS — захищений варіант HTTP, що забезпечує конфіденційність і цілісність даних між клієнтом і сервером. Використовується для онлайн‑банкінгу, e‑комерції та будь‑яких додатків, де потрібна безпека.

Ключові принципи/терміни

• TLS (Transport Layer Security) – протокол шифрування, що замінює SSL.
• Handshake – процес узгодження криптографічних параметрів.
• Certificate Authority (CA) – орган, що видає цифрові сертифікати.
• Public/Private key – пара ключів для шифрування і підпису.

Як це працює

1. TCP‑з’єднання: клієнт відкриває TCP‑соединение на порт 443.
2. TLS‑handshake: клієнт запитує сертифікат сервера, перевіряє його підпис CA, обирає алгоритм шифрування і генерує симетричний ключ.
3. HTTP‑запит: після успішного handshake клієнт надсилає HTTP‑запит, зашифрований симетричним ключем.
4. HTTP‑response: сервер розшифровує запит, обробляє його і повертає зашифрований відповідь.
5. Закриття: при завершенні сесії обидві сторони закривають TLS‑канал.

Практика і реалізація (JavaScript/TypeScript)

import https from 'https';
const options = { hostname: 'example.com', port: 443, path: '/', method: 'GET' };
const req = https.request(options, res => {
  console.log(`statusCode: ${res.statusCode}`);
});
req.end();

Тестування

• Unit: перевірка функції, що генерує TLS‑options.
• Integration: використання supertest з https сервером.
• E2E: Playwright для перевірки HTTPS‑з’єднання через браузер.

Безпека і приватність

• Валідація сертифікатів: перевірка CN, SAN і дати дії.
• Перевага HSTS (HTTP Strict Transport Security) для примусової HTTPS‑з’єднання.
• Захист від CRIME/BREACH: використання TLS 1.3.

Оптимізація і масштабування

• TLS‑session resumption: Session ID або Ticket для зменшення накладних витрат.
• HTTP/2: мультиплексування запитів над одним TLS‑каналом.

Часті помилки і edge cases

1. Невірний сертифікат → ERR_CERT_AUTHORITY_INVALID.
2. Відсутність підтримки TLS 1.3 → ERR_SSL_VERSION_OR_CIPHER_MISMATCH.
3. Перевищення часу handshake → ERR_SSL_CLIENT_AUTH_CERT_NEEDED.
4. Підключення через проксі без CONNECT → ERR_SSL_PROTOCOL_ERROR.

Діагностика

• OpenSSL s_client: openssl s_client -connect example.com:443.
• Wireshark: перевірка TLS‑handshake.
• Browser DevTools: вкладка Security для перегляду сертифікату.

Альтернативи

• HTTP/3 (QUIC): UDP‑базований протокол, що підтримує TLS 1.3.
• mTLS: двостороннє аутентифікація для сервіс‑на‑сервіс комунікації.

Повне пояснення

Що це і навіщо

• Клон відомого проєкту – це реплікація функціоналу та UI іншої системи. Вибір технологій визначає швидкість розробки, підтримку типів і масштабованість.

Ключові принципи/терміни

• Next.js 14/15 – React‑framework з SSR, SSG і рутингом.
• React – компонентна архітектура.
• TypeScript – статична типізація, зменшує runtime‑помилки.
• Redux Toolkit – простий спосіб керувати глобальним станом.
• Tailwind CSS – utility‑first, швидка розробка стилів.
• Prisma + PostgreSQL – ORM і реляційна БД, що підтримує типобезпечність.

Як це працює

1. Next.js генерує сторінки на сервері (SSR) або статично (SSG).
2. React‑компоненти отримують дані через API роутери Next.js, що використовують Prisma для доступу до PostgreSQL.
3. Redux Toolkit обробляє локальний та глобальний стан, забезпечуючи реактивність.
4. Tailwind CSS застосовується через класові утиліти, що зменшує час розробки стилів.

Практика і реалізація

• Створення проекту: npm create next-app@latest my-clone --ts.
• Ініціалізація Prisma: npx prisma init і налаштування схеми.
• Додавання Redux Toolkit: npm i @reduxjs/toolkit react-redux і створення slice.
• Використання Tailwind: npm i -D tailwindcss postcss autoprefixer і конфігурація.

Тестування

• Unit: Jest + React Testing Library для компонентів.
• Integration: Vitest з @testing-library/react для роутерів.
• E2E: Playwright для тестування повного потоку користувача.

// example test with Vitest
import { render, screen } from '@testing-library/react';
import Home from '@/pages/index';

test('renders welcome message', () => {
  render(<Home />);
  expect(screen.getByText(/Welcome/i)).toBeInTheDocument();
});

Безпека і приватність

• Використання next-auth для аутентифікації.
• Захист API роутів через middleware.
• Prisma забезпечує параметризовані запити, що зменшує SQL‑ін’єкції.

Производительность і масштабування

• SSR/SSG з Next.js мінімізує час до першого контенту.
• Prisma кешує запити, а PostgreSQL підтримує горизонтальне масштабування через реплікацію.

Оптимізація, типові помилки та edge cases

• Не використовуйте any у TypeScript; визначайте типи для API відповідей.
• Уникайте «прямого» доступу до DOM у React; використовуйте useRef.
• Перевіряйте стан під час SSR, щоб уникнути «hydration mismatch».

Диагностика і отладка

• Симптом: «Hydration error» → Причина: різні рендери на сервері і клієнті → Дія: використайте useEffect для асинхронних даних.
• Симптом: «TypeError: Cannot read property…» → Причина: невірний тип даних → Дія: додайте валідацію або ?..

Альтернативи

• Nuxt.js (Vue) – аналог Next.js для Vue.
• SvelteKit – легший, але менш розповсюджений.

Часті помилки

1. Неправильна конфігурація tsconfig.json → TypeScript не компілює.
2. Відсутність getServerSideProps у Next.js → SSR не працює.
3. Перевантаження Redux store → використовуйте createSlice і configureStore.
4. Неправильне використання Tailwind класів → стилі не застосовуються.
5. SQL‑ін’єкція через Prisma → використовуйте параметризовані запити.
6. Необроблені проміси → async/await з try/catch.
7. Відсутність тестів → ризик регресії.
8. Неправильна конфігурація next.config.js → SSR/SSG не працює.

Cheatsheet + follow‑up питання

• Next.js: getStaticProps, getServerSideProps, app router.
• Redux Toolkit: createSlice, configureStore.
• Prisma: prisma.$queryRaw, prisma.user.findMany.
• Tailwind: container, mx-auto, p-4.

Follow‑up: Як забезпечити SSR з аутентифікацією у Next.js?

Повне пояснення

Що це і навіщо

• Рефакторинг старих проектів потрібен, коли технології застаріли або код не підтримується. Це зменшує ризик багів і полегшує майбутню підтримку.

Ключові принципи/терміни

• Branch‑by‑abstraction: створюємо окрему гілку для змін.
• CI/CD: автоматичне тестування і деплой.
• Feature‑flag: тимчасово вимикаємо нові функції, поки не перевіримо.

Як це працює

1. Аналіз – вивчаємо залежності, конфігурації і точки входу.
2. Гілка – git checkout -b feature/refactor.
3. CI/CD – налаштовуємо pipeline (GitHub Actions, GitLab CI) з lint‑ом, unit‑тестами і build‑проектом.
4. Тестування – локальний запуск, unit‑тести, integration‑тести і end‑to‑end (наприклад Cypress).
5. Code review – peer‑review, статичний аналіз (ESLint, SonarQube).
6. Merge – після успішного тестування і review, merge у main.

Практика та реалізація

// Приклад NestJS сервісу
@Injectable()
export class UserService {
  async findAll(): Promise<User[]> { return this.userRepo.find(); }
}

// React компонент з TypeScript
const UserList: FC = () => {
  const [users, setUsers] = useState<User[]>([]);
  useEffect(() => fetch('/api/users').then(r=>r.json()).then(setUsers), []);
  return <ul>{users.map(u => <li key={u.id}>{u.name}</li>)}</ul>;
};

Тестування

• Unit: Jest + ts-jest.
• Integration: Supertest для NestJS, React Testing Library.
• E2E: Cypress або Playwright.

Дизайн‑рішення і моделі даних

• Використовуємо DTO‑и для валідації (class-validator).
• Маппінг між DB і DTO через TypeORM або Prisma.

Производительность и масштабирование

• Кешування (Redis) для часто запитуваних даних.
• Паралельні процеси через worker‑pool (BullMQ).

Безпека і приватність

• JWT/OPA для авторизації.
• CSRF‑захист, CORS‑policy.
• Валідація вхідних даних через class-validator.

Оптимізація, типові помилки та edge cases

• Не забувайте про async/await у NestJS, щоб уникнути «callback hell».
• Перевіряйте null/undefined перед доступом до властивостей.
• Уникайте глобальних змінних, що можуть викликати race‑conditions.

Диагностика и отладка

• Симптом: помилка «Cannot read property…» → перевірте, чи існує об’єкт.
• Причина: неправильний шлях до модуля або неініціалізований state.
• Дія: додайте console.log або використовуйте VSCode debugger.

Альтернативи

• Якщо проект надто застарілий, розгляньте миграцію до Next.js 15 з TypeScript.
• Для швидкого прототипу можна використати Remix або Astro.

Часті помилки (8+):

1. Не оновлюєте package.json → залежності залишаються застарілими.
2. Відсутність tsconfig.json → TypeScript не компілює.
3. Занадто довгі гілки → конфлікти при merge.
4. Відсутність CI → баги потрапляють у продакшн.
5. Неправильна конфігурація tsconfig-paths → помилки імпорту.
6. Не тестуєте edge cases → непередбачувані crash‑и.
7. Відсутність eslint → код не стандартизований.
8. Не використовуєте dotenv → конфіденційні дані в коді.

Cheatsheet + follow‑up питання

• Чому важливо CI/CD? → автоматизує тестування і зменшує людські помилки.
• Як уникнути merge‑конфліктів? → короткі гілки, часті pull‑requests.
• Що робити при великому refactor? → розбивайте на малі, перевіряйте кожен крок.

Повне пояснення

Що це і навіщо Next.js 14 – фреймворк, що об’єднує серверний рендеринг (SSR), статичну генерацію сторінок (SSG) і клієнтський рендеринг у одному React‑проєкті. Він підвищує продуктивність, полегшує SEO і забезпечує швидку розробку.

Ключові принципи/терміни

• SSR / SSG – серверний рендеринг і статична генерація.
• React – бібліотека для побудови UI.
• TypeScript – статична типізація, що зменшує кількість runtime‑помилок.
• File‑based routing – маршрутизація за файловою структурою.

Як це працює

1. При запиті сервер рендерить компонент, повертаючи готовий HTML.
2. Після завантаження клієнтський JavaScript «підключається» (hydration).
3. Для SSG сторінки генеруються під час збірки і розміщуються як статичні файли.

Практика та реалізація (JS/TS)

// app/page.tsx – простий компонент
export default function Home() {
  return <h1>Привіт, Next.js!</h1>;
}

// middleware.ts – глобальний перехоплювач
import { NextResponse } from 'next/server';
export function middleware(request) {
  return NextResponse.next();
}

Тестування

• Jest + React Testing Library для юніт‑тестів компонент.
• Playwright для end‑to‑end тестування маршруту.

import { test, expect } from '@playwright/test';

test('home page loads', async ({ page }) => {
  await page.goto('/');
  expect(await page.textContent('h1')).toBe('Привіт, Next.js!');
});

Дизайн‑рішення та моделі даних

• Використання React Query або SWR для кешування даних.
• API‑роутинг через app/api/* з підтримкою JSON.

Производительность і масштабування

• Вбудований Image Optimization.
• Підтримка Incremental Static Regeneration (ISR) для оновлення сторінок без повної збірки.

Безпека і приватність

• Middleware для аутентифікації.
• Захист CSRF через заголовки XSRF-TOKEN.

Фактори вибору фреймворку

1. Технічні вимоги – SSR/SSG, SEO, TypeScript.
2. Командний досвід – знання React і Node.js.
3. Екосистема – підтримка бібліотек, плагінів і спільноти.
4. Термін розробки – швидка поставка MVP.
5. Масштабування – можливість горизонтального масштабування через Vercel, Netlify або власний VPS.

Часті помилки та edge cases

• Необхідність правильно налаштувати next.config.js для кастомних роутів.
• Перевірка типу undefined у серверних функціях, щоб уникнути runtime‑помилок.
• Забезпечення кешування даних у SSR, щоб уникнути дублювання запитів.

Cheatsheet

• npm create next-app@latest – створення нового проєкту.
• next dev – локальний сервер.
• next build && next start – продакшн збірка.

Follow‑up питання

• Як реалізувати SSR з Auth0 у Next.js?
• Які переваги ISR порівняно з традиційним SSG?

Повне пояснення

Що це і навіщо V8 – рушій, що перетворює JavaScript‑код у машинний байткод і виконує його з максимальною швидкістю. Його застосовують у браузері Chrome, серверному середовищі Node.js та в багатьох інших проектах.

Ключові принципи

• JIT‑компіляція (Just‑In‑Time) для швидкого виконання.
• Підтримка ECMAScript‑стандарту, включаючи нові фічі.
• Оптимізація пам’яті через збірник сміття (garbage collector).

Як працює

1. Парсер перетворює код у синтаксичне дерево.
2. Бінарний компілятор генерує байткод, що потім трансформується у машинний інструкційний код.
3. Під час виконання JIT‑компілятор оптимізує частіші шляхи.

Практика і реалізація (JS/TS)

import { getHeapStatistics } from 'v8';
console.log(getHeapStatistics());

Тестування

• Unit: перевірка функцій, що взаємодіють з V8 API.
• Integration: запуск скриптів у Node.js і вимірювання часу виконання за допомогою performance.now().

Безпека і приватність

• Відокремлення процесів у Node.js за допомогою worker_threads.
• Обмеження доступу до глобальних об’єктів через sandbox‑механізми.

Альтернативи

• SpiderMonkey (Firefox), JavaScriptCore (Safari). Вони мають подібну архітектуру, але різні оптимізації й API.

Часті помилки

• Перевантаження пам’яті через великі об’єкти без очищення.
• Використання синхронних API у асинхронному коді, що призводить до блокування event loop.