Могу ли я использовать java -grp c в качестве библиотеки вместо фреймворка? - PullRequest
Новая
       27

Могу ли я использовать java -grp c в качестве библиотеки вместо фреймворка?

0 голосов
/ 28 апреля 2020

Я большой сторонник композиции поверх наследования, а также библиотек над инфраструктурой (что очень похоже на композицию, поскольку библиотеки составлены). Этот код из примера gRP C java в некоторой степени говорит мне, что java -grp c является каркасом, а не просто библиотекой (что хорошо, в этом нет ничего плохого) .. . 

    Server server = ServerBuilder.forPort(port)
            .addService(new GreeterImpl())
            .build()
            .start();

Я пытаюсь, чтобы мой веб-сервер (веб-компоненты) получал запросы на эти URL

  • https://host/grpc -> веб-элементы просто используйте библиотеку grp c (надеюсь) для кодирования / декодирования
  • https://host/json/ {grpcMethod} -> webpieces будет захватывать grpcMethod и декодировать json в grp c объект для вызова службы здесь

(отредактируйте для большей ясности, основываясь на первом ответе) ...

Key Point -> Json должен прийти И использовать одни и те же объекты протобуф. Мне не нужно создавать json pojo, как видно на этом json grp c ударном посте JSON grp c

Мне действительно нужно java -gRP C api, с которым я могу взаимодействовать, чтобы я мог попросить библиотеку кодировать / декодировать в обоих направлениях. Это тогда дает клиентам возможность сделать gRP C в нашем publi c API или использовать JSON, если они предпочитают.

Я начинаю думать с java -grp c, это невозможно, так как это скорее фреймворк, чем просто библиотека (я имею в виду, что это, конечно, тоже библиотека, но поскольку я должен подключиться к ней, а не использовать ее, это тоже фреймворк).

Я потратил сегодня достаточно много времени, чтобы начать создавать новый io.grp c .ServerProvider и новый io.grp c .ManagedChannelProvider, но ничего себе, есть способ реализовать гораздо больше, чем я подозревал бы для простого кодирования / декодирования эти объекты для меня - это то, что я искал.

И последний вопрос, поскольку gRP C находится над http / 2. Я не вижу местоположения в клиенте или сервере в java -grp c для указания пути URL, который должен быть выбран?

webpieces фактически поддерживает потоковую передачу в обоих направлениях, например gRP C до точка (веб-интерфейс http 100% поддерживает это). Нам нужно проделать определенную работу, чтобы перенести его в контроллеры, что мы и сделаем в какой-то момент (когда мы сможем серверные веб-страницы, gRP C и JSON, все на том же безсерверном сервере, который мы настроили) .

БОНУСНЫЕ ТОЧКИ: Веб-части, подобные старой игровой структуре '1067 *, ТАКЖЕ поддерживают горячую компиляцию при разработке, поэтому было бы ОЧЕНЬ ИДЕАЛЬНО, если бы у нас был сервер gRP C под веб-элементами вместо gRP * 1069. * сервер находится на вершине, убивая процесс без перезапуска, который мы продолжаем.

спасибо за любые подсказки там! Декан

1 Ответ

1 голос
/ 28 апреля 2020

Я все еще думаю, что gRP C больше похож на библиотеку.

В любом случае, JSON сообщение в блоге даст вам хорошую идею, как сериализовать и десериализовать запрос / ответы , Кроме того, в нем показано, как вручную предоставить MethodDescriptors и ServerServiceDefinitions для определения метода и службы, включая маршрутизацию.

Protobuf - это сериализация по умолчанию для gRP C. Таким образом, использование protobuf намного проще. Вам обычно не нужно беспокоиться об этих низкоуровневых API. Тем не менее, в основном, это не сильно зависит от спецификации c сериализации, как вы можете видеть из сообщения в блоге.

...