HARmageddon скасовано: як ми навчили Playwright відтворювати HAR з динамічними параметрами

Регулярні пошуки HAR швидко перестають працювати - динамічні параметри переривають відповідність запитів, а вміст містить конфіденційні дані, які не можуть бути залучені. Problem: Ми ввели автоматичну нормалізацію HAR (заміна користувачів, токенів, ідентифікаторів) і логічний шар на вершині Playwright, який правильно обробляє динамічні параметри. Approach: Ми навчили Playwright знайти правильний вхід HAR навіть при зміні значень запиту / тіла і запобігали повторному використанню суб'єктів з динамічними ідентифікаторами. What we did: Тести E2E стали незалежними від навколишнього середовища, працюють стабільно в CI / CD, не потребують резервного коду і не містять персональних даних. Result: Why mock the network in E2E tests at all? Чому взагалі жартує мережа в тестах E2E? Незважаючи на те, що тести E2E призначені для тестування додатка «як цілого», на практиці ви майже завжди повинні ізолювати інтерфейс користувача від реальних мережевих викликів. 1. Test stability Справжнє вогонь може: Будьте недоступні Будьте повільними Повернення непередбачуваних даних Мокки усувають випадковість і роблять тести повторюваними. 2. Speed Навіть при послідовних тестуваннях повертаються відповіді Без реальних мережевих дзвінків. instantly Це робить тести в кілька разів швидше, ніж потрапляння в реальний бак-енд. 3. Reducing load on the backend Коли тести E2E працюють паралельно, вони генерують багато одночасних запитів. створення завантажувальних піків на тестовому сервері, призводить до помилок у розмірах тарифів, В основному «DDoS» ваш власний backend. Mocks повністю знімають навантаження на мережу - бак-енд взагалі не бере участі в тестуванні. 4. Independence from external services Stripe, S3, геокодери, OpenAI - все, що може провалитися, в кінцевому підсумку провалиться. Mocks перетворюють тести E2E на повністю автономний шар, який не залежить від сторонніх API. Але є один недолік: якщо зовнішня служба змінює свій контракт або йде вниз, смішний тест ніколи не дізнається і буде щасливо залишатися зеленим. How Playwright mocks the network Як Playwright жартує про мережу Playwright має інтерфейс низького рівня для перехоплення та заміни запитів: browserContext('**/api/users', route => { route.fulfill({ status: 200, contentType: 'application/json', body: JSON.stringify(mockUsers), }); }); Будь-який запит, що відповідає шаблону (в даному прикладі закінчується /api / користувачі) буде оброблятися локально - без переходу в Інтернет, і дані, передані для виконання, будуть повернуті "клієнту" у відповідь на цей запит. What is a HAR file and why is it convenient for testing? Що таке файл HAR і чому він зручний для тестування? Це JSON-файл, який містить: HAR (HTTP Archive) Всі сторінки запитів Запрошення параметрів Серверні відповіді З іншого боку, вона є записом real network activity. Якщо ви створили HAR один раз (наприклад, ввійшли, відкрили список, завантажили картку продукту), то ви можете використовувати цей файл як джерело жартів, які повністю відтворюють справжню поведінку API. Ось чому HAR ідеально підходить, коли ви: Необхідно встановити стан мережі Хочете перевірити UI, не запускаючи backend потрібен детерміністичний сценарій, що максимально наближається до реальності How Playwright uses HAR files for mocking Як Playwright використовує файли HAR для змалювання Playwright може: Рекорд має Відтворення HAR без реальних мережевих дзвінків Обидві операції виконуються за допомогою методу routeFromHAR на браузеріContext: browserContext.routeFromHAR(harFilePath, options); 1) Recording HAR browserContext.routeFromHAR(harFilePath, {update: true, url: /api\./}); Playwright автоматично перехоплює все, що відбувається в браузері (якщо виключення не налаштовані в параметрах) і зберігає його в *.har файл(і) 2) Replaying HAR browserContext.routeFromHAR(harFilePath, {update: false, url: /api\./}); Тепер, якщо тест робить запит, який існує в HAR, Playwright відразу ж повертає збережену відповідь, не йдучи в мережу. Ви можете прочитати більше про запис і відтворення HAR в документах Playwright. Ви можете прочитати більше про запис і відтворення HAR в Playwright . Докці Докці Advantages of HAR mocking Переваги HAR Mocking Реалістичні дані HAR містить реальні серверні відповіді, і інтерфейс користувача бачить їх точно так, як вони були в момент запису. 2. повна ізоляція Тестування виконується навіть на локальній машині без резервного кінця. 3 Висока швидкість HAR відповіді повертаються миттєво - тести працюють з максимальною швидкістю. Ідеальний варіант для складних потоків Наприклад: Автентифікація Комплексні фільтри Запрошення ланцюгів Сторінки з десятками викликів API Створювати такі жарти вручну важко, і HAR вирішує це автоматично. Why HAR mocks can unexpectedly break Чому бородавки можуть несподівано розірватися Зареєстрований HAR-файл є знімком мережевих запитів, зроблених під час натискання на реальний бак-енд під час тестування. В результаті, файл може містити динамічні дані, ідентифікатори користувачів в URL-адресах та чутливу інформацію (токенів аут, електронних листів тощо). У нашому проекті ми зіткнулися з 4 проблемами з даними в файлах HAR: tied to the user under which the HAR was recorded dynamic parts of URLs dynamic request bodies sensitive data that can’t be committed 1.Tied to the user under which the HAR was recorded 1.Перенаправлено до користувача, під яким був записаний HAR На практиці розробники записували файли HAR під час входу як різних користувачів, що призвело до того, що URL-адреси з ідентифікаторами користувачів відразу ж стали проблемою. Example: У нашому додатку користувач може використовувати чат і також переглядати список отриманих електронних листів на окремій сторінці. Тестування для чат-сторінки використовують мочки від яка містить запит на список користувачів для користувача з ідентифікатором : chats.har, unique-user-id-1 GET /unique-user-id-1 / користувачі / список GET /unique-user-id-1 / користувачі / список { "entries": [ { "request": { "method": "GET", "url": "/unique-user-id-1/users/list" } } ] } Тестування для сторінки електронної пошти використовують чутки від , який також містить запит на список користувачів, але він був записаний під користувачем з ідентифікатором emails.har unique-user-id-2: GET /unique-user-id-2 / користувачі / список GET /unique-user-id-2 / користувачі / список { "entries": [ { "request": { "method": "GET", "url": "/unique-user-id-2/users/list" } } ] } Наслідки : Playwright при повторному використанні відповідає запитам строго за URL-адресами, методом і тілом, тому навіть невелике невідповідність руйнує бред. Якщо ми запускаємо всі тести, зареєстровані як користувач з ID , Playwright не зможе знайти потрібний суб'єкт у під час запуску тестів електронної пошти, тому що кінцева точка GET було записано для користувача У той час як Playwright шукає unique-user-id-1 emails.har /unique-user-id-2/users/list unique-user-id-2 /unique-user-id-1/users/list. 2. Dynamic parts of URLs Динамічні частини URL Example: Файл HAR може містити запис з ідентифікатором запиту, що генерується на стороні клієнта: { "entries": [ { "request": { "method": "GET", "url": "/generate?request-id=fc21b48a-e84d-4b-92-a494d65a280a" } } ] } Consequences: кожен раз буде унікальним (одне значення в час запису, інше в час повторного відтворення), тому Playwright ніколи не знайде цей запис на наступних тестах, знову ж таки, тому що Playwright суворо порівнює дані URL при пошуку. request-id 3. Dynamic request body Якщо тіло містить значення, які повинні збігатися з даними, отриманими на попередньому кроці (наприклад, request-id від /generate), Playwright зможе знайти правильний вхід HAR тільки якщо ці значення точно збігаються. Хоча такі параметри є унікальними за своєю природою, їх значення повинно бути однаковим у всіх пов'язаних запитах у тесті.Якщо ідентифікатор запиту, що передається до /generate, не відповідає ідентифікатору request_id в тілі наступного запиту, Playwright не зможе знайти відповідний запис, і підступ просто не працюватиме. коли раніше створений ідентифікатор запиту передається в тіло наступного запиту: Example { "entries": [ { "request": { "method": "POST", "url": "/generate-result", "postData": { "text": "{\"request_id\":\"fc21b48a-e84d-4b-92-a494d65a280a\"}" } } } ] } Consequences: Якщо відрізняється від того, що було в запиті /generate, Playwright не знайде відповідний запис в HAR. request_id 4. Sensitive data that can’t be committed Example: { "entries": [ { "request": { "method": "POST", "url": "api/auth", "postData": { "mimeType": "application/json", "text": "{\"email\":\"test@test.com\",\"password\":\"strongPassword\"}" } } } ] } Consequences: Реальні дані користувача можуть закінчитися в репозиторії, тому що файли HAR повинні бути в репо для тестування CI / CD. І, сподіваємося, ваша кінцева точка auth не приймає такі дані в простому тексті в реальному житті We ended up with these tasks: Ми закінчили з цими завданнями: Файли HAR не повинні залежати від користувача, під яким вони були записані, і не повинні містити конфіденційні дані. Не має значення, де ми їх записали - ми хочемо використовувати їх без залежності від користувачів і їх даних. Файл не повинен містити реальних персональних даних користувача - тільки контрольовані значення тестування. Ми повинні навчити наші тести працювати з динамічними даними Кінцеві точки з динамічними даними повинні бути знайдені в HAR і використані в тесті лише один раз, так само як і при реальних зволоженнях: конкретний запит - конкретна відповідь. Якщо для тестування логіки необхідно викликати кінцеву точку з даними з іншої кінцевої точки, необхідно використовувати строго відповідний вхід HAR. How to approach the solution Як підходити до рішення HAR нормалізація - окремий сценарій, який: finds “original” user data in the HAR and replaces it with test values can normalize previously created HARs so we don’t have to re-record them. Some tests require special conditions for the user in order to reproduce them for recording Динамічне перехоплення даних запити на URL-адреси з динамічними даними перехоплюються, а в відповідь повертається правильний вхід HAR. HAR normalization Є нормалізація Оскільки нам потрібно нормалізувати раніше створені HAR, завдання полягає в автоматичному виявленні довіреності користувача (userId, email, token) і заміні їх контрольованими значеннями тесту. Ми розділили цей процес на два основних етапи: Витягніть реальні дані користувача з auth запиту, тому що це єдине місце, де ми можемо надійно знайти правильні дані користувача: Користувачі Електронна Токен аутентифікації чутливі дані користувача з повсюдними даними тестування: Walk through all HAR entries and replace У всіх URL в заголовках запитів/відповідей Організація запитів/відповідей Нижче наведено спрощену версію того, як можна реалізувати таку нормалізацію, яка вже розділена на логічні частини. Step 1. Extract user data from HAR По-перше, ми знайдемо успішний аутх запит ( / аут з статусом 200) і витягнемо userId, e-mail і токен. interface IdentityData { userId: string email: string token: string } const testData: IdentityData = { userId: '123456789', email: 'test@test.com', token: '936598harmageddoniscancelled5351', }; function extractUserData(harContent: Har): IdentityData | null { const entries = harContent.log.entries; for (const entry of entries) { const url = entry.request?.url || ''; const status = entry.response.status; if (url.includes('/auth') && status === 200) { const responseBody = JSON.parse(entry.response.content.text); const token = entry.response.headers.find( h => h.name.toLowerCase() === 'token' )?.value; return { userId: responseBody.id, email: responseBody.email, token: token, }; } } return null; } Ви можете ознайомитися з типом файлу HAR більш детально тут: https://github.com/DefinitelyTyped/DefinitelyTyped/blob/master/types/har-format/index.d.ts https://github.com/DefinitelyTyped/DefinitelyTyped/blob/master/types/har-format/index.d.ts Step 2. Normalize URLs Далі нам потрібно позбутися від залежності від конкретного userId в URL-адресах: function normalizeUrl((url: string, identityData: IdentityData, testData: IdentityData): string { // Replace userId – our IDs are unique enough that the chance of // encountering them somewhere else is essentially zero return url.replaceAll(identityData.userId, testData.userId); } Step 3. Normalize headers Заголовки часто містять токени та інші речі, які не повинні з'являтися в сховищі. function normalizeHeaders(headers: Header[], identityData: IdentityData, testData: IdentityData): Header[] { return headers.map(header => { let value = header.value || ''; // Replace token in the `token` header if (header.name?.toLowerCase() === 'token' && value === identityData.token) { value = testData.token; } return { ...header, value }; }); } При необхідності ви також можете додати логіку заміни для авторизації, X-User-Id та інших налаштованих заголовків тут. Step 4. Normalize request and response bodies function normalizeContent(text: string, identityData: IdentityData, testData: IdentityData): string { let normalized = text; for (const key of Object.keys(identityData) as (keyof IdentityData)[]) { const original = identityData[key]; const replacement = testData[key]; if (!original || !replacement) continue; normalized = normalized.replaceAll(original, replacement); } return normalized; } Result: putting it all together in normalizeHarFile Результат: покласти все разом в normalizeHarFile Тепер, коли ми маємо всі функції помічника, останній крок - пройти всі записи і застосувати нормалізацію до всіх частин запитів / відповідей. /** * Normalizes a HAR file by replacing real user data with test data * @param {Har} harContent - HAR file content * @param {Object} testData - test data used for replacement (userId, email, token) */ function normalizeHarFile(harContent: Har, testData: IdentityData) { const entries = harContent.log.entries || []; // 1. Extract real user data from the auth request const identityData = extractUserData(harContent); // 2. Normalize each entry in the HAR file const normalizedEntries = entries.map(entry => { // Normalize request URL if (entry.request.url) { entry.request.url = normalizeUrl( entry.request.url, identityData, testData ); } // Normalize request headers if (entry.request.headers) { entry.request.headers = normalizeHeaders( entry.request.headers, identityData, testData ); } // Normalize response headers if (entry.response.headers) { entry.response.headers = normalizeHeaders( entry.response.headers, identityData, testData ); } // Normalize request body if (entry.request.postData?.text) { entry.request.postData.text = normalizeContent( entry.request.postData.text, identityData, testData ); } // Normalize response body if (entry.response.content.text) { entry.response.content.text = normalizeContent( entry.response.content.text, identityData, testData ); } return entry; }); // 3. Return normalized HAR content harContent.log.entries = normalizedEntries; return harContent; } Dynamic data interception Динамічне перехоплення даних У нашій системі існує кілька пов'язаних кінцевих точок: один отримує запит-id в параметрах запиту (генерований на клієнті), а пізніше той же запит-id повинен з'являтися в тілі іншого запиту POST. Під час відтворення HAR, Playwright суворо відповідає URL + метод + тіло і не має поняття, що два різних запити логічно пов'язані одним і тим же запитом-id. Sequence of steps Ми розділили роботу з динамічними даними на кілька етапів Basic HAR wiring through routeFromHAR Playwright still replays everything it can strictly match. Add a wrapper that: HarMocks Закарпаття має пам’ять, може шукати правильний запис з урахуванням динаміки (видалення парамів запиту, пошук в тілі і т.д.) Магазини вже використовували запит-idvalues, щоб уникнути повторного використання одного і того ж входу Перехоплення проблемних URL-адрес через context.route: first request: comes in the query request-id (/with-dynamic-request-id) second request: the same is in the body request-id (/with-request-id-inside-body) additional case: static URL + dynamic only in the body ( ) request_id /api/**/with-dynamic-inside-post Кожного разу, коли Playwright не може відповідати входу HAR з коробки, ми: перевірка запиту, Знайдіть правильний вхід вручну, використовуйте його один раз через route.fulfill(), Зазначте запит-ID як використовується. Step 1. Basic HAR setup via routeFromHAR Крок 1: Налаштування HAR за допомогою routeFromHAR Почнемо з простого класу, який може завантажити HAR і прикріпити його до Playwright. async function setupHarMocks(context: BrowserContext, harFileName: string): Promise { const harFilePath = path.join(__dirname, '..', 'har-files', harFileName); if (!fs.existsSync(harFilePath)) { throw new Error(`HAR file not found: ${harFilePath}`); } const harMocks = new HarMocks(context, harFilePath); await harMocks.setupHarMocks(); } export class HarMocks { private context: BrowserContext private harFilePath: string private harContent: HarContent constructor(context: BrowserContext, harFilePath: string) { this.context = context; this.harFilePath = harFilePath; try { this.harContent = JSON.parse(fs.readFileSync(this.harFilePath, 'utf8')); } catch (error) { throw new Error(`Failed to load HAR file ${this.harFilePath}: ${error}`); } } async setupHarMocks(): Promise { await this.context.routeFromHAR(this.harFilePath, { // Use for API requests url: /api\./, // Use only existing entries update: false, }); } } На даний момент Playwright вже може відтворювати HAR, але все одно «перепадає» на динамічні параметри. . HarMocks Step 2. State for working with dynamic parameters Крок 2: Стан роботи з динамічними параметрами Ми повинні бути: зберігання вже використаних значень request-id, пам'ятати знання request-id, знайдені в одному запиті, щоб ми могли використовувати їх в іншому. export class HarMocks { private context: BrowserContext private harFilePath: string private harContent: HarContent // In one request the request-id is in query, in another - in body, // so we need to store the found value somewhere private foundSearchParams: Record = {} // Store used request-ids so we don’t reuse the same entry private usedRequestIds: Set = new Set() // ... } Step 3. Helper methods for searching entries in HAR Крок 3: Допомога методів пошуку записів в HAR 3.1. URL normalization (removing dynamic query params) normalize(url: string, removableSearchParams: string[] = []) { const urlObj = new URL(url); removableSearchParams.forEach((param) => { urlObj.searchParams.delete(param) }); return urlObj.toString(); } 3.2. Cache key for found params getKeyForSearchParams(name: string, param: string) { return `${name}_${param}`; } 3.3. Easy access to query params getSearchParams(url: string) { const urlObj = new URL(url); return urlObj.searchParams; } 3.4. Finding HAR entry by URL/method with normalization and an extra check findHarEntry({ requestUrl, method, removableSearchParams = [], customCheck }: { requestUrl: string method: string removableSearchParams?: string[] customCheck?: (entry: HarEntry) => boolean }) { return this.harContent.log.entries.find((entry: HarEntry) => { // Additional check, if provided if (entry.request.method !== method || (customCheck && !customCheck(entry))) { return false; } const normHarUrl = removableSearchParams.length > 0 ? this.normalize(entry.request.url, removableSearchParams) : entry.request.url; if (normHarUrl !== requestUrl) { return false; } return true; }) } 3.5. Finding HAR entry where a parameter is inside the body findHarEntryWithParamsInsideBody({ requestUrl, method, parentParamValue, ownParamName, }: { requestUrl: string method: string parentParamValue: string ownParamName: string }) { if (!parentParamValue) { return false; } return this.harContent.log.entries.find((entry: HarEntry) => { const postDataText = entry.request.postData?.text; if (!postDataText) { return false; } return entry.request.url === requestUrl && entry.request.method === method && postDataText.includes(ownParamName) && postDataText.includes(parentParamValue); }) } 3.6. Extracting request_id from request body extractRequestIdFromPostData(entry: HarEntry): string | null { try { const postDataText = entry.request.postData?.text; if (!postDataText) return null; const postData = JSON.parse(postDataText); return postData.request_id || null; } catch { return null; } } Step 4. Intercepting a request with request-id in query Крок 4: Перехоплення запиту з ідентифікатором запиту в запиті Перша кінцева точка: Приєднується до запиту Сам Playwright не знайде вхід HAR через суворе порівняння URL, тому ми робимо це для Playwright. request-id (/with-dynamic-request-id/**) async setupHarMocks(): Promise { await this.context.routeFromHAR(this.harFilePath, { url: /api\./, update: false, }); // URL where request-id is passed in query await this.context.route('**/with-dynamic-request-id/**', async (route) => { const url = route.request().url(); // Remove dynamic request-id from URL const normalizedUrl = this.normalize(url, ['request-id']); const entry = this.findHarEntry({ requestUrl: normalizedUrl, method: 'POST', removableSearchParams: ['request-id'], customCheck: (entry) => { // Ensure request-id from searchParams hasn’t been used yet const searchParams = this.getSearchParams(entry.request.url) const requestId = searchParams.get('request-id') return !requestId || !this.usedRequestIds.has(requestId) }, }); if (!entry) { console.error('Entry not found for:', url); await route.continue(); return; } const searchParams = this.getSearchParams(entry.request.url); const requestId = searchParams.get('request-id'); if (requestId) { // Save request-id for subsequent requests this.foundSearchParams[ this.getKeyForSearchParams('dynamic', 'request-id') ] = requestId; // Mark request-id as used this.usedRequestIds.add(requestId); } await route.fulfill({ status: entry.response.status, headers: entry.response.headers, body: entry.response.content?.text || '{}', }); }) // ...other route handlers } What’s happening here: Ми перехоплюємо запит за шаблоном **/with-dynamic-request-id/**. Ми видаляємо ідентифікатор динамічного запиту з URL-адреси, щоб знайти відповідний запис в HAR. За допомогою customCheck ми гарантуємо, що цей ідентифікатор запиту раніше не використовувався. Ми зберігаємо ідентифікатор запиту в foundSearchParams і usedRequestIds. Ми повертаємо відповідь від HAR через route.fulfill() замість того, щоб натиснути на реальний backend. Step 5. Intercepting a request where request-id is in the body Крок 5: Перехоплення запиту, де ідентифікатор запиту знаходиться в тілі Другий кінцевий пункт повинен використовувати той же ідентифікатор запиту, але цього разу всередині органу запиту як Запит ID: // URL that sends request-id from previous step in the body of a POST request await this.context.route('**/with-request-id-inside-body', async (route) => { const url = route.request().url(); const entry = this.findHarEntryWithParamsInsideBody({ requestUrl: url, method: 'POST', parentParamValue: this.foundSearchParams[ this.getKeyForSearchParams('dynamic', 'request-id') ], ownParamName: 'request_id', }); if (!entry) { console.error('Entry not found for:', url); await route.continue(); return; } await route.fulfill({ status: entry.response.status, headers: entry.response.headers, body: entry.response.content?.text || '{}', }); }) Logic: Ми беремо раніше збережений ідентифікатор запиту від foundSearchParams. Ми шукаємо вхід HAR, де цей запит-id знаходиться в корпусі під ключем request_id. Якщо ви знайдете, ми повернемо цей запис в тесті. Step 6. Static URL + dynamic request_id in the body Статичний URL + динамічний request_id в корпусі Додатковий випадок: URL-адреса не змінюється, але в тілі запиту міститься унікальна І ми хочемо використовувати кожен такий вхід тільки один раз. request_id await this.context.route('**/api/**/with-dynamic-inside-post', async (route) => { const url = route.request().url(); const entry = this.findHarEntry({ requestUrl: url, method: 'POST', customCheck: (entry) => { // Ensure request_id from the body hasn’t been used yet const requestId = this.extractRequestIdFromPostData(entry) return !requestId || !this.usedRequestIds.has(requestId) }, }); if (!entry) { console.error('Entry not found for:', url); await route.continue(); return; } const requestId = this.extractRequestIdFromPostData(entry); if (requestId) { this.usedRequestIds.add(requestId); } await route.fulfill({ status: entry.response.status, headers: entry.response.headers, body: entry.response.content?.text || '{}', }); }) Покласти все разом Для того, щоб логіка тестування поводилася так само, як і реальний бак-енд, нам потрібно: Нехай Playwright використовує HAR всюди, де працюють суворо відповідні роботи, для динамічних кінцевих точок перехоплюйте запити вручну, нормалізуйте URL і тіло, виберіть правильний запис і переконайтеся, що кожен запит-ID використовується тільки один раз. Код вище реалізує саме цей шар на вершині . routeFromHAR What does Playwright think about this? Що думає про це Playwright? На даний момент Playwright залишається «простим HAR-плеєром» без рівня нормалізації: Суворе відповідність за URL / методом / тілом. Немає підтримки Cross-environment/baseURL-aware HAR. Playwright не знає вашої логіки домену. Ось чому окремі рішення з'являються в екосистемі на вершині Playwright - , або спеціальних рішень, як або . ЗакарпаттяПівденно-Східна Створення Playwright-network-cache Завантажити Playwright Network Recordings Приховані витрати на знущання Playwright's API (І наше індивідуальне рішення) ЗакарпаттяПівденно-Східна Створення Playwright-network-cache Завантажити Playwright Network Recordings Приховані витрати на знущання Playwright's API (І наше індивідуальне рішення) Conclusion Висновок Замість ряду крихких жартів, ми в кінцевому підсумку прийшли до єдиної системи, де: У будь-якому випадку користувач записує, автоматично нормалізується Використовуючи абсолютно фальшиві дані, і працює правильно навіть з динамічними параметрами. Цей підхід особливо корисний у великих проектах з великою кількістю викликів API і паралельним розвитком: тести E2E залишаються швидкими, детерміністичними і незалежними від реальних користувачів. Написав Сергій Левкович, старший розробник Frontend у Social Discovery Group. Написав Сергій Левкович, старший розробник Frontend у Social Discovery Group. Написано від Старший розробник на . Сергій Левкович Група соціальних відкриттів Сергій Левкович Сергій Левкович Група соціальних відкриттів Група соціальних відкриттів