search

frequenz-floss / frequenz-api-electricity-trading

gRPC+protobuf specification and Python bindings for the Frequenz Electricity Trading API
MIT License
0 stars 6 forks source link

Remove `filled_quantity` field from `OrderDetail` message #60

Open matthias-wende-frequenz opened 3 months ago

matthias-wende-frequenz commented 3 months ago

What's needed?

The filled_quantity field has redundant information that can be deduced by a simple subtraction of open_quantity from order.quantity.

Proposed solution

We can add this a back as a property to the SDK at a higher level above the API client or it can simply be calculated in any application.

Use cases

No response

Alternatives and workarounds

No response

Additional context

No response

camille-bouvy-frequenz commented 1 month ago

Was this completed? It shouldn't have been done because we agreed not to remove this field in the end

matthias-wende-frequenz commented 1 month ago

We agreed that one of filled or open can be removed due to redundancy. In case I missed the discussion about not removing it, can you please give context, why this shouldn't be removed?

camille-bouvy-frequenz commented 1 month ago

We agreed that one of filled or open can be removed due to redundancy

When or where? I thought we concluded on not removing it but I cannot find this conversation and my memory might be tricking me.

why this shouldn't be removed?

Currently, the app is using the filled_quantity field to make some informed trading decisions. This could indeed be deducted by the subtraction but I think it's more intuitive & user friendly to have both. I also looked into how other markets were doing and they have a similar approach, I don't think it's that terrible to keep both to be honest.

camille-bouvy-frequenz commented 1 month ago

ChatGPT's take on it:

In the context of designing an API for electricity trading, the presence of open quantity, filled quantity, and the original quantity fields in the OrderDetail message can indeed be seen as redundant from a strict data normalization perspective. However, redundancy in API design is not always a bad practice, especially if it enhances usability and reduces the likelihood of client-side calculation errors.

_In financial and trading markets, APIs often prioritize usability and convenience, sometimes at the cost of strict normalization. It's common to see APIs providing both open and filled quantities for the reasons mentioned above. Given the context and the typical practices in trading APIs, retaining both open_quantity and filled_quantity fields in the OrderDetail message is justified. It aligns with a user-centric approach, ensuring that users have all the necessary information at their fingertips without needing to perform additional calculations._