RpcExplorer is a curses tool that allows the user to search for service methods defined in protobuf and interactively build and issue requests.
I built it a few months ago, and my team at Square has been using it to save time during both development and debugging when interacting with gRPC and proto-over-http servicse defined in protobuf.
If you use protobuf-based services, please feel free to play with it and let me know what you think!
It's been my experience that people usually build systems that expect a certain timeout for a certain service or perhaps service+method.
That said, not all clients are created equal. The ads folks who used to hit my system way back when had far tighter deadline requirements than the calendar or spreadsheet people, for instance.
I think the solution is more cultural than technical.
When a company develops a culture that fosters the creation of technical documentation, and encourages employees to document absolutely everything (both the how and the why), then institutional knowledge is simply a byproduct.
When a company focuses much more on shipping products and de-values everything from architecture documentation to API documentation, then institutional knowledge suffers.
However, to make the institutional knowledge useful, it must be easy to find. Thus, I think the second most important thing for capturing institutional knowledge is to have a small number of easily searchable places where documentation lives. Markdown files in the source are convenient place for documenting particular projects or code, but more general-purpose knowledge should be in a wiki or any other document store that is centrally searchable and update-able. An example of such general purpose knowledge is "how-to knowledge": How do I request the appropriate privileges to integrate my service with Service X? How do I make and deploy a staging build? How do I set up a new service?
Another sort of general-purpose knowledge that should have a single home is knowledge around context for past decisions that were made for good, but not obvious reasons. My team maintains a document called a Decision Log, where we record the context around and reasons for every decision that required more than roughly 10 minutes of thought. Longer decisions have their own docs, but they are linked from the central Decision Log.
I built it a few months ago, and my team at Square has been using it to save time during both development and debugging when interacting with gRPC and proto-over-http servicse defined in protobuf.
If you use protobuf-based services, please feel free to play with it and let me know what you think!