You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'd love to see the ability to statically generate code (not just interfaces) as part of a build process, instead of creating it dynamically when the application starts. I'm currently using the static generation of grpc-node to build my client and server, but would like to move to the observable model because it feels like a much more natural API.
@majelbstoat Sorry, #30 is about something else.
I did not plan to use the static version, but I can change my mind :) Can you explain what is the benefit of using the statically generated code vs interfaces and plain JS objects?
Some of it is admittedly just personal preference, where I can look at the code generated by the build step and understand exactly what's going on. For my specific situation, protos are stored in a global common path in a monorepo and the build step arranges for the right generated code to go into the right Docker image for deployment. The protos themselves don't actually go into the Docker image.
But also from a practical perspective, I'm generally in favour of doing preprocessing things offline, once. Application startup time can be a factor, especially if there are lots of protos, and you're using something like Knative to spin up new instances in response to load.
I'd love to see the ability to statically generate code (not just interfaces) as part of a build process, instead of creating it dynamically when the application starts. I'm currently using the static generation of grpc-node to build my client and server, but would like to move to the observable model because it feels like a much more natural API.
Perhaps this is what is intended by #30?
The text was updated successfully, but these errors were encountered: