Блог

Я пытаюсь создать PoC на работе, который использует gRPC. В приведенном документе Google рассматривается пример приложения. Мне было интересно, обладает ли protobuf-net, и в частности protogen, способностью понимать определения служб и классы, необходимые для выполнения вызовов gRPC? Или над этим что-то работает? Будет ли это работать, если я использую протокол Google для генерации клиентского и серверного кода (который включает определения служб и вызовы RPC) и protobuf-net для моих бизнес-объектов.

protobuf-net.Grpc теперь стал реальностью… хотя и в предварительном просмотре. Когда .Выходит NET Core 3, мы должны быть в состоянии сделать это доступным.

Он основан на подходе WCF, поэтому ваши интерфейсы служб определяются с помощью:

 namespace Whatever {
    [ServiceContract]
    public interface IMyAmazingService {
        ValueTask<SearchResponse> SearchAsync(SearchRequest request);
        // ... etc
    }
}
  

Серверы просто реализуют интерфейс:

 public class MyServer : IMyAmazingService {
    // ...
}
  

(то, как вы их размещаете, зависит от того, используете ли вы ASP.NET Ядро или собственные / неуправляемые библиотеки gRPC; оба работают)

и клиенты просто запрашивают интерфейс:

 var client = http.CreateGrpcService<IMyAmazingService>();
var result = await client.SearchAsync(query);
  

В приведенном выше случае было бы сделано предположение, что это Whatever.MyAmazingService / Search сервис в терминах gRPC, т.Е.

 package Whatever;
// ...
service MyAmazingService {
    rpc Search (SearchRequest) returns (SearchResponse) {}
}
  

но имена служб / методов могут быть настроены более явно, если вы предпочитаете. Приведенный выше унарный пример; для унарных операций результатом может быть любой из T , Task<T> , ValueTask<T> — или void / Task / ValueTask (которые все сопоставляются с .google.protobuf.Empty , как и метод без подходящего входного параметра).

Операции потоковой передачи / дуплекса выводятся автоматически, если вы используете IAsyncEnumerable<T> (для некоторых T ) для входного параметра (потоковая передача клиента), возвращаемого типа (потоковая передача сервера) или обоих (дуплекс).

Это то, чем я хотел бы заняться, но на сегодняшний день, нет: у меня не было необходимости изучать это, и это не достигло вершины моего невыполненного задания. Я стараюсь следить за тем, какие функции нужны людям, поэтому приятно знать, что вам это нужно, но сегодня: нет. В основном это вопрос времени — protobuf-net разрабатывается за счет моего свободного времени, если только у меня нет реальных оснований тратить на это «рабочее время».

Обновление: Я активно общаюсь с ребятами из Microsoft, которые работают над gRPC для .NET, и кажется вероятным, что мы попытаемся работать вместе здесь, чтобы это стало возможным с помощью функций gRPC в масштабе времени .NET Core 3.0, что означает: мы бы совместно использовали реализацию кода вызова службы, но разрешили бы ему работать с несколькими API-интерфейсами сериализатора.