### Tasks
- [ ] Decide the aggregations and processing needed
- [ ] Add the aggregations/processing to KSQL streams
- [ ] jdbc-connector will sink the processed data into postgres
- [ ] Add endpoints to the appserver to expose this data (this can be a separate module of the appserver that can be deployed separately, can be a separate database too if concerned about performance)
Another alternative is to just expose the data from the timescaledb (grafana) using a microservice (similar to the appserver)
Since multiple components are involved (frontend and backend), we need to think hard about how to make this customisable in the best way possible. one option would be to make the backend (appserver) self describe what endpoints and data is available for a particular subject+project and the app can just pull that and display. Another option is to use radar-app-config to maintain a global config accessible by all the services involved.
Another alternative is to just expose the data from the timescaledb (grafana) using a microservice (similar to the appserver)
Since multiple components are involved (frontend and backend), we need to think hard about how to make this customisable in the best way possible. one option would be to make the backend (appserver) self describe what endpoints and data is available for a particular subject+project and the app can just pull that and display. Another option is to use radar-app-config to maintain a global config accessible by all the services involved.