Реактивність є основою багатьох сучасних фреймворків, таких як Vue.js, Svelte та навіть внутрішніх механізмів React. Вона дозволяє автоматично оновлювати UI, коли змінюється стан.
Одним з найефективніших способів створення реактивних об’єктів у JavaScript є Proxy API та Reflect API. У цій статті ми розглянемо, як вони працюють, чому вони краще за Object.defineProperty, та як їх можна використати для створення власного простого реактивного механізму.
Об’єкт Proxy дозволяє перехоплювати операції над іншими об’єктами (наприклад, отримання, встановлення, видалення властивостей) та змінювати їхню поведінку.
const obj = { name: "Alice" };
const proxy = new Proxy(obj, {
get(target, property) {
console.log(`Отримання значення ${property}`);
return target[property];
},
set(target, property, value) {
console.log(`Зміна ${property} на ${value}`);
target[property] = value;
return true;
}
});
console.log(proxy.name); // Лог: Отримання значення name
proxy.age = 25; // Лог: Зміна age на 25
Reflect – це набір утиліт, який спрощує роботу з об’єктами, даючи змогу безпечно виконувати операції (get, set, deleteProperty тощо).
const obj = { name: "Alice" };
console.log(Reflect.get(obj, "name")); // Alice
Reflect.set(obj, "age", 25);
console.log(obj.age); // 25
Reflect часто використовується разом із Proxy, щоб делегувати стандартну поведінку, не переписуючи її вручну.
До появи Proxy для реактивності використовували Object.defineProperty, але цей підхід має обмеження:
Object.defineProperty працює тільки з окремими властивостями, а Proxy дозволяє працювати з цілим об’єктом.Object.defineProperty не працює з масивами так само ефективно, як Proxy.Приклад проблеми з Object.defineProperty:
const obj = {};
Object.defineProperty(obj, "name", {
get() {
console.log("Отримання значення");
return "Alice";
},
set(value) {
console.log("Зміна значення");
}
});
obj.name = "Bob"; // Лог: Зміна значення
console.log(obj.name); // Лог: Отримання значення
delete obj.name; // ❌ Не працює – не можна відстежити видалення властивостей
З Proxy ми можемо легко відстежувати всі зміни.
Створимо базовий механізм, який дозволить відстежувати зміни у стані та викликати відповідні функції при оновленні значень.
function reactive(target) {
const subscribers = new Set(); // Зберігаємо функції, які реагують на зміни
const notify = () => {
subscribers.forEach(subscriber => subscriber());
};
return new Proxy(target, {
get(obj, prop) {
console.log(`Отримання значення ${prop}`);
return Reflect.get(obj, prop);
},
set(obj, prop, value) {
console.log(`Зміна ${prop} на ${value}`);
Reflect.set(obj, prop, value);
notify(); // Викликаємо підписників після зміни
return true;
},
deleteProperty(obj, prop) {
console.log(`Видалення ${prop}`);
Reflect.deleteProperty(obj, prop);
notify();
return true;
},
subscribe(fn) {
subscribers.add(fn);
}
});
}
// Використання
const state = reactive({ count: 0 });
const render = () => console.log(`Рендер: count = ${state.count}`);
state.subscribe(render); // Підписуємо рендер-функцію
state.count = 1; // Лог: Зміна count на 1 → Рендер: count = 1
state.count = 2; // Лог: Зміна count на 2 → Рендер: count = 2
delete state.count; // Лог: Видалення count → Рендер: count = undefined
Масиви у JavaScript є об’єктами, тому Proxy може працювати з ними аналогічно.
const reactiveArray = reactive([]);
reactiveArray.subscribe(() => console.log("Масив змінено:", reactiveArray));
reactiveArray.push("React"); // Масив змінено: ["React"]
reactiveArray.push("Vue"); // Масив змінено: ["React", "Vue"]
reactiveArray.pop(); // Масив змінено: ["React"]
length у масивахПри видаленні елемента length масиву змінюється, що теж можна перехопити:
const arrayHandler = {
set(target, prop, value) {
console.log(`Зміна ${prop} на ${value}`);
return Reflect.set(target, prop, value);
}
};
const reactiveNumbers = new Proxy([1, 2, 3], arrayHandler);
reactiveNumbers.push(4); // Лог: Зміна 3 на 4, Зміна length на 4
reactiveNumbers.length = 2; // Лог: Зміна length на 2 (всі зайві елементи видаляться)
console.log(reactiveNumbers); // [1, 2]
Тепер давайте зробимо зв’язок між станом і HTML, щоб створити базову реактивність.
<!DOCTYPE html>
<html lang="uk">
<head>
<title>Реактивний лічильник</title>
</head>
<body>
<p id="counter">Лічильник: 0</p>
<button id="increment">Збільшити</button>
<script>
function reactive(target, render) {
return new Proxy(target, {
set(obj, prop, value) {
obj[prop] = value;
render();
return true;
}
});
}
const state = reactive({ count: 0 }, () => {
document.getElementById("counter").innerText = `Лічильник: ${state.count}`;
});
document.getElementById("increment").addEventListener("click", () => {
state.count++;
});
</script>
</body>
</html>
✅ Що ми зробили?
state.<p id="counter"> змінюється при оновленні count).click, яка змінює стан.🚀 Вийшов міні-VueJS без фреймворків!
Proxy та Reflect дають змогу створювати потужні механізми реактивності без зайвих складнощів.
✔ Proxy дозволяє перехоплювати всі операції з об’єктами.
✔ Reflect допомагає зручно делегувати стандартну поведінку.
✔ Реактивні об’єкти можна використовувати в UI, автоматично оновлюючи DOM.
✔ Масиви також можна зробити реактивними через Proxy.
💡 Proxy – це основа багатьох сучасних фреймворків, і розуміння його механіки допоможе вам глибше зрозуміти Vue, Svelte та навіть внутрішні механізми React. 🚀
Світ веб-технологій динамічно змінюється. Якщо Web1 був ерою статичних сайтів, а Web2 — ерою соціальних мереж, централізованих платформ і динамічного контенту, то Web3 пропонує децентралізовану альтернативу, засновану на блокчейні, смарт-контрактах і криптовалютах.
Але чи реально Web3 замінить Web2 у стандартних завданнях, таких як пошук інформації, платежі, зберігання файлів чи управління ідентифікацією? Чи це просто модний тренд без реальних переваг? Давайте розберемося.
📌 Web2 – це нинішній інтернет, де більшість сервісів контролюється великими компаніями (Google, Facebook, Amazon). Вони керують нашими даними, контролюють платформи та встановлюють правила гри.
📌 Web3 – це концепція децентралізованого інтернету, де користувачі контролюють свої дані та взаємодіють один з одним без посередників. Основні технології Web3:
✔ Блокчейн – децентралізоване зберігання та перевірка транзакцій.
✔ Смарт-контракти – автоматизовані угоди без потреби в довірених третіх особах.
✔ DApps (децентралізовані додатки) – додатки, що працюють на блокчейні.
✔ Децентралізовані ідентифікації (DID) – методи входу без паролів, через криптовалютні гаманці.
🚀 Головна ідея Web3: ніяких посередників, більше свободи для користувачів.
Але чи це працює в реальних завданнях?
У Web2 всі транзакції проходять через банки, PayPal, Visa або Mastercard. Вони контролюють платежі, можуть блокувати рахунки або стягувати високі комісії.
✅ Web3 рішення:
❌ Проблеми:
📢 Вердикт: Web3 поки що не може повністю замінити банківські системи, але криптовалюти можуть бути вигідним доповненням у міжнародних переказах та DeFi-сервісах.
Зараз більшість користувачів зберігають файли у централізованих хмарах (Google Drive, iCloud, Dropbox).
✅ Web3 рішення:
❌ Проблеми:
📢 Вердикт: Web3-зберігання має потенціал, але поки що Web2 рішення швидші, дешевші та зручніші для масового користувача.
Централізовані соцмережі контролюють контент, можуть блокувати користувачів, продають дані рекламодавцям.
✅ Web3 рішення:
❌ Проблеми:
📢 Вердикт: Web3-соцмережі ще не готові замінити Facebook та Twitter, але вони можуть стати нішевими альтернативами.
Зараз люди реєструються на сайтах через Google чи Facebook, віддаючи свої дані компаніям.
✅ Web3 рішення:
❌ Проблеми:
📢 Вердикт: Web3-ідентифікація цікава, але Google/Facebook авторизація залишається зручнішою для більшості користувачів.
🔹 Web3 має переваги у безпеці, конфіденційності та децентралізації, але він ще не готовий повністю замінити Web2.
🔹 Більшість Web3-рішень повільніші, дорожчі та складніші у використанні для масового ринку.
🔹 Проте Web3 додає альтернативу, дозволяючи користувачам обирати між централізованими та децентралізованими сервісами.
💡 Web2 і Web3, ймовірно, співіснуватимуть – Web2 залишиться основою для звичайних користувачів, а Web3 буде активно використовуватись у фінансах, цифровій ідентифікації та зберіганні цінних даних.
🚀 Web3 – це не заміна Web2, а його доповнення.
Можливо, через 10 років ми навіть не помітимо, як Web3 стане стандартом у багатьох сферах, але поки що він проходить стадію активного розвитку.
| Завдання | Web2 рішення | Web3 альтернатива | Чи варто переходити? |
|---|---|---|---|
| Платежі | Банки, PayPal | Криптовалюти, DeFi | ✅ Якщо потрібні миттєві глобальні транзакції |
| Зберігання файлів | Google Drive, Dropbox | IPFS, Arweave, Filecoin | ❌ Поки що Web2 дешевше та швидше |
| Соцмережі | Facebook, Twitter | Lens, Steemit | ❌ Web3-соцмережі ще не готові |
| Ідентифікація | Google Login | ENS, DID | ✅ Якщо потрібно більше приватності |
Web3 – це потужний тренд, але поки що він не готовий повністю замінити Web2.
Проте, як тільки децентралізовані сервіси стануть простішими, швидшими та дешевшими, майбутнє інтернету може змінитися назавжди. 🚀
Криптовалютний ринок відомий своєю високою волатильністю, різкими ціновими коливаннями та нестабільністю. Для ефективного трейдингу тут важливо використовувати чіткі правила входу та виходу з позицій, щоб мінімізувати ризики та отримати максимальний прибуток. Одна з найвідоміших стратегій, яка успішно працювала на традиційних фінансових ринках, – “Стратегія черепах” (Turtle Trading Strategy).
Ця стратегія була розроблена ще у 1980-х роках для ф’ючерсних ринків, але чи працює вона у світі криптовалют? У цій статті ми розглянемо основні принципи стратегії черепах, її адаптацію для цифрових активів, а також конкретні приклади її застосування на Bitcoin, Ethereum та інших криптовалютах.
Стратегія “Черепах” була створена Річардом Деннісом та Вільямом Екхардтом, які хотіли довести, що трейдинг – це навик, якому можна навчитися. Вони відібрали групу людей без досвіду у фінансах, навчили їх певним правилам торгівлі і через рік отримали професійних трейдерів, які успішно заробляли на ринку.
Річард Денніс порівнював трейдерів зі зростанням черепах у фермерському господарстві – якщо забезпечити їм правильні умови, вони будуть рости та приносити прибуток. Тому він навчав трейдерів як “вирощувати” прибуткові угоди.
Криптовалютний ринок суттєво відрізняється від традиційних ринків:
Проте ключові принципи “Черепах” все ще залишаються ефективними, якщо їх правильно адаптувати під реалії криптовалют.
Класична стратегія використовувала 20-денні та 55-денні рівні для входу.
✅ Адаптація для крипторинку:
🔹 Приклад:
Якщо Bitcoin пробиває 50-денний максимум, це сигнал для входу в лонг (купівлю). Якщо пробиває 50-денний мінімум – це сигнал для шорт-позиції (продажу).
import pandas as pd
def turtle_signal(data, period=50):
data['High_Max'] = data['High'].rolling(period).max()
data['Low_Min'] = data['Low'].rolling(period).min()
data['Buy_Signal'] = data['Close'] > data['High_Max'].shift(1)
data['Sell_Signal'] = data['Close'] < data['Low_Min'].shift(1)
return data
✅ ATR (Average True Range) для визначення стоп-лосса
ATR – це індикатор, який вимірює волатильність ринку.
📌 Як встановити стоп-лосс?
Правило: Стоп-лосс = Вхідна ціна – (ATR * 2)
def calculate_stop_loss(entry_price, atr, risk_factor=2):
return entry_price - (atr * risk_factor)
✅ Зменшення розміру позиції на високій волатильності
Якщо ринок “штормить”, краще зменшити обсяг угоди, щоб не отримати величезний збиток.
Якщо тренд продовжується, вигідно використовувати трейлінг-стоп, щоб фіксувати прибуток, не виходячи з ринку завчасно.
📌 Як це працює?
Якщо ціна росте, стоп-лосс “рухається” за нею.
Якщо ціна падає до встановленого рівня – позиція закривається.
✔️ Добре працює у трендових ринках.
✔️ Прозорі правила входу та виходу.
✔️ Дисципліна та відсутність емоційного трейдингу.
❌ Багато фальшивих пробоїв у флеті.
❌ Необхідність жорсткого управління ризиками.
❌ Ринок 24/7 – потрібні автоматизовані алгоритми.
Стратегія “Черепах” може працювати у криптовалютній торгівлі, якщо адаптувати її під високу волатильність та швидкі зміни ринку.
🔹 Якщо ринок трендовий – стратегія приносить прибуток.
🔹 Якщо ринок флетовий – потрібні додаткові фільтри, щоб уникати зайвих входів.
Головне правило – дисципліна. Саме вона зробила “черепах” успішними трейдерами у 1980-х, і саме вона допоможе вам заробляти у криптовалютах сьогодні! 🚀
Керування станом у React — одна з ключових тем для розробників, оскільки додатки стають дедалі складнішими, а їхня архітектура потребує продуманих рішень. Незважаючи на вбудований useState і useReducer, у багатокомпонентних додатках часто виникає необхідність централізованого керування станом. У цій статті ми розглянемо топ-5 бібліотек для керування станом у React, їхні особливості, переваги та коли їх варто використовувати.
🌟 Коли використовувати:
🔹 Основні особливості:
redux-thunk або redux-saga) дозволяють керувати асинхронними запитами.🔸 Мінуси:
🔹 Приклад Redux у дії:
// store.js
import { createStore } from 'redux';
const initialState = { count: 0 };
const counterReducer = (state = initialState, action) => {
switch (action.type) {
case 'INCREMENT':
return { count: state.count + 1 };
case 'DECREMENT':
return { count: state.count - 1 };
default:
return state;
}
};
const store = createStore(counterReducer);
export default store;
// CounterComponent.js
import { useSelector, useDispatch } from 'react-redux';
const CounterComponent = () => {
const count = useSelector((state) => state.count);
const dispatch = useDispatch();
return (
<div>
<p>{count}</p>
<button onClick={() => dispatch({ type: 'INCREMENT' })}>+</button>
<button onClick={() => dispatch({ type: 'DECREMENT' })}>-</button>
</div>
);
};
🌟 Коли використовувати:
🔹 Основні особливості:
🔸 Мінуси:
🔹 Приклад використання:
import create from 'zustand';
const useStore = create((set) => ({
count: 0,
increment: () => set((state) => ({ count: state.count + 1 })),
decrement: () => set((state) => ({ count: state.count - 1 })),
}));
const CounterComponent = () => {
const { count, increment, decrement } = useStore();
return (
<div>
<p>{count}</p>
<button onClick={increment}>+</button>
<button onClick={decrement}>-</button>
</div>
);
};
🌟 Коли використовувати:
🔹 Основні особливості:
🔸 Мінуси:
🔹 Приклад використання:
import { atom, useRecoilState } from 'recoil';
// Створюємо атом (маленький шматочок стану)
const countState = atom({
key: 'countState',
default: 0,
});
const CounterComponent = () => {
const [count, setCount] = useRecoilState(countState);
return (
<div>
<p>{count}</p>
<button onClick={() => setCount(count + 1)}>+</button>
<button onClick={() => setCount(count - 1)}>-</button>
</div>
);
};
🌟 Коли використовувати:
🔹 Основні особливості:
🔸 Мінуси:
🔹 Приклад використання:
import { atom, useAtom } from 'jotai';
const countAtom = atom(0);
const CounterComponent = () => {
const [count, setCount] = useAtom(countAtom);
return (
<div>
<p>{count}</p>
<button onClick={() => setCount(count + 1)}>+</button>
<button onClick={() => setCount(count - 1)}>-</button>
</div>
);
};
🌟 Коли використовувати:
🔹 Основні особливості:
🔸 Мінуси:
🔹 Приклад використання:
import { useQuery } from '@tanstack/react-query';
const fetchUsers = async () => {
const res = await fetch('https://jsonplaceholder.typicode.com/users');
return res.json();
};
const UsersList = () => {
const { data, error, isLoading } = useQuery(['users'], fetchUsers);
if (isLoading) return <p>Loading...</p>;
if (error) return <p>Error loading users</p>;
return (
<ul>
{data.map((user) => (
<li key={user.id}>{user.name}</li>
))}
</ul>
);
};
Обирайте бібліотеку відповідно до завдань вашого проєкту! 🚀
JavaScript — це однопотокова мова програмування, що працює на основі event loop (циклу подій). Це означає, що виконання складних або тривалих обчислень може заблокувати головний потік, зробивши додаток непрацездатним (UI перестане відповідати, а користувачі побачать “зависання”). Тому вкрай важливо правильно ділити тривалі завдання, щоб не порушувати плавність роботи застосунку.
У цій статті ми розглянемо основні способи розбиття довготривалих завдань у JavaScript, їхні переваги та недоліки.
Веб-додатки працюють у середовищі, де кожна задача виконується в основному потоці. Якщо якийсь код займає надто багато часу (наприклад, складні обчислення або обробка великої кількості даних), це блокує подальше виконання подій, включаючи анімації, введення користувача та відповіді на HTTP-запити.
Приклад проблеми:
// Симуляція довготривалої обчислювальної задачі
function longTask() {
let sum = 0;
for (let i = 0; i < 1e9; i++) { // Величезний цикл
sum += i;
}
console.log("Task completed", sum);
}
// Виклик блокує головний потік
longTask();
console.log("Цей код виконається лише після завершення довгої задачі.");
Результат:
Як цього уникнути? Ось кілька основних способів.
setTimeout або setIntervalОдним із простих способів розділити виконання тривалих завдань є розбиття задачі на менші частини та виконання їх у наступних ітераціях циклу подій.
function longTaskChunked() {
let sum = 0;
let i = 0;
function processChunk() {
let start = Date.now();
while (i < 1e9) {
sum += i;
i++;
// Виходимо з циклу, якщо витратили більше 50 мс
if (Date.now() - start > 50) {
console.log("Chunk processed");
setTimeout(processChunk, 0); // Відкладаємо наступну ітерацію
return;
}
}
console.log("Task completed", sum);
}
processChunk();
}
longTaskChunked();
requestIdleCallbackФункція requestIdleCallback дозволяє виконувати задачі, коли браузер має вільний час, тобто між основними подіями.
function longTaskIdle(deadline) {
let sum = 0;
let i = 0;
function processChunk() {
while (i < 1e9 && deadline.timeRemaining() > 0) {
sum += i;
i++;
}
if (i < 1e9) {
requestIdleCallback(processChunk);
} else {
console.log("Task completed", sum);
}
}
requestIdleCallback(processChunk);
}
longTaskIdle();
requestIdleCallback не гарантує виконання задачі в певний час.Web Workers дозволяють виконувати задачі у фоновому потоці, повністю уникаючи блокування головного потоку.
const worker = new Worker("worker.js");
worker.onmessage = function (e) {
console.log("Result from worker:", e.data);
};
worker.postMessage(1e9); // Надсилаємо велику кількість ітерацій
self.onmessage = function (e) {
let sum = 0;
for (let i = 0; i < e.data; i++) {
sum += i;
}
self.postMessage(sum); // Повертаємо результат у головний потік
};
yield у Generator функціяхГенератори (function*) дозволяють створювати “паузи” у виконанні функції, які можна контролювати.
function* longTaskGenerator() {
let sum = 0;
for (let i = 0; i < 1e9; i++) {
sum += i;
if (i % 1e6 === 0) yield; // "Перериваємося" на ітерації
}
return sum;
}
const task = longTaskGenerator();
function processNext() {
const result = task.next();
if (!result.done) {
setTimeout(processNext, 0); // Відкладаємо наступну ітерацію
} else {
console.log("Task completed", result.value);
}
}
processNext();
У JavaScript є кілька підходів до розбиття тривалих завдань:
| Метод | Блокування UI | Багатопоточність | Застосування |
|---|---|---|---|
setTimeout / setInterval |
❌ Ні | ❌ Ні | Дрібні задачі, нескладна обробка |
requestIdleCallback |
❌ Ні | ❌ Ні | Фонові задачі без чітких дедлайнів |
| Web Workers | ❌ Ні | ✅ Так | Тяжкі обчислення, незалежні задачі |
yield + Generator |
❌ Ні | ❌ Ні | Гнучке управління процесом |
setTimeout.requestIdleCallback.yield).Головне — правильний вибір інструменту, адже неправильне використання може призвести до зайвих витрат ресурсів або складнощів у підтримці коду.
Сподіваюся, ця стаття допомогла вам краще розібратися у темі! 🚀
Безпека в інтернеті — це одна з ключових тем, яку не можна ігнорувати. Якщо на сайті передаються важливі дані (наприклад, паролі або платіжна інформація), то безпечний канал зв’язку є критично важливим. SSL (Secure Sockets Layer) і його наступник — TLS (Transport Layer Security) забезпечують захищене з’єднання між клієнтом (браузером) та сервером. У цій статті пояснимо, що таке SSL, чому потрібні SSL-сертифікати та як усе це працює на практиці.
SSL (Secure Sockets Layer) — це криптографічний протокол, який створює захищений канал передачі даних через інтернет. Починаючи з певного часу, SSL-технологія була вдосконалена й формально змінилася на TLS. Однак у щоденному вжитку говорять “SSL” та “TLS” майже як синоніми. Принцип полягає у шифруванні даних та взаємній автентифікації учасників з’єднання, щоб третя сторона (зловмисник) не змогла їх прочитати чи підробити.
Навіщо потрібні SSL-сертифікати
Щоб браузер і сервер домовилися про безпечний канал, потрібен “секрет” — сертифікат, що підтверджує, що даний сервер — дійсно той, за кого себе видає. Користувач бачить “замочок” у адресному рядку (https://) і може бути впевненим, що з’єднання зашифроване.
Типові причини, чому SSL-сертифікати стали стандартом:
Захист даних
Усі дані (паролі, повідомлення, платіжна інформація), що передаються між клієнтом і сервером, стають зашифрованими. Зловмисник, який перехопить трафік, побачить лише набори зашифрованих байтів.
Автентифікація сайту
Сертифікат містить інформацію про домен, організацію, якій цей домен належить. Якщо сертифікат відповідає домену, браузер довіряє з’єднанню.
Поліпшення SEO
Починаючи з певного часу, Google краще оцінює сайти, доступні через HTTPS, у рейтингу пошуку.
Handshake
Створення сесійного ключа
Захищене з’єднання
Приклад (Nginx)
server {
listen 443 ssl;
server_name example.com;
ssl_certificate /etc/ssl/certs/cert.pem;
ssl_certificate_key /etc/ssl/private/key.pem;
location / {
proxy_pass http://localhost:3000;
}
}
Node.js (HTTPS)
const https = require('https');
const fs = require('fs');
const express = require('express');
const app = express();
const options = {
key: fs.readFileSync('key.pem'),
cert: fs.readFileSync('cert.pem')
};
https.createServer(options, app).listen(443, () => {
console.log('HTTPS server running on port 443');
});
Якщо ви вже налаштували TLS, варто розглянути HTTP/2, адже більшість браузерів вмикають HTTP/2 лише при використанні https. HTTP/2 дає мультиплексування, що покращує продуктивність (кілька запитів можуть оброблятися одночасно в межах одного TCP-з’єднання).
SSL (точніше TLS) — фундаментальний механізм захисту даних, який гарантує шифрування й перевірку автентичності домену. Без нього сучасний веб важко уявити, бо весь обмін конфіденційними даними був би небезпечним. Сертифікати можна отримати безкоштовно (Let’s Encrypt) або придбати розширені опції (OV, EV) для більш серйозних проєктів. Налаштування SSL-сертифіката не складне: достатньо згенерувати ключі, налаштувати веб-сервер і переконатись, що домен відповідає конфігурації. У результаті отримуєте https-з’єднання (замочок), підвищений рівень довіри, кращий рейтинг у пошуку та захист даних від прослуховування й атак посередника.
Node.js – це середовище виконання JavaScript, яке, попри однопоточну архітектуру, здатне обробляти велику кількість одночасних з’єднань. Однак бувають ситуації, коли додатку потрібно скористатися додатковим процесом, щоби, наприклад, розпаралелити ресурсоємну задачу, обробити складні обчислення чи забезпечити ізоляцію. У таких випадках актуальною стає проблема обміну даними між процесами. Ця стаття присвячена різним механізмам IPC (Inter-Process Communication – взаємодія між процесами) у Node.js, а також тому, як вони вирішують задачу “зшивання” даних між різними частинами застосунку.
Node.js має вбудовану можливість створювати дочірні процеси для виконання коду. Коли використовується fork(), створений процес має “канал” для обміну повідомленнями з батьківським процесом за допомогою process.send() і child.on('message').
Приклад – просте спілкування між parent.js і child.js.
child.js:
process.on('message', (msg) => {
console.log('Child received:', msg);
process.send({ reply: 'Hello from child' });
});
parent.js:
const { fork } = require('child_process');
const child = fork('./child.js');
child.on('message', (msg) => {
console.log('Parent got message:', msg);
});
child.send({ text: 'Hi child' });
Важливо, що fork() виконує новий JavaScript-файл у окремому процесі, дозволяючи паралельні обчислення і незалежний контекст, а також channel для повідомлень.
Починаючи з Node.js v10.5, з’явився модуль worker_threads, який дозволяє створювати Worker. Вони запускаються у тому самому процесі, проте мають окремий event loop, окрему пам’ять (хоча можна використовувати SharedArrayBuffer). Перевага в тому, що передача об’єктів часто є швидшою, ніж при child_process, і немає overhead створення повноцінного окремого процесу.
Приклад worker.js:
const { parentPort } = require('worker_threads');
parentPort.on('message', (data) => {
// робимо щось із data
parentPort.postMessage(`Worker processed: ${data}`);
});
Головний файл:
const { Worker } = require('worker_threads');
const worker = new Worker('./worker.js');
worker.on('message', (msg) => {
console.log('From worker:', msg);
});
worker.postMessage('Hello from main thread');
Cluster – це модуль, що дозволяє “клонуати” процес Node.js на декілька робочих (worker) процесів, які використовують одну “слухаючу” порт програму. Підходить для створення “pool” процесів, що приймають HTTP-запити, розподіляючи навантаження на всі CPU-ядра.
const cluster = require('cluster');
const http = require('http');
const numCPUs = require('os').cpus().length;
if (cluster.isMaster) {
for (let i = 0; i < numCPUs; i++) {
cluster.fork();
}
cluster.on('exit', (worker) => {
console.log(`Worker ${worker.process.pid} died, forking a new one.`);
cluster.fork();
});
} else {
http.createServer((req, res) => {
res.writeHead(200);
res.end(`Handled by worker ${process.pid}\n`);
}).listen(3000);
}
IPC у cluster
Всі робочі процеси можуть обмінюватись повідомленнями з майстер-процесом (через event worker.on('message')), а майстер може відправляти повідомлення назад worker.send(msg). Це зручно, коли потрібно зберігати якісь глобальні дані, які синхронізуються поміж процесами.
Якщо у вас складна система мікросервісів, Node.js-процеси можуть взагалі не обмежуватись єдиним хостом. Тоді ефективно застосовувати зовнішній брокер повідомлень (Redis Pub/Sub, RabbitMQ, Kafka). Це переходить із рівня локального IPC до рівня мережевого, проте концептуально виконує схожу функцію — обмін даними між процесами.
IPC у Node.js дозволяє писати більш потужні та масштабовані застосунки, оскільки перерозподіляє завдання поміж кількома процесами чи потоками. Вибір інструменту залежить від вашого сценарію:
Правильне налаштування IPC, врахування безпеки, перезапуску при помилках та ефективне передавання даних — все це складається у архітектуру Node-додатків, що можуть обробляти значні навантаження та лишатися стабільними.
React дозволяє створювати інтерфейси, які оновлюються лише тоді, коли дані справді змінюються. Але на практиці трапляються випадки, коли компоненти рендеряться знову й знову, навіть без реальної потреби. Це може знижувати продуктивність, спричиняти “пригальмовування” та сповільнювати відгук додатка. У цій статті зібрано ключові прийоми та концепції, які допоможуть вам ефективно боротися з надлишковими перерендерами і зберігати високу швидкодію UI.
React працює за принципом Virtual DOM, порівнюючи попередній стан з новим та оновлюючи інтерфейс лише там, де відбулися зміни. Але якщо компонент “вважає”, що змінився його проп або стан, відбувається повторний рендер. Якщо таких повторів багато, UI може почати гальмувати. Особливо це помітно у великих таблицях, списках або багаторівневих компонентах.
Анонімні функції та об’єкти у пропсах
Кожного разу при рендері батьківський компонент створює нове посилання (наприклад, () => setState(…)), яке React бачить як “зміна пропів” у дочірнього компонента.
Зміна контексту (Context)
Коли в контексті оновлюється навіть одне поле, всі компоненти, які його споживають, можуть перерендеритися.
Відсутність мемоізації
Якщо підкомпоненти не “захищені” за допомогою React.memo або PureComponent, вони можуть рендеритись навіть при незначних змінах у батьківському компоненті.
Фальшиві оновлення стану
Коли викликається setState з тим самим значенням (наприклад, setCount(count)), React теж ініціює рендер (хоча він може оптимізувати, якщо ви користуєтесь певними підходами).
DevTools Profiler
Chrome DevTools (Performance) або профайлер у React DevTools дають змогу побачити, які компоненти рендеряться і скільки часу це займає.
why-did-you-render
Спеціальна бібліотека, яка вказує у консоль, коли React виконує перерендер компонента і чому він вважає, що пропи змінились.
Для функціональних компонентів існує React.memo, який проводить поверхневе порівняння пропів:
const MyComponent = React.memo(function MyComponent(props) {
console.log('Render MyComponent');
return <div>{props.value}</div>;
});
Якщо props.value не змінився (поверхнево), MyComponent не буде ререндеритися. Проте це працює лише, якщо пропи є простими (числа, рядки). Для об’єктів чи масивів, які завжди створюються заново, React.memo не допоможе без додаткових прийомів.
Якщо передаємо у пропсах функції чи складні об’єкти, бажано використовувати useCallback і useMemo, щоб React “запам’ятав” (мемоізував) значення. Наприклад:
function Parent() {
const [count, setCount] = useState(0);
const increment = useCallback(() => setCount(c => c + 1), []);
return <Child onClick={increment} />;
}
Тепер onClick завжди має те саме посилання на функцію, і якщо Child обгорнуто в React.memo, він не ререндеритиметься при зміні count (якщо на інші пропи це не впливає).
Якщо контекст (React Context) містить багато даних або часто змінюється, кожен Consumer може ререндеритися. Один зі способів:
Захист від “фальшивих” оновлень
function Parent() {
const [count, setCount] = useState(0);
const increment = () => {
setCount(prev => {
if (prev === 100) return prev; // Якщо досягнуто межі, не оновлюємо
return prev + 1;
});
};
return <button onClick={increment}>{count}</button>;
}
У такому разі, якщо поточний стан уже 100, ми не викликаємо непотрібний рендер.
Для складних даних у стані можна використовувати такі бібліотеки, щоб грамотно робити immutable-оновлення, не створюючи “зайвих” нових об’єктів. Це зменшує ризик випадкових перезаписів, що провокують ререндер.
MobX автоматично “прив’язує” компоненти до певних спостережуваних (observable) полів. Якщо поле не змінювалося, компонент не ререндериться. Проте це вимагає додаткових архітектурних рішень, а також знання MobX.
Якщо у батьківському компоненті є багато дочірніх, краще “розділити” логіку так, щоб дочірні компоненти отримували тільки ті пропи, які їм дійсно потрібні. Таким чином, якщо змінюється якась глобальна змінна, яку не використовує конкретний дочірній компонент, він не рендериться.
Якщо у вас є довгий список (наприклад, відображення сотень чи тисяч елементів), зверніть увагу на:
Зайві перерендери у React можуть “з’їдати” продуктивність, але є багато способів боротися з ними. Головне — зрозуміти, чому відбуваються ці повторні рендери: чи це через передачу функцій-анонімок, великих об’єктів у пропсах, чи, можливо, контекст оновлюється надто часто. Правильне використання React.memo, useCallback, useMemo, архітектурне розділення стану, оптимізація контексту — усе це зменшить кількість непотрібних рендерів. У підсумку, користувачі отримають швидкі й чуйні інтерфейси, а код стане більш передбачуваним і зручним у підтримці.
Час завантаження сайту часто є вирішальним чинником для користувачів: якщо сторінка вантажиться надто довго, відвідувач може просто піти. Це безпосередньо впливає на конверсії, SEO та загальний досвід користувачів. Тож “як прискорити завантаження сайту?” — питання, яке хвилює багатьох розробників. У цій статті зібрано найважливіші поради та прийоми, які можна легко реалізувати у будь-якому веб-проєкті.
Вибір правильного формату
Стиснення
Ледаче завантаження (lazy loading)
Об’єднання файлів (bundling)
Використання CDN
Попереднє завантаження (preload, prefetch)
Мінімізація
Вилучення невикористаного коду
Кеш заголовки (cache headers)
Service Worker
Динамічне підключення
Code splitting
Прискорення завантаження сайту — це багатоаспектне завдання. Часто розпочинають із оптимізації зображень та мінімізації ресурсів (CSS, JS), налаштування кешу. Потім переходять до тонших прийомів, таких як lazy loading, code splitting, використання CDN і коректного налаштування сервера (HTTP/2, Gzip). Важливо постійно моніторити швидкодію та стежити за рекомендаціями інструментів на кшталт Lighthouse. Правильна оптимізація дасть вашому сайту швидший старт, кращий досвід для користувачів та позитивний вплив на SEO.
Laravel давно вважається одним із найпопулярніших фреймворків для PHP завдяки його простоті, структурі і великій спільноті. Проте одна з ключових проблем у проєктах на Laravel — це налаштування середовища, особливо якщо розробники працюють на різних операційних системах. Docker дає змогу створювати уніфіковані середовища для розробки та продакшену, значно спрощуючи життєвий цикл додатка. У цій статті розглянемо, як працювати з Docker для Laravel, з чого почати та як налагодити процес розгортання.
Уніфіковане середовище
Якщо один розробник працює на Linux, інший на Windows, а третій на macOS, виникають різні нюанси налаштування PHP, бази даних і розширень. Docker виключає такі конфлікти, адже всі запускаються в однакових контейнерах.
Легке масштабування
Для продакшен-середовища можна швидко підняти кілька контейнерів з різними компонентами: Nginx/PHP-FPM, Redis, MySQL. Це робить додаток більш гнучким для навантажень і розподілення сервісів.
Зручне оновлення середовища
Якщо потрібна інша версія PHP або якесь нове розширення, змінюють Dockerfile, а потім перезбирають контейнер. Не треба ручного “відловлювання” несумісностей.
CI/CD інтеграція
Docker гарно інтегрується з інструментами безперервної інтеграції і деплою, адже один і той самий образ можна запускати в розробці, на тест-середовищі і в продакшені.
Найпростіший варіант — використати офіційні образи PHP (з розширеннями) і MySQL/Redis. Але зручніше мати docker-compose.yml, де буде описано всі сервіси.
docker-compose.yml
version: "3.9"
services:
app:
build:
context: .
dockerfile: Dockerfile
image: laravel-app
container_name: laravel_app
volumes:
- ./:/var/www/html
ports:
- "8000:80"
depends_on:
- db
db:
image: mysql:8
container_name: laravel_db
environment:
MYSQL_DATABASE: laravel_db
MYSQL_ROOT_PASSWORD: secret
MYSQL_USER: laravel
MYSQL_PASSWORD: secret
ports:
- "3306:3306"
Dockerfile
# Залежить від PHP-образу з фреймворком
FROM php:8.1-fpm
# Встановлюємо додаткові розширення (gd, pdo, etc.)
RUN apt-get update && apt-get install -y \
libpng-dev \
libonig-dev \
libxml2-dev \
zip \
unzip
RUN docker-php-ext-install pdo_mysql mbstring exif pcntl bcmath gd
# Composer
COPY --from=composer:2 /usr/bin/composer /usr/bin/composer
WORKDIR /var/www/html
# Виставляємо права доступу
RUN chown -R www-data:www-data /var/www/html
# За замовчуванням php-fpm буде слухати 9000 порт
EXPOSE 80
CMD ["php-fpm"]Пояснення
php:8.1-fpm./var/www/html.Після того, як ми маємо docker-compose.yml і Dockerfile, у корені проєкту (там, де папка з Laravel) можна запустити
docker-compose build
docker-compose up -d
Тепер у браузері можна перейти на http://localhost:8000 і побачити Laravel.
DB_CONNECTION=mysql
DB_HOST=db
DB_PORT=3306
DB_DATABASE=laravel_db
DB_USERNAME=laravel
DB_PASSWORD=secret
Тут DB_HOST=db означає ім’я сервісу з docker-compose.
Зверніть увагу, що у docker-compose.yml використовується
volumes:
- ./:/var/www/htmlЦе означає, що локальна папка відображена у контейнері як /var/www/html. Усі зміни, які ви робите локально (редагування файлів Laravel), автоматично відображаються у контейнері, тож немає потреби ребілдити контейнер.
Виготовляйте окремі Dockerfile для development і production.
Якщо залежності встановлюються часто, оптимізуйте шари Dockerfile так, щоб composer install кешувався, якщо composer.json не змінюється.
Приклад виробничого Dockerfile (Production)
FROM php:8.1-fpm as builder
RUN apt-get update && apt-get install -y \
libpng-dev \
libonig-dev \
libxml2-dev \
zip \
unzip
RUN docker-php-ext-install pdo_mysql mbstring exif pcntl bcmath gd
COPY --from=composer:2 /usr/bin/composer /usr/bin/composer
WORKDIR /var/www/html
COPY composer.json composer.lock ./
RUN composer install --no-dev --optimize-autoloader
COPY . .
RUN php artisan config:cache
FROM php:8.1-fpm
COPY --from=builder /var/www/html /var/www/html
WORKDIR /var/www/html
CMD [\"php-fpm\"]Структура
Docker дає змогу зробити процес розробки Laravel проєктів більш передбачуваним і контрольованим. Замість витрачати час на ручне налаштування PHP, розширень і СУБД, ми описуємо все у Dockerfile і docker-compose.yml, а потім просто запускаємо контейнери. Це особливо корисно, коли команда розробників велика або коли потрібно швидко відтворити середовище для тестування чи продакшену. Незважаючи на початкові труднощі, переваги (універсальність середовища, масштабованість, легкість деплою) роблять Docker для Laravel гарним вибором.
Відкрийте криптовалютну картку Trustee за кілька хвилин! Оплачуйте ваші покупки миттєво з автоматичною конвертацією