Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feature: Define and implement Provider interface for providers package #5

Open
raamsri opened this issue Oct 3, 2024 · 2 comments
Open
Labels
enhancement New feature or request

Comments

@raamsri
Copy link
Contributor

raamsri commented Oct 3, 2024

feature: Define and implement Provider interface for providers package

Summary:

Implement Provider interface in the providers package. This interface will provide methods for interacting with various weather data providers.

Package providers must offer an interface and a factory method for weather data providers. This package is designed to facilitate the integration of various weather data providers by defining a common interface that each provider must implement. It may include a factory method to instantiate the appropriate provider based on a given name.

The main components of this package would be(Preemptively. This may change):

  • Provider interface: Defines the methods that each provider must implement.
  • NewProvider function: A factory method that returns the appropriate provider based on the name.

Expected usage:

	provider, err := providers.NewProvider("open-meteo")
	if err != nil {
	    log.Fatal(err)
	}
	data, err := provider.FetchData(queryParams)
	if err != nil {
	    log.Fatal(err)
	}

Details:

  1. Interface Description:
    Provider interface:

    package providers
    
    type Provider interface {
         FetchData(queryParams map[string]string) (*plumber.BaseData, error)
    }
  2. Package Description:

    • This package will include methods to retrieve data from different weather data providers.
  3. Outcome:

    • Provide a standardized way to interact with various weather data providers.
    • Facilitate easier integration and swapping of different providers in the future.
    • Seamlessly merge API response from multiple providers to realize the required set of plumber.BaseData fields.
  4. Dependencies:

    • No external dependencies apart from the obvious third party API providers
    • Ensure compatibility with existing packages that interact with weather data providers.
  5. Acceptance Criteria:

    • Implement the FetchData method in the new package. More may be added as necessary.
    • Update documentation to include usage examples and integration guidelines.
    • Write unit tests to verify the functionality of the new package. [deferring this for this package til testing modules are implemented for other simpler packages]
  6. Additional Information:

    • Consider future extensions to support additional weather data providers.
    • Establish the essential meteo parameters that aren't yet included in plumber.BaseData that's pulled from various providers
    • Ensure the package is designed to be easily extensible for new provider implementations.
@raamsri raamsri added the enhancement New feature or request label Oct 3, 2024
@raamsri
Copy link
Contributor Author

raamsri commented Oct 3, 2024

This will need many more dedicated issues to address and meet the desired outcome in smaller steps.

@yendelevium
Copy link
Collaborator

Cool

raamsri added a commit that referenced this issue Oct 6, 2024
This commit lays the ground work for fetching multi-provider API data by
the interface methods that every provider must implement.

It also includes the logic to set log level, which I couldn't pull out
as a separate commit. And, an HTTPClient interface signature change.

- Implement Provider interface for open-meteo.com
- Placeholders for meteoblue.com
- Unmarshals the data onto plumber.BaseData struct
- Return HTTPClient for HTTPClient.NewRequest() method so that client
  methods can be chained as resty natively does.

#5 #2 

Signed-off-by: Raamsri Kumar <[email protected]>
yendelevium added a commit to yendelevium/meteomunch that referenced this issue Oct 20, 2024
- Changed the function signature of the FetchData method in the Provides interface
- Added the SetQueryParams method to the providers aligned to the concerns raised in tinkershack#13

Resolves tinkershack#13
References tinkershack#5
raamsri pushed a commit that referenced this issue Oct 22, 2024
* Implement SetQueryParams in the Provider Interface

- Changed the function signature of the FetchData method in the Provides interface
- Added the SetQueryParams method to the providers aligned to the concerns raised in #13

Resolves #13
References #5

* Reduce redundant passing of queryParamters

- Add queryParams field on the providers
- Update SetQueryParams method to set the queryParams field on the provider
- Update NewOpenMeteoProvider() and NewMeteoBlueProvider() to set default QPs on the client
- Update FetchData() to only set the coords, and not the entire QPs

* Address the latitude-longitude/lat-lon discrepancy in the queryParans of MB
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants