История изменений
Исправление semlanik, (текущая версия) :
Как и любой другой IDL, например Thrift или RSDL. Проектирование любого взаимодействия компонент начинается с описания итерфейса между ними. Вы всегда можете описать его словами либо использовать «пакетное описание» интерфейсов. Но прогресс выявил более удобный способ описания интерфейсов - IDL. Google предолжили protobuf. Общая логика такова:
- Вы определяете компоненты вашей системы.
- Описываете интерфейс взаимодействия используя IDL(в нашем случае Google protocol buffers и gRPC).
- Генерируете код условно серверной и условно клиентской частей. Клиент-серверное взаимодействие условность на мой взгляд, правильнее использовать поставщик интефейса и его потребитель(aka interface provider, interface consumer).
- Дополняете сгенерированный код имплементацией бизнес логики.
В случае с «чистым» protocol buffers вы определяете структуры обмена данными, но не методы. gRPC дополняет protocol buffers методами.
На выходе вы получаете готовые связи компонентов без необходимости продумывать механизмы сериализации и передачи данных.
Также IDL очень полезен если вы предполагаете иметь какой-то публичный/внешний API для вашей системы. Имея на руках IDL описание интерфеса программист-пользователь системы может без труда сгенерировать необходимый код и впоследствии использовать его, избавив себя от решения проблем сериализации и траспортировки данных.
Надеюсь что ответ исчерпывающий.
Исходная версия semlanik, :
Как и любой другой IDL, например Thrift или RSDL. Проектирование любого взаимодействия компонент начинается с описания итерфейса между ними. Вы всегда можете описать его словами либо использовать «пакетное описание» интерфейсов. Но прогресс выявил более удобный способ описания интерфейсов. Google предолжили protobuf. Общая логика такова:
- Вы определяете компоненты вашей системы
- Описываете интерфейс взаимодействия используя IDL(в нашем случае Google protocol buffers и gRPC)
- Генерируете код условно серверной и условно клиентской частей. Клиент-серверное взаимодействие условность на мой взгляд, правильнее использовать поставщик интефейса и его потребитель(aka interface provider, interface consumer).
- Дополняете сгенерированный код имплементацией.
В случае с «чистым» protocol buffers вы определяете структуры обмена данными, но не методы. gRPC дополняет protocol buffers методами.
На выходе вы получаете готовые связи компонентов без необходимости продумывать механизмы сериализации и передачи данных.
Также IDL очень полезен если вы предполагаете иметь какой-то публичный/внешний API для вашей системы. Имея на руках IDL описание интерфеса программист-пользователь системы может без труда сгенерировать необходимый код и впоследствии использовать его, избавив себя от решения проблем сериализации и траспортировки данных.
Надеюсь что ответ исчерпывающий.