Is it possible to get raw message buffers in client methods?

[nurbo]

Is there any way to omit deserialization in client methods and obtain the raw buffer instead? Or would I have to roll out own versions of createUnaryMethod and alike?

Middlewares do not seem to have access to the raw message either.

Context: I was thinking of isolating the gRPC communication and logic in a (shared) worker. Passing the raw UInt8Array over the message port would avoid the "duplicate" deserialization from decoding and the structured cloning that will take place when sending an object to the main thread.

One idea that crossed my mind was to implement (de)serialization as a (default) middleware. In this way other serialization frameworks could potentially be used, for example flatbuffers, which also has some gRPC support. Having access to the raw messages in middlewares might also be useful and could be achieved just by middleware ordering.

[aikoven]

Yes, this is definitely possible, though it would create some problems with typings.

When you create a client, you pass a service definition, which contains method descriptors that have serialize and deserialize methods. You could bake your own service definition where these methods are identities, something like (type checks ignored):

const client = clientFactory.create(
  {
    someMethod: {
      path: '/some.package.SomeService/SomeMethod',
      requestStream: false,
      responseStream: false,
      requestSerialize: value => value,
      requestDeserialize: value => value,
      responseSerialize: value => value,
      responseDeserialize: value => value,
      options: {},
    },
    // ... other methods
  },
  channel,
);

This way, no serialization will happen: the client will expect Uint8Arrays as requests, and will return Uint8Arrays as responses.

You may create these custom service definitions dynamically from original ones.

Though not initially intended to, middlewares actually can alter messages that pass through them — i.e. pass a value different from call.request to call.next, and yield a value different from the one yielded from call.next. As I said, the main problem is the typings: this library tries to have as strong typings as possible, so they won't allow to change the type of request or response. However, I don't see any evil in manual casting to any, if it is encapsulated in your module.

[nurbo]

Thanks for the response! I see, casting to any or some Typescript magic would be required, but otherwise one could achieve this by overriding the serialization at creation time.