Conversation
Replace the hardcoded tutorial stub with a real Kubernetes exporter so the example can read Namespaces, ClusterRoles, and Pods from a cluster. Expand the tutorial for the new workflow and update Go/Nix dependencies to build the example.
gergely-szabo-sap
left a comment
There was a problem hiding this comment.
I suggested an improvement. Otherwise, it's a beautiful work!
🥇
| func uniqueStrings(values []string) []string { | ||
| seen := make(map[string]struct{}, len(values)) | ||
| unique := make([]string, 0, len(values)) | ||
| for _, value := range values { | ||
| if _, ok := seen[value]; ok { | ||
| continue | ||
| } | ||
| seen[value] = struct{}{} | ||
| unique = append(unique, value) | ||
| } | ||
| return unique | ||
| } |
There was a problem hiding this comment.
No need to change, but a more elegant implementation of this function could be provided by using https://pkg.go.dev/maps#Keys and https://pkg.go.dev/slices#Collect.
You build up the seen map as before and simply collect the keys.
| type collectedResource struct { | ||
| key string | ||
| object resource.Object | ||
| } |
There was a problem hiding this comment.
I find the collectedResource type too artificial in this example. Here, it serves as temporary storage for resources to be exported.
I would prefer to emit resources as soon as they are available (stream the resources) instead of collecting them in collectedResource first.
If we want to demonstrate the mkcontainer types, you could use them to cache the namespaces there. For example, if the user exports both Namespaces and Pods, you can avoid collecting the namespaces twice. Collect them in the mkcontainer type when you first need them, and retrieve them from the mkcontainer when you need them again.
Replace the hardcoded tutorial stub with a real Kubernetes exporter so the example can read Namespaces, ClusterRoles, and Pods from a cluster.
Expand the tutorial for the new workflow and update Go/Nix dependencies to build the example.
#30 #31 #32