@tantialex I have modified my entire system with a polling mechanism, where I had to start tracking each individual order I put through, modifying their state as I go. For every position that I’m in that has trailing stops that haven’t activated yet, I loop through all of those positions and actually send a request through the API for the candlestick data for that position. I had to start tracking the open_time
for each trailing_stop I put through. I limit the query for the candlestick data to 99 candles, starting at the tracked open_time
, and only take the 1d
interval candles because I don’t really care about the actual candlestick information, and I want to minimize not only the amount of request weight
resources that I’m using up, but also the actual computational resources that I’m using up in the process. I then retrieve the high
values from those candles, sort them, and pick the highest one. I then make inferences for that position, which of the trailing stops have been activated, and I modify those ones’ states individually. I then also move my stop loss based on the findings and send myself notifications through my front-end.
As a client of this API, these are the things that I had to do to compensate for the incompleteness of the trailing stop activation notification in the way that I’ve detailed it to you:
- Add state tracking to my database’s representation of a trade and a follow-up-order
- Add a timer that does things every n seconds
- Track every trade with some state, so that I can loop through the relevant ones every n seconds
- Retrieve candlestick data for the positions that are relevant
- Parse them, sort them and retrieve the highest value
- Look through all the open trailing stops for the position, adjust their internal state manually if it’s found that the highest high is higher than the specified activation_price
- For each one that was adjusted to be activated, send a notification through
- Determine to which level the stop-loss now needs to be moved to, and move it
- When all the trailing_stops have been activated, update the original order to say that we should exclude this one from the loop now
- I still need to catch the
order_update_events
that are currently happening, so that I can know when they actually execute and make me money haha, I’ll probably implement that today, but essentially I need to also hook that in to the whole state tracking system too so that my polling mechanism knows to skip the ones that aren’t relevant anymore. There will be some details there that I wouldn’t have had to deal with if I was just notified about the activation_price being hit.
So yeah, I had to come up with a whole convoluted system just as a workaround, and it’s not even perfect because, now:
- I’m using up
rate limit
resources that I did not need to use up before, and that I would not have had to use up if theactivation_price
notification was in place - I’m using up computational resources on a system that would not be necessary if
activation_price
notifications were in place - I’ve introduced an inherent delay into the system of up to n seconds, at any given time my local representation of what’s happening might be out of date by up to n seconds, which isn’t much of a problem but it’s a nick on the paint, yknow?
For the last issue there, you might argue, “just use websockets to stream the stuff then you’re always up to date”. The issue with that is one of tradeoffs. By using the websocket streams, I would now be using a metric firetruck-tonne of computational resources to keep track of something that a very simple order_update_event
would have solved. Computational resources are not free. I’m running my system on a little laptop with a battery life, and each little computation that I need to make cuts into that battery life. If I was using a cloud computing service, each little computation would’ve cut into the computing costs.
Like, without this very simple thing, myself and a whole bunch of others need to go through a whole bunch of mission and make unnecessary tradeoffs that wouldn’t be necessary to go through or make if the order_update_event
was sent through when an activation_price
is hit, which is explicitly specified in the first place, and thus is important to the user of that feature.
I cannot make sense of how you can’t perceive the value here.