refactor: Refactor Go architecture #43
Conversation
Refactoring Go SDK to be closer to the API and internal representation that we have with the Rust SDK. Just doing Datadog at the moment and seeking some feedback then i'll port the others and add docs and tests.
go/adapter.go
Outdated
| return fmt.Sprintf("%032x", t) | ||
| return AdapterBase{ | ||
| // TODO set to some kind of max, add dump logic | ||
| TraceEvents: make(chan TraceEvent, 100), |
There was a problem hiding this comment.
My plan is for the adapter to hold a bucket of these events and dump them after MAX is reached or after some timeout occurs. So it may make sense to default this to MAX. but it could also be something configurable by the end programmer.
| Collectors: map[*Collector]chan bool{}, | ||
| return AdapterBase{ | ||
| // TODO set to some kind of max, add dump logic | ||
| TraceEvents: make(chan TraceEvent, 100), |
There was a problem hiding this comment.
Sends to this channel will block once the channel reaches 100 events. I think thats probably ok, but wondering if this is intentional. We can omit the buffered size and let the channel grow as needed.
There was a problem hiding this comment.
Yeah i think non-buffered might be the way to go but let me think about it for a moment. my intention with using a buffered channel is if the adapter is busy then it may take some time to read off this channel which would block the sender right? By default sending a message to a channel blocks until the receiver synchronizes. Ideally the adapter just pulls messages off this channel and only puts them in a local slice, then it submits them offline in another goroutine. but i haven't done that yet. so this is acting at the bucket.
There was a problem hiding this comment.
I see -- yea that makes sense!
There was a problem hiding this comment.
I'll make a follow up for that. Goal will be to add the bucket on the adapter side and test that this channel can't get blocked. We just need to make sure that the adapter's main routine only reads off this channel as fast as possible. And if it can't put the events in a bucket it should just throw them away and log an error. But never block.
Refactoring Go SDK to be closer to the API and internal representation that we have with the Rust SDK.