При разработке и поддержке нового сервиса часто приходится проделать много монотонной работы, связанной с API. Нужно спецификацию разработать, потом реализовать API на сервере, протестировать api на соответствие спецификации. Со стороны вызывающего сервиса приходится реализовать клиенты к этому сервису, так же их протестировать. Потом тестировать их интеграцию... Одним словом, очень много монотонной, рутинной и не интересной работы.

Вот бы был такой инструмент, которому мы на вход подавали спецификацию в более-менее человеко-читаемом формате, а на выходе получали:
- код сервера
- код для вызова этого сервера из другого сервиса
- гарантию соблюдения API всеми участниками
и оставалось только реализовать бизнес-логику.
Google предлагает решение для такой задачи - gRPC. Protoc с помощью плагинов grpc по protobuf генерирует сервер и клиентскую библиотеку к нему. Однако, прибивает вас намертво к фреймворку gRPC. Во-первых, http2 подходит не всем. Внутренняя инфраструктура в компании может быть выстроена вокруг http1.1, настроены балансировщики, метрики, алерты и тп. Во-вторых, не предоставляет достаточный уровнь кастомизации. Например, для дебаг целей не удобно использовать бинарный протокол. Хочется просто взывать endpoint с помощью curl и передать условный json. Кастомизация позволяет удовлетворить хотелки достаточно просто.

В ivi мы разработали такой инструмент для автоматической генерации сервера и http-клиента к нему, базируясь на open-source решении: в качестве основы мы взяли protobuf. В качестве кодогенератора - protoc с нашими кастомными плагинами. Сервер и клиент генерируются для python и golang. Веб-фреймворк для go - fasthttp, для python - наши собственные wsgi/asgi приложения. Совокупность упомянутых инструментов лежит в основе нашего фреймворка для межсервисного взаимодействия PIVI.

В своем докладе я расскажу о том, как с минимальными трудозатратами и почти без велосипедостроения на базе open-source создать такой инструмент с большой долей кастомизации. Не нравится http2? Пожалуйста, используйте http1.1. Хотите принудительные одинаковые логи во всех клиентах к вашему сервису? Без проблем. Прикрутить open-telemetry? Не вопрос! Ваши клиент и сервер будут сами-с-усами, сильные и независимые.