|
|
|
|
|
by bliti
4648 days ago
|
|
You mention collecting data, which has been a big issue in this market. The local dentists (this is an offline startup) use a closed sourced program that does not export data. The only way to retrieve any data is to use automation scripts that "read" from the screen and dump it into CSV files (they use excel a lot). Once that is done, the script calls another one that sanitizes the data and inserts it into the database (PostgreSQL, in this case). I currently have a flexible API that allows me to make complicated queries by sending commands through an HTTP call. Say "GET /clients/where/__last-visit/20132009" and so on. On the front end, I have a fairly custom dashboard for each dentist (they all have specific needs due to different business sub-specialties). The dashboard calls the API and creates the reports automatically. They are update n amount of times a day, depending on the metric being observed. Given this information, and the one you provided me, can you give me your insight into how different your offering would be? My aim is to reduce complexity, and reduce business costs. Without eroding the service or client experience. I'm interested how my "small data system" would compare to yours in those terms. It may sound like I'm being pedantic, but I am genuinely interested in learning more. You could be the solution that saves me hundreds of hours of development time. |
|
Looks like you already built an API similar to ours, but if you ever reach scale/maintenance/availability bottlenecks then check us out.
Most of our customers use charts that query in realtime when the page loads or the user adds a filter or whatever, but batching reporting like you describe is a way to optimize the page load time.
Generally we want to help developers before they already built the solution themselves. I think your homegrown solution is probably exactly what you need right now to validate your product in the market. When you want to invest more in your architecture for improved performance, scalability, or reliability, then you can consider building v2.0 on Keen IO :)