Skip to content

Conversation

pinglin
Copy link
Member

@pinglin pinglin commented Aug 6, 2025

Because

  • all backends should share the x/minio package for accessing MinIO for blob operations.

This commit

  • refactors the codebase to adopt the x/minio package.

Copy link

linear bot commented Aug 6, 2025

jvallesm
jvallesm previously approved these changes Aug 7, 2025
Copy link
Collaborator

@jvallesm jvallesm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Besides removing deprecated methods (which unlocks further cleanup in the artifact service 👍), the new structure is significantly tidier ✨ Thanks for addressing this.

I added a couple of nonblocking comments regarding the fetcher injection.

"github.com/instill-ai/x/client"
"github.com/instill-ai/x/minio"
"github.com/instill-ai/x/temporal"
clientx "github.com/instill-ai/x/client"
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: I wouldn't alias these unless there's a conflict with other package name (e.g. when we use the Temporal SDK and x/temporal, or when partially migrating a package like resource and we might need to use both the local and the x resource packages).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The references of x packages across all backend repos can indeed often encounter naming conflict, especially for client, temporal, etc. I found it can improve readability by appending x as suffix to indicate the use of the x package no matter how.

return compStore
}

// GetBinaryFetcher returns the binary fetcher instance used by the store
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: since Store is exported and used directly, not as an implementation of an interface, we can just make the s.BinaryFetcher field exported instead of implementing a getter method.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you agree with this comment it wouldn't even be necessary to export it, as the downstream methods will initialise the fetcher themselves.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's a good point. I wasn't aware that component/store package has been instantiated in each reference.

return &fetcher{
httpClient: resty.New().SetRetryCount(3),
}
}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

❓ Do we need an interface here? It feels like unnecessary indirection. Here you removed the fetcher from the constructor params, but in other constructors where the arguments aren't wrapped in a struct you've kept them.

I think we can directly initialise binary.NewFetcher() wherever we're going to use it. We don't need to leverage the interface for testing and passing it nor having a single shared instance offers any benefit, and removing this would shorten the constructor signatures.

Suggested change
}
// Fetcher can be used to fetch binary data from a URL.
type Fetcher struct {
httpClient *resty.Client
}
// NewFetcher creates a new BinaryFetcher instance.
func NewFetcher() *Fetcher {
return &Fetcher{
httpClient: resty.New().SetRetryCount(3),
}
}

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, that makes sense.

@pinglin pinglin marked this pull request as draft August 9, 2025 18:07
@pinglin pinglin force-pushed the main branch 7 times, most recently from f54c7c6 to ce9c44c Compare September 22, 2025 12:32
@pinglin pinglin force-pushed the main branch 11 times, most recently from 203fb3f to 1153a09 Compare September 27, 2025 21:30
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

Successfully merging this pull request may close these issues.

2 participants