Static generation vs loading protos at runtime

[JustinBeckwith]

So, I'm in no way an expert on gRPC. I've noticed that we seem to be shipping *.proto files in our libraries, and then parsing/loading them at runtime. I also notice that we tend to do a lot of this synchronously, and during construction.

What do folks think of us... not doing that? Just guessing, but if we use pbjs to generate the stubs at compile time, wouldn't that save us a fair bit of runtime loading perf?

@ofrobots @alexander-fenster @crwilcox @kinwa91

[jkwlui]

Is this in the scope of the upcoming microgenerator work? I feel like we would be able to take advantage of generated typescript protobuf code..

[jkwlui]

Referencing existing issues:
nodejs-firestore: Unacceptable cold start get() performance
nodejs-kms: Significant overhead / delay decrypting on cloudfunctions at first

[evaogbe]

It looks like protobufjs doesn't support gRPC: grpc/grpc-node#528

[evaogbe]

To be clear, it doesn't support gRPC directly. @grpc/protoloader uses protobufjs internal.

[noahdietz]

@eoogbe any update on this issue? Thanks!

[JustinBeckwith]

I'd like to keep this open for discussion. It looks like this is something we should engage with the gRPC team.

[noahdietz]

@eoogbe Is this something you can take to the gRPC team for exploration or should we assign it to another for follow up?

[alexander-fenster]

We don't load protos directly anymore, instead, we use pbjs to produce a JSON and load it.