Что такое gRPC и как он работает
Что проверяют
Знаете ли вы, на чём он построен, и понимаете ли, чем тестирование отличается от привычного REST.
Как отвечать
Это способ вызывать методы чужого сервиса так, будто они локальные. Построен на трёх вещах:
- описание контракта в отдельном файле: сервисы, методы, структуры сообщений с номерами полей;
- бинарная сериализация вместо текста. Компактнее и быстрее разбирается, но глазами не читается;
- транспорт поверх HTTP/2: одно соединение мультиплексирует много запросов, заголовки сжимаются.
По описанию генерируется код клиента и сервера. Отсюда главное преимущество: контракт нельзя нарушить незаметно, несоответствие ловится на этапе сборки.
Четыре вида вызовов: обычный запрос и ответ, поток от сервера, поток от клиента и двунаправленный поток. Последние три и есть то, ради чего часто выбирают этот протокол.
Что важно для тестировщика:
- браузером не открыть. Нужны специальные утилиты либо клиент, поддерживающий этот протокол. Многие популярные инструменты его уже умеют;
- описание сервиса можно получить с самого сервера, если включена соответствующая возможность. Тогда инструменту не нужен файл контракта, он спросит методы у сервиса сам;
- коды ошибок свои, не совпадают с привычными числовыми кодами;
- из браузера напрямую не работает: нужна отдельная разновидность протокола и прокси, потому что браузер не даёт нужного контроля над соединением;
- обратная совместимость держится на номерах полей. Добавлять поля можно, менять номера и переиспользовать удалённые нельзя. Это то, что стоит проверять при обновлении контракта.
Где применяется: обмен между сервисами внутри системы, где важны скорость и строгий контракт. Наружу для браузеров обычно оставляют обычный интерфейс.
Где спотыкаются
Пытаются проверить его обычным клиентом для HTTP.
Не знают про получение описания с сервера и требуют файл контракта.
Меняют номера полей и ломают совместимость.
Считают, что он заменяет REST везде, включая браузерные клиенты.