Доброго дня, друзі! Як ви?

Щось я маю вам сказать)
Чим більше я проводжу курси, тим чіткіше бачу одну цікаву річ:
для більшості людей API = це або REST, або GraphQL.

Але, насправді, API-протоколів реально цілий всесвіт.

І якщо ви хочете бути сильним КУА - у цьому варто розібратися.
Бо реальні системи говорять між собою зовсім різними способами:
хтось шле івенти, хтось XML у SOAP, хтось працює через WebSockets, а хтось по MQTT як IoT-пилосос.
…і це ще не все)

У кожного з них свої плюси, мінуси і кейси використання.
Тому коли на проєкті щось «не працює», дуже часто питання саме в протоколі, а не в бекенді.

Якщо реально хочете - можу спробувати зробити серію простих постів, де розберемо кожен протокол з прикладами)

Пишіть у коментах, який протокол більше всьго хотілось би розібрати*?

Всім гарного дня і настрою
Обняв 🤗🤗🤗

А це вам підняти настрій)

Коли за тиждень регресії нічого не найшли і за пару годин до злиття в продакшен КУА почали процювати))

ну класика життя що не?

ОБЕРЕЖНО МАТ)

Друзі привіт - як ваш день? сподіваюсь ви були в безпеці та з вами і вашими близкими все добре

2 години сну за ніч - 3 чашки кавусі і з 9 працювати) ось відійшов на обід і думаю яж обіцяв - треба написати

і як раз народилась нова рубрика - ну шо я маю вам сказать

Протоколи для QA - WebSocket

Чесно, WebSocket - це той випадок, коли REST уже не тягне, а реального часу хочеться прямо тут і зараз.

І так що я маю вам сказать,
WebSocket - це прямий живий канал між клієнтом і сервером, де обидві сторони можуть говорити коли хочуть, а не лише «запит → відповідь».

REST - це як листи надсилати.
WebSocket - це як дзвінок, де ви обидва говорите одночасно.

Як відбувається підключення - тут все просто
Клієнт робить handshake через HTTP: щось типо такого ви бачити

GET /ws HTTP/1.1
Upgrade: websocket
Connection: Upgrade

А Сервер каже:

HTTP/1.1 101 Switching Protocols
Upgrade: websocket

І все з цього моменту HTTP більше нема, є чистий WebSocket-канал.
Далі вже API летить у вигляді фреймів: текстові/ бінарні / ping/pong / close
І все це без перестворення з’єднання.

Тобто
Як працює?
Клієнт відкриває WebSocket-з’єднання (handshake через HTTP).

Сервер каже: «Ок, підключаю!».

Після цього вони спілкуються без переривання:

клієнт може надсилати повідомлення

сервер може надсилати події (events) у будь-який момент

З’єднання закривається лише коли одна зі сторін каже close.

За часту це використовують

Чати, Нотифікації, Біржі / live-update цін, Трекинг кур’єрів на мапі, Відеоконференції та дзвінки, Онлайн-ігри

Спитаєте як потестити WebSocket через Postman?
Так-так, Postman вміє WebSocket-и

- Відкриваємо Postman → New → WebSocket
- Пишемо адресу:
-

ws://localhost:8080/ws

- Підключаємося
- Відправляємо тестове повідомлення:

{ "action": "ping" }

- Дивимося, що сервер відповідає
- Для live-систем тестую івенти так:
- робите дію в UI
- дивиьесь, які саме WebSocket-пакети полетіли
- ну звіряю payload з документацією
- перевіряєте порядок подій (це часта бага!) и все) впринципі є офіційна дока як це налаштувати - там думаю ви зрозумієте https://learning.postman.com/docs/sending-requests/websocket/websocket-overview/

Автомейшенам ще проше через wscat пишите и все буде бігати само) я так роблю у себе на курсах - люди яки бачили скажуть шо круто) а може і не))

а і забув ключове Чому WebSocket сам не закривається без ping/pong?
У WebSocket є одна важлива особливість, про яку багато хто не знає:

WebSocket-з’єднання саме по собі “вічне”.
Якщо ви його не пінгуєте - сервер думає, що все ок, навіть якщо клієнт давно помер.
І тут заходить ping/pong

Ping - сервер періодично надсилає «ти живий?».
Pong - клієнт автоматично відповідає «я тут».
Якщо Pong не прийшов у певний час → сервер розуміє, що клієнта нема, і закриває з’єднання.

якщо прям дуже коротко то
Ping/pong - це heartbeat WebSocket-а.
Без нього у вас будуть “зомбі-з’єднання” і нестабільна робота в real-time сервісах.

Вроді нічого не пропустив)

Всім гарного дня і настрою
Обняв 🤗🤗🤗

Друзі, доброго вечора)

Я от сидів, дивився на цю підбірку AI-тулів для кодерів - і знаєте, що подумав?
Зараз стільки шуму про лайв-кодинг, будь девелопером за 2 тижні, керуй AI і пиши код, не знаючи коду, Ну ви бачили це все.

І я реально задумався: а може й правда, вже не потрібно знати 5 мов програмування, щоб нормально працювати?
Бо якщо чесно - я теж почав балуватися AI-тулзами для деву. Взяв собі Cursor, пробую щось робити, граюсь з промтами… І знаєте, воно реально може закривати 50% рутини.
Але про сам проєкт я вам розкажу пізніше, хай трохи підросте)

Що я хочу сказати
І хочете ви того чи ні - AI вже сидить з нами за робочим столом.

Питання інше: може нам дійсно треба бути такими собі general-engineer, але з AI під рукою?
Типу трохи Linux, трохи бекенду, трохи фронта, трохи QA - і AI допомагає з тим, що ти сам не вмієш?
Бо звучить як новий стандарт 2026 року.

А ви як думаєте?
Цікаво почути ваші думки.

Всім гарного та спокійного вечора 🙌
Сильні 💛

Друзі доброго раночку, як ви?)

Слухайте хочу вам підняти настрій і подивитися на себе коли шось нове або складне у вас вийшло) ну я прям бачу себе тут)

Всім гарно дня і настрою
Сильні 💛💛💛

Протоколи для QA - GraphQL

Друзі привіт!
Ну що, рухаємося далі по API-протоколах)

Протоколи для QA - GraphQL

І сьогодні у нас GraphQL.
Чесно - це той випадок, коли REST інколи виглядає як велосипед, а GraphQL - як Tesla.

Що я маю вам сказать
GraphQL вирішує одну дуже болючу проблему REST:
або забагато даних, або замало.

У REST ви отримуєте весь payload, хочете ви того чи ні:

GET /users/123 → п

риходить 10 полів,
хоча умовно треба два.

А в GraphQL ви самі кажете бекенду що саме тобі потрібно:

query {
  user(id: "123") {
    name
    email
  }
}

І сервер повертає рівно це.
Не менше, не більше.

Тому яка головна суть:
GraphQL = не ресурс, а запит до схеми.

Працює це дуже просто)
У GraphQL є три ключові штуки:

Query - читаємо дані
Mutation - змінюємо дані
Subscription - real-time оновлення (тут вже WebSocket заходить)

Вроді просто але покажу вам приклад краше)

Запит:
query {
  product(id: 42) {
    price
    currency
  }
}

Відповідь:
{
  "data": {
    "product": {
      "price": 200,
      "currency": "USD"
    }
  }
}

Чим GraphQL відрізняється від REST?
- REST: “Ось готова відповідь, бери все.”
- GraphQL: “Ти сам кажеш, що хочеш.”

Для UI це рай:
1 запит → 1 відповідь → мінімум оверхедів.

Навішо це нам знати як КУА
GraphQL всеж тестується інакше, ніж REST.

Ключові кейси:
валідація схеми (types, required)
null-handling
error extensions
over-fetching / under-fetching
складні поля з залежностями
pagination
versioning без versioning

І дуже важливе:
GraphQL помилки НЕ такі, як REST.

Вони можуть бути:
data + errors одночасно
REST такого не робить.

За часту воно використовується ?

Shopif/GitHub API/Pinterest/Netflix/Slack

Будь-де, де UI потребує багато даних і мало запитів.

Якщо прям дуже коротко
GraphQL = коли дані тобі потрібні точково і швидко.
REST = коли структура проста і зрозуміла.

Обняв 🤗

Доброго дня друзі - як ви? як ваш день?
Ну шо ше пару годин і можно відпочівати)

Протоколи для QA - gRPC

Чесно? gRPC - це той випадок, коли REST вже не тягне по швидкості і навантаженню.
Це не просто ще один API-формат - це зовсім інший підхід.

Що я маю вам сказать сьогодні
gRPC протокол від Google поверх HTTP/2, який працює на Protobuf (бінарний формат), а не JSON.
Тому він швидший, легший і точніший.

Чому бекенди люблять gRPC?
Бо між мікросервісами треба ганяти величезну кількість даних без зайвого оверхеду.
Тому там де REST “задумується”, gRPC просто пролітає.

Виглядає API принцепі більше складніше ніж ви привикли бачити РЕСТ?

Тут не endpoint-и, а методи сервісу:

service UserService {
  rpc GetUser (UserRequest) returns (UserResponse);
}

Все строго типізовано.
Або підходить - або не проходить. Ніяких “а тут стрінга чи інт?”

Важливий момент для КУА для розуміня
- У gRPC є 4 режими викликів:
- звичайний request/response
- сервер стрімить багато відповідей
- клієнт стрімить запити
- двосторонній стрім (майже як WebSocket)

Для чого його реально юзають:
мікросервіси / high-load / фінтех/ігри/стрімінг / real-time системи, де час відповіді важливий

Тестувати теж в принцепі не складно
BloomRPC /grpcurl / Kreya / Postman (так, тепер теж вміє)

Приклад:

grpcurl -plaintext localhost:50051 list

Що ви маєте перевіряти?
- правильність схем (Proto)
- помилки/коди статусів (вони тут свої)
- performance (gRPC створений для цього)
- роботу стрімів (часто саме там і падає) то що

Ну вроді все - є що добавити то кажіть)

Всім гарно закінчення дня)
Обняв🤗

Доброго ранку, друзі!
Як ви? Як пройшли вихідні?

А у мене вихідні почався з міні-катастрофи(
Мій старий сервер, на якому ми роками ганяли SQL / NoSQL / Linux-лаби / демки - просто злетів.
Не впав, не завис - контора просто перестала його сапортити.

Всі середовища, налаштування, тестові бази, постановки, пайплайни… в трубу.
Болить тільки за учнів, які зараз зі мною в навчанні - і чекають поки я це все відновлю (

Але нічого - піднімемо нове.
І навіть краще. Уже думаю чи не пора зробити собі свій олдскульний домашній дата-центр на 3–4 ТБ, щоб більше ніхто не ламав мою КУА-лабораторію 😄

А тепер шо я хочу вам сказать)
Останнім часом у мене рекомендації просто кишать відео про мікрочіпи, кремнієві фабрики і виробництво. Мабуть я занадто захопився цією темою)

Але ви уявіть, який там рівень тестування.
Ці системи тестують не тільки виробництво, а й:

- пропускну здатність,
- деградацію матеріалів,
- напругу,
- температурні коливання,
- дефекти на рівні нанометрів.
І це ж теж КУА, просто на іншому рівні.
От реально круто же дорости до такого рівня інженерії.

Натрапив на статтю про те, як тестують напівпровідники. Дуже стисло, але технічно і по суті:
https://mptestequipment.com/blog/how-semiconductor-testing-works/

Подумав - може і вам буде цікаво. Бо QA - це не тільки UI/REST/кнопочки. Це цілий світ технологій.

Всім гарного дня і настрою. Обняв!
Сильні 💙

P.S. якщо маєте поради по стабільному сервісу для піднятя Linux-середовища на пару терабайт - буду дуже вдячний. Я вже дивлюсь у бік Hetzner але може є щось прям проверене у робочих умовах?

Друзі привіт - як ваш ранок?

Я все поки в запарі на роботі і налаштуванні свого енв)

Є для вас круте пояснення роботи одного з протоколів, мені подобається формат а вам? Чайники не про васС))

Всім гарного дня і настрою
Обняв 🤗

Доброго ранку друзі - як ви? як ваш ранок?

Це відео якраз про те шо деви іноді роблять бяку в обход куа)
Але миж куа не повині бякі пропускати в прод) Думаю підніму вам настрій

Всім гарного дня, друга кавуся вже допита і погнали працювати)

Сьогодні буде цікава інфа))

Сильні💛💛💛

Друзі, привіт! Як ваш день?
Добрався я до розбору нового пула - і цього разу він прям життєвий для всіх, хто хоч раз ловив «сервер лагає, API відповідає повільно» )

І так

Чому не (A) systemctl status
Багато хто натиснув саме це, і я розумію чому, перша думка: «подивлюсь, чи сервіс впав».
Але… якщо на сервері вже лагає все, ця команда не покаже головне - хто конкретно вантажить систему.
Вона просто скаже «running / failed», але не дасть ні CPU, ні пам’яті, ні load average.

Так це корисно, але точно не перше, що треба запускати.

Чому не (C) ping 8.8.8.8
Ping - це перевірити інтернет, а не сервер.
API гальмує → причина всередині машини, а не у зв’язку з Google DNS. і пінг вже вмер( краше юзати неткат типо шось nc -vz host port

Ping не покаже, що у вас один процес з’їв 100% CPU і тримає систему за горло.

Чому не (D) cd /var/log
О, логи - це святе)
Але лізти туди в першу секунду - це як шукати граблі в темній кімнаті.
Спочатку треба зрозуміти, чи взагалі живий залізяка, а вже потім дивитися логи.

Ну і чому правильна відповідь (B) htop

Тут все просто:
htop - це рентген сервера за 1 секунду.

Він вам покаже
- хто жере CPU;
- хто з’їв пам’ять;
- load average;
- процеси, що зависли;
- свопінг;
- загальну температуру системи.

Ви за 2 секунди розумієте:
«ага, ось цей java/python/node процес живе власним життям і душить усе навколо».

Саме тому htop - перше, що запускає інженер, коли на сервері почалося пекло )

І що я всеж маю вам сказать)
Правильна відповідь тут - не про "знати команду", а про мислення:
спочатку діагностика заліза → потім сервіс → потім логи.

Хто вгадав з першого разу - респект, ви мислите як SRE)
Хто ні - нічого страшного, тепер будете знати з чого починати.

Всім гарного дня і настрою!
Обняв 🤗