reidbuzby
Joined 3 years ago
Karma
30
Submissions
8
Member since
Oct 18
Recent submissions
Comment · 2 years ago
Comment · 3 years ago
Thanks for the comment, it seems like you know a lot more about this than I do.
This was a solution that has worked well for my company that averages <1 req/s, so yes I have not tested it under more extreme conditions. This is version 1.0.0 so it is quite new and naive by design. I was posting here to get some feedback on the initial version and see how I can improve it, which you have given me!
Feel free to contribute to the project! It seems like your expertise applies nicely!
Comment · 3 years ago
Support for multiple keys is in the works! See this issue for updates: https://github.com/konigsoftware/konig-kontext/issues/8
Comment · 3 years ago
You do get the same explicit schema and type safety with this library. The context values can be typed using a protobuf message: https://github.com/konigsoftware/konig-kontext#protobuf-mess..., or any other type you'd like. Although you are right, it is not explicitly in the request schema but that's kinda the point.
Comment · 3 years ago
Ditto whats been said before. It can be very cumbersome to update multiple request/response types with new data especially if an intermediary service has no use for the data and is simply passing it through.
Comment · 3 years ago
Hey everyone, I've recently created an open source library on top of grpc-kotlin and grpc-java that allows you to propagate a context across microservice boundaries throughout an entire request lifetime. The existing io.grpc.Context (https://grpc.github.io/grpc-java/javadoc/io/grpc/Context.htm...) only propagates a context across API boundaries within the same container and does not cross microservice boundaries.
It's called KonigKontext, check it out here: https://github.com/konigsoftware/konig-kontext!
Example use cases include:
Propagating security principals, or user credentials and identifiers throughout an entire request lifetime across all of your microservices. Propogating distributed tracing information. Set a request trace id upon receiving a request and later access that id in any downstream microservice. However, Konig Kontext is built to support any type of context value, so it can be extended to fit any specific use cases as well.
Let me know what you think!
Let me know what you think!