История изменений

Как и любой другой IDL, например Thrift или RSDL. Проектирование любого взаимодействия компонент начинается с описания итерфейса между ними. Вы всегда можете описать его словами либо использовать «пакетное описание» интерфейсов. Но прогресс выявил более удобный способ описания интерфейсов - IDL. Google предолжили protobuf. Общая логика такова:

1. Вы определяете компоненты вашей системы.
2. Описываете интерфейс взаимодействия используя IDL(в нашем случае Google protocol buffers и gRPC).
3. Генерируете код условно серверной и условно клиентской частей. Клиент-серверное взаимодействие условность на мой взгляд, правильнее использовать поставщик интефейса и его потребитель(aka interface provider, interface consumer).
4. Дополняете сгенерированный код имплементацией бизнес логики.

В случае с «чистым» protocol buffers вы определяете структуры обмена данными, но не методы. gRPC дополняет protocol buffers методами.

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

Также IDL очень полезен если вы предполагаете иметь какой-то публичный/внешний API для вашей системы. Имея на руках IDL описание интерфеса программист-пользователь системы может без труда сгенерировать необходимый код и впоследствии использовать его, избавив себя от решения проблем сериализации и траспортировки данных.

Надеюсь что ответ исчерпывающий.

Как и любой другой IDL, например Thrift или RSDL. Проектирование любого взаимодействия компонент начинается с описания итерфейса между ними. Вы всегда можете описать его словами либо использовать «пакетное описание» интерфейсов. Но прогресс выявил более удобный способ описания интерфейсов. Google предолжили protobuf. Общая логика такова:

1. Вы определяете компоненты вашей системы
2. Описываете интерфейс взаимодействия используя IDL(в нашем случае Google protocol buffers и gRPC)
3. Генерируете код условно серверной и условно клиентской частей. Клиент-серверное взаимодействие условность на мой взгляд, правильнее использовать поставщик интефейса и его потребитель(aka interface provider, interface consumer).
4. Дополняете сгенерированный код имплементацией.

В случае с «чистым» protocol buffers вы определяете структуры обмена данными, но не методы. gRPC дополняет protocol buffers методами.

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

Также IDL очень полезен если вы предполагаете иметь какой-то публичный/внешний API для вашей системы. Имея на руках IDL описание интерфеса программист-пользователь системы может без труда сгенерировать необходимый код и впоследствии использовать его, избавив себя от решения проблем сериализации и траспортировки данных.

Надеюсь что ответ исчерпывающий.