Develop protobuf (gRPC) decorators

[samchon]

export function message<T>(): string; // Protocol Buffer message
export function assertDecode<T>(buffer: Buffer): T; // safe decoder
export function assertEncode<T>(input: T): Uint8Array; // safe encoder
    // +) decode, isDecode, validateDecode
    // +) encode, isEncode, validateEncode

typia would support protobuf features soon.

Therefore, develop protobuf (gRPC) related decorators. One thing amazing is, it does not need any *.proto file definition. Just using pure TypeScript type would be possible, as TypedRoute and TypedBody are. Defining protocol buffer message and marshaling to binary data would be automatically done by AOT compilation.

New decorator names would be:

• ProtoRoute
• ProtoBody

[omid-mamandi]

we want to use nestia, when it can be ready for use?

[samchon]

Maybe 3-5 months

[L-U-C-K-Y]

Would be a game-changer to have the source of truth for GRPC from typescript

[samchon]

Currently, succeded to support protobuf through typia v5 update.

https://typia.io/docs/protobuf/message/

[L-U-C-K-Y]

Currently, succeded to support protobuf through typia v5 update.

https://typia.io/docs/protobuf/message/

Hi @samchon

Is it already possible to use the ProtoRoute and ProtoBody from Typia in Nestia?

I checked the Nestia docs and was not sure if this is working correctly.

Many thanks

[samchon]

I should develop this feature, but I'm sorry. I cannot sure when to start.

[L-U-C-K-Y]

I should develop this feature, but I'm sorry. I cannot sure when to start.

No problem at all, you are doing great work, just started also to sponsor you, would be great if we can have this feature, as it would allow us to migrate all of our projects to Nestia.

[L-U-C-K-Y]

Hi @samchon

I would kindly ask if it is planned in the near future to work on this feature? As our payloads are large, it would be a big performance benefit to use gRPC and it would enable our non-Nestjs Microservices to receive .proto definitions.

Many thanks!

[samchon]

Planning to develop websoket decorators and SDK first, and it would be next.

The date may be end of this year.

[L-U-C-K-Y]

Planning to develop websoket decorators and SDK first, and it would be next.

The date may be end of this year.

Thanks for the update!

[samchon]

https://nestia.io/docs/core/WebSocketRoute/

Have waited for a long time. I've finally succeeded to implement the @WebSocketRoute.

The GrpcAdaptor.upgrade() and @GrpcRoute() would be developed in the same way.`

[L-U-C-K-Y]

https://nestia.io/docs/core/WebSocketRoute/

Have waited for a long time. I've finally succeeded to implement the @WebSocketRoute.

The GrpcAdaptor.upgrade() and @GrpcRoute() would be developed in the same way.`

Great news, great work, many thanks @samchon

[samchon]

@L-U-C-K-Y I think you can take most (or more) advantages of gRPC in the @WebSocketRoute().

How about accomplish your mission with it? gRPC may needs lots of months as WebSocket was.

Also, as there's no way to use gRPC in the web browser, I may have to wait for a long time

[L-U-C-K-Y]

@L-U-C-K-Y I think you can take most (or more) advantages of gRPC in the @WebSocketRoute().

How about accomplish your mission with it? gRPC may needs lots of months as WebSocket was.

Also, as there's no way to use gRPC in the web browser, I may have to wait for a long time

Hi @samchon

Appreciate your efforts a lot, but I think that the @WebSocketRoute() would not be a suitable option for communication among our microservices with many replicas.

We have large payloads that are exchanged which could benefit from protocol buffers. If I'm not mistaken, web sockets would keep talking to the same replicas/servers due to session affinity, which would not allow effective load balancing, which is a central requirement.

For us, I think it's better if we wait until grpc is ready.

Many thanks

[zeallat]

Support for websockets is pretty amazing and cool. You are the best.