#интеграция

Есть у меня любимое задание на курсах по интеграции: выбрать технологию или протокол для взаимодействия и обосновать выбор.

Каждый раз, случается диалог вида:

— Мы выбрали gRPC для внутренних взаимодействий, потому это быстрее, чем REST

— А на сколько быстрее?

— Что вы называете REST’ом? А если это REST API поверх HTTP/2, будет ли gRPC быстрее, и на сколько?

— Какую долю от времени ответа занимает передача данных? Будет ли разница в скорости между gRPC и REST значимой для нас?

— Какая общая нагрузка на систему или продукт? Важна ли нам вообще скорость внутренних взаимодействий?

После этих вопросов приходится идти считать текущую и прогнозируемую нагрузку, изучать производительность сервисов, смотреть бенчмарки, делать нагрузочное тестирование. Вполне вероятно, что летенси ваших сервисов определяется совсем не скоростью передачи по сети.

И я не перестану говорить, что все эти чек-листы и универсальные критерии выбора — полный буллшит. Если человек не может собрать контекст задачи, выделить значимые критерии и приоритезировать их, он остается жалким подобием чатгпт.

Поэтому для желающих стать человеком мыслящим в мае проведем несколько активностей в Tech Analyst Club:

• 23.05, сбт — воркшоп по тестированию и документированию нестандартных API (GraphQL, gRPC, WebSocket) в Postman, чтобы пощупать их ручками

• 28.05, чтв — вебинар про иерархию и устройство протоколов и технологий взаимодействий, если хочется какой-то цельной классификации

• 30.05, сбт — воркшоп про выделение и приоритезацию критериев выбора способа интеграции, там будет самое мясо

Кстати, о производительности gRPC у нас был стрим с Алексеем Романовым.