Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Better terminal logs #844

Closed
ArielGueta opened this issue May 15, 2024 · 4 comments
Closed

Better terminal logs #844

ArielGueta opened this issue May 15, 2024 · 4 comments

Comments

@ArielGueta
Copy link

Hi!

We are encountering an issue where logging server responses that extend the Message class results in overly verbose logs. This verbosity makes it difficult to identify the relevant data because the log includes all methods from the Message class.

When logging responses, if an object extends Message, the entire object and its methods are logged, leading to extensive and cluttered output.

We implement a recursive check that identifies objects extending Message and selectively logs their data using .toJson().

If there's a more efficient way to achieve this, suggestions are welcome.

Thank you for looking into this. Any guidance or alternative solutions would be greatly appreciated!

@timostamm
Copy link
Member

Hey Ariel, we're working on a version 2 that doesn't use classes (see pre-release here). This should help you in your case.

Logging the JSON representation still seems like a good idea to me. It really depends on your use case. If you want to redact specific fields from your logs, you'll also be able to use custom options with v2 to implement a filter. For example, you could mark fields that you do not want to show up in logs like this:

syntax = "proto3";

import "google/protobuf/descriptor.proto";

message Person {
  string name = 1;
  int32 id = 2;
  string email = 3 [(redacted) = true]; // don't include in logs
}

// custom field option 
extend google.protobuf.FieldOptions {
  optional bool redacted = 1024;
}

It's a unique feature of Protobuf that can be very useful for cases like this.

@ArielGueta
Copy link
Author

We are working on a JS sdk based on this. Should we wait for v2?

@timostamm
Copy link
Member

You could start using v2 today (the main APIs are fairly stable and feature complete), but you wouldn't want to ship with a dependency on a v2 pre-release version.

We can't commit on a release date yet, but I'd be extremely bummed if we didn't cut a stable release within the next couple of weeks or worst case next couple of months. If you need help with your implementation on v2, please feel free to reach out to us via Slack, we're happy to help.

@ArielGueta
Copy link
Author

Great, thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants