Ну шо ше пару годин і можно відпочівати)
Протоколи для 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 створений для цього)
- роботу стрімів (часто саме там і падає) то що
Ну вроді все - є що добавити то кажіть)
Всім гарно закінчення дня)
Обняв🤗