Сценарий представляет собой набор микросервисов , сгенерированных JHipster , которые взаимодействуют друг с другом через gRP C. Субгенератор jhipster-grp c (https://github.com/cbornet/generator-jhipster-grpc) используется для генерации соответствующих классов gRP C.
Я определяю protobuf (. Прото) файлы, определяющие service s и их вызовы RP C, а также любые определения message по мере необходимости. Когда вызывается суб-генератор jhipster-grp c, это приведет к генерации кода, реализующего эти интерфейсы. Затем разработчик (и) должен разработать спецификацию домена c logi c в реальных реализациях службы, которые реализуют / расширяют сгенерированный код gRP C.
A Потребительская служба , которая вызывает службу поставщика , должна иметь доступ к API, сгенерированному поставщиком gRP C. Я обнаружил, что мне нужно продублировать файл (ы) protobuf (и все, что сгенерировано из них) на стороне потребителя, в противном случае потребитель не сможет увидеть сгенерированный код на провайдере.
Это делает нет смысла на нескольких уровнях. Я также не думаю, что имеет смысл пытаться сделать сервис провайдера зависимым для потребителя. Это предоставит потребителю весь API-интерфейс publi c поставщика, что может быть нежелательно.
Каков наилучший способ сделать это, чтобы файлы .proto и все, что генерируется не нужно ли дублировать субгенератор jhipster-grp c на потребителе (ах)?
Я кратко поигрался с идеей создания отдельного проекта JHispter с just артефакты protobuf, но JHipster ориентирован на создание приложения, а не «библиотеки», и будет много ненужного сгенерированного кода, который никогда не будет использоваться. Это не похоже на жизнеспособное решение.
Возможно, я создаю отдельный проект для API gRP C, то есть , а не , сгенерированный JHipster или подпрограммой jhipster-grp c -generator, а затем сделать его зависимым для микросервисных проектов. Похоже, что это своего рода поражение цели использования преимуществ, предоставляемых JHipster.
Есть идеи?