Rework project to use DI instead of Singleton approach

[iwa]

No description provided.

[Copilot]

Pull request overview

This PR refactors the application from a Singleton pattern to Dependency Injection (DI) pattern, improving testability and architectural clarity. The monolithic AppState singleton is replaced with two focused components: Config for immutable configuration and DomainStore for thread-safe domain data management.

Key changes include:

• Introduction of DomainStore with mutex-protected concurrent access to domain data
• Separation of configuration into an immutable Config struct
• Refactoring of all utility and provider functions to accept dependencies as parameters instead of accessing global state

Reviewed changes

Copilot reviewed 14 out of 14 changed files in this pull request and generated 8 comments.

Show a summary per file

File	Description
internal/state/DomainStore.go	New thread-safe store for domain data with RWMutex protection
internal/state/Config.go	New immutable configuration struct for application settings
internal/state/AppState.go	Deleted singleton pattern implementation
internal/app/app.go	New application bootstrap that wires dependencies together
internal/utils/whois.go	Refactored to use DomainStore dependency instead of AppState
internal/utils/notifications.go	Updated to accept both store and config as parameters
internal/utils/env_import.go	Renamed to LoadConfig and returns initialized dependencies
internal/utils/cli_report.go	Updated to use DomainStore dependency
internal/utils/providers/telegram.go	Refactored to use Config instead of AppState
internal/utils/providers/discord.go	Refactored to use Config instead of AppState
internal/utils/providers/ntfy.go	Refactored to use Config instead of AppState
internal/api/routes.go	Updated to use factory pattern for handler with DomainStore
internal/cron/cron.go	Updated to accept store and config as parameters
cmd/expira/main.go	Simplified to delegate initialization to app package

Comments suppressed due to low confidence (1)

internal/utils/providers/discord.go:33

• The HTTP response status code is not checked. The Discord API may return a non-success status code (e.g., 4xx or 5xx) even if the HTTP request itself succeeds. Consider checking resp.StatusCode and returning an error if it's not in the 2xx range to properly handle API errors.

	resp, err := http.Post(config.DiscordWebhookURL, "application/json", bytes.NewBuffer(data))
	if err != nil {
		return err
	}
	defer resp.Body.Close()

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.