Support Board
Date/Time: Fri, 14 Mar 2025 15:24:02 +0000
[Programming Help] - Custom data into SC
View Count: 266
| [2024-12-28 18:12:48] |
| User806682 - Posts: 20 |
|
I have a data feed of computed data which I’ve managed to get into SC via a custom study but it’s not the best solution. I currently provide this study to my users for them to see the data in SC. Basically, what I’ve built is an HTTP fetcher that puts any new data plots into the matching subgraph index but this isn’t ideal. I’m curious if there’s a way for me to get time series data into SC via a custom symbol. Date Time Of Last Edit: 2024-12-28 18:14:50
|
| [2024-12-29 00:50:12] |
| User719512 - Posts: 302 |
|
really not enough to go on here to give great advice. Basically, what I’ve built is an HTTP fetcher that puts any new data plots into the matching subgraph index but this isn’t ideal.
What's not ideal?if the answer was yes, you can get a time series into Sierra, then the problem would move to how to update that data stream, or what mechanism Sierra would magically do this for you. if you provided a list of date/time to Sierra it would have to do work to align your data to chart bars. Same thing you can do from your own study. Making assumptions based on other information you provide... you have users: how many? what is the anticipated scale of this? do you anticipate using a CDN, simple Heroku flask server, etc.? you have an http fetcher, which probably implies this is not a real-time feed and some lag is ok. if this is more real-time, then we come back to scale and your data stream being push or pull? (huge rabbit hole for event bridges, scalable design, distributed network, servers per geographic region) pulling from a Sierra study at some rate you want to monitor and not a chart update interval like 10 times a second might be just fine. if so, then you'd want to spend time on your REST API for efficient pulling of all data, then a method for efficient updates with a param to the API for last item seen, resume handle, etc. parsing this data in your study and aligning to nearest/containing bar index should be efficient and you'd most certainly make use of some persistent variables for tracking state. -- Not an answer to your question per se, but some things to ponder and elaborate on so perhaps you get the desired outcome to your problem statement. |
| [2024-12-29 15:10:48] |
| User806682 - Posts: 20 |
|
Thanks for the response. Currently I have about 20 users, as this is a brand new study it is likely to grow as I've just been promoting it for the last couple of weeks. The study I built currently fetches data every 3 seconds, implying that the data doesn't need to be realtime but near realtime is important. I initially tried to implement websockets in the custom study to make it a push versus a pull but was having issues with the implementation so I've punted on this until scaling becomes more of an issue. pulling from a Sierra study at some rate you want to monitor and not a chart update interval like 10 times a second might be just fine.
if so, then you'd want to spend time on your REST API for efficient pulling of all data, then a method for efficient updates with a param to the API for last item seen, resume handle, etc. parsing this data in your study and aligning to nearest/containing bar index should be efficient and you'd most certainly make use of some persistent variables for tracking state. This is more or less what I have already implemented. What I'm curious about is if SC had a different way to get realtime data into SC via a custom data feed/symbol. It sounds like this isn't the case. I'm curious if this is something SC would be interested in building? Alternatively, I could ask if SC would be interested in building a socket API that developers could use. This would greatly facilitate things for me. |
| [2024-12-29 16:24:43] |
| User719512 - Posts: 302 |
|
Sounds like you need to build locally if not already doing so, from visual studio for example. Then you can use any library, header, API you want.
|
| [2024-12-29 16:30:30] |
| User806682 - Posts: 20 |
|
Yes, I was doing this and was able to build the DLL locally successfully. Unfortunately, when running the study it was throwing an exception that I wasn't able to figure out. With more time I'm sure I can get to the bottom of it. I wasn't sure if it was due to the nature of the study function being called over and over or what exactly. In the future I can clean up my study a bit and share the code, maybe someone could help. Thanks. |
To post a message in this thread, you need to log in with your Sierra Chart account: