Feature Request: Enable Asynchronous Operations in entsoe-py

[JrtPec]

Preface: I have brainstormed this idea with GPT-4 and asked it to write a Github issue, here it is:

Hi everybody,

I'm currently integrating entsoe-py into a "Data Collector Engine" deployed on Azure, which consists of various functions aimed at collecting and processing data. These functions are triggered both by a schedule and by HTTP calls. As part of this integration, I've encountered a challenge related to the synchronous nature of entsoe-py, which can block and potentially interfere with other asynchronous operations within the Azure environment.

Given the importance of non-blocking operations in modern cloud applications, I'd like to propose an enhancement to entsoe-py to better support asynchronous workflows. This could greatly enhance its compatibility with environments like Azure Durable Functions, which provide built-in mechanisms for asynchronous HTTP requests.

To achieve this, I suggest modifying entsoe-py to allow for a more flexible use of its functionality, specifically by:

1. Allowing entsoe-py to prepare and validate queries, and return the necessary URL and parameters for the request.
2. Enabling users to defer the actual HTTP call to their own asynchronous handling mechanisms (e.g., Azure Functions in my case).
3. Using entsoe-py to parse the HTTP response once it's received.
4. This approach would not only solve the blocking issue but also leverage the strengths of the user's environment (such as Azure's asynchronous HTTP capabilities).

For my immediate needs, I'm particularly interested in applying this to the day-ahead prices functionality. However, I believe this could be beneficial for a broader range of entsoe-py's features and its users.

I would love to hear the community's thoughts on this proposal:

• Do you see any potential issues with splitting the functionality in this manner?
• Would anyone else benefit from asynchronous support in entsoe-py?
• Are there other, perhaps better, ways to achieve asynchronous operations with entsoe-py that I might not have considered?

Thank you for considering this proposal. I am looking forward to your feedback and am open to contributing to the implementation of this feature.

[JrtPec]

That was actually easier than expected. See PR #316.

Works only for Day Ahead Prices for now.

[fleimgruber]

Before seeing this feature and it's design, I often wished for an API such as client.query_day_ahead_prices_async(country_code, start, end) that I could await from async user calling code.

The proposed design turns the problem inside out so would be preferable to the mentioned alternative design with a lot of new API code. For this to work smoothly the parsing code should be tightly coupled to the preparation code.

[fboerman]

hi @JrtPec and @fleimgruber I like this design idea in the PR to do the prepare, but not fully switch to async. that last one would be a lot of work and require loads of changes, while adding preparation is a lot simpler. lets discuss in the PR

[Astlaan]

Before seeing this feature and it's design, I often wished for an API such as client.query_day_ahead_prices_async(country_code, start, end) that I could await from async user calling code.

The proposed design turns the problem inside out so would be preferable to the mentioned alternative design with a lot of new API code. For this to work smoothly the parsing code should be tightly coupled to the preparation code.

I too was hoping for something precisely like this. The API request time can be long, especially if we want to query multiple years at once (since the API only allows for max of 1 year per request) and multiple types of data (generation, cross-border, etc).

I ended up implementing my own specialized async solution for the specific request I needed to make (before I found out this library), but would be nice to have it here too.