Better JSON output support

[pouriyajamshidi]

Better JSON output support

[doclai]

We may not just keep them simply as "message" but, for example {"message":"total uptime: 3 seconds"} as key "total uptime" with value "3 seconds". Then we can easily jq the result, for example
echo '{ "total uptime": "3 seconds" }' | jq '."total uptime"'
We may clean some long strings, like "started at: 2022-07-10 17:57:27 ended at: 2022-07-10 17:57:30 duration (HH:MM:SS): 00:00:02"

[pouriyajamshidi]

Hey @ravsii,

Do you want to keep it all in the same file (statsprinter.go)? Maybe we split it into separate plane/json printers?

I rather keep things simple and easier to work with. If your proposal of splitting it in another file leads to a cleaner code base, I have no objections.

My main issue is with programs that end up with like 15 different files for a simple thing. Rather common among OOP lovers. 😄

I'm thinking a good solution for this will be using a one big struct with a bunch of fields that have json:"...,omitempty". There are a lot of info we can put in there, yet keep unnecessary(not related to a specific event) fields empty

It is fine. As stated above, it is better to keep things simple. So if some information is not required, there is no need to cram it there.

Nonetheless, think of this JSON output as something closely similar to what we send out to STDOUT. This JSON output will be consumed by a service that is looking for similar information to feed into monitoring systems.

Let me know if you wanna brainstorm further and take your time thinking about a clean solution.

P.S. Why are comments using a /* ... */ format?

Not quite sure if I understood this one. If you mean in the code, you can do multiline comments with that. instead of using // on every line. If I did not understand correctly, feel free to enlighten me.

Thanks a lot!

[pouriyajamshidi]

Guess that's me then, haha. I asked because I often saw such CLI's code is being in the root / directory(so that it could be imported easily), while the entryping for the CLI itself is in /cmd/cli/main.go or something. I guess the main advantage of such approach is not having to specify new files in go build while also splitting CLI and the core logic.

Right. different projects use different approaches. This project was an excuse for me to learn Go at the time and since there was no official guide on how to structure your program, I just put everything in the root. 😄

How about I try to implement it and submit a draft pull request, so you can see how it turned out and make suggestions? I think there are so many nuances (mainly "results" screen) and it's better to address each individually.

Sounds good to me! Thanks in advance.

Sorry, just a nitpick from me. I've never seen /* ... */ comments in a golang codebase, probably because the official article always uses the // style, except for the doc.go file.

Ah, I see. My C "background" has spilt into Go. 😄

We had another very active contributor who also used that /* */. I think this is more of a personal preference and I don't oppose against any form. They get stripped by the compiler anyway.

Thanks for the answers @pouriyajamshidi, I'll start working on it then!

My pleasure. Thanks and good luck.

P.s. Please make sure to rebase to version 1.21.2. Just pushed some stuff.

[pouriyajamshidi]

Indeed. The goal of this issue is to exactly do that.

[ravsii]

Is this still open?

[pouriyajamshidi]

Is this still open?

Yes, feel free to reach out in case you wonder what needs to be done.

My example on top is not really "JSON" standard.

[ravsii]

@pouriyajamshidi
I did read the code of printers, so here are my thoughts:

1. Do you want to keep it all in the same file (statsprinter.go)? Maybe we split it into separate plane/json printers?
2. I'm thinking a good solution for this will be using a one big struct with a bunch of fields that have json:"...,omitempty". There are a lot of info we can put in there, yet keep unnecessary(not related to a specific event) fields empty

Something like

type JSONEvent struct{
	// Mandatory
	EventType string `json:"event_type"` // something like "ping", "stop", "stats", "retry", ... basically one for each "event type"
	Message string `json:"message"` // user-readable message, we could reuse the same message that we have now

	// Optional fields for better parsing.
	// This would duplicate data from message for 3rd party programs to parse
	// so that they don't need to use string split or regex to give info from our messages
	TotalUptime time.duration `json:"total_update,omitempty"`
	TotalDowntime time.duration `json:"total_downtime,omitempty"`
	// other fields...
}

I didn't really think deep about the format, it's just a general IDEA.

P.S. Why are comments using a /* ... */ format?

[ravsii]

I rather keep things simple and easier to work with. If your proposal of splitting it in another file leads to a cleaner code base, I have no objections.
My main issue is with programs that end up with like 15 different files for a simple thing. Rather common among OOP lovers. 😄

Guess that's me then, haha. I asked because I often saw such CLI's code is being in the root / directory(so that it could be imported easily), while the entryping for the CLI itself is in /cmd/cli/main.go or something. I guess the main advantage of such approach is not having to specify new files in go build while also splitting CLI and the core logic.

But I was just asking here, it's not a suggestion.

Nonetheless, think of this JSON output as something closely similar to what we send out to STDOUT. This JSON output will be consumed by a service that is looking for similar information to feed into monitoring systems.

Let me know if you wanna brainstorm further and take your time thinking about a clean solution.

How about I try to implement it and submit a draft pull request, so you can see how it turned out and make suggestions? I think there are so many nuances (mainly "results" screen) and it's better to address each individually.

P.S. Why are comments using a /* ... */ format?

Not quite sure if I understood this one. If you mean in the code, you can do multiline comments with that. instead of using // on every line. If I did not understand correctly, feel free to enlighten me.

Sorry, just a nitpick from me. I've never seen /* ... */ comments in a golang codebase, probably because the official article always uses the // style, except for the doc.go file.

Thanks for the answers @pouriyajamshidi, I'll start working on it then!