...
- Currently the Frontend is fully dependent on APIs, so dashboard can be replaced.
- Next iteration will have custom reports, can be added as widgets.
- Currently, reverse engineering the instructor dashboard code to understand the data model usage.
- They use APIs where they exist.
- Couldn't find enrollments API.
- Using Course Blocks API.
- CSV reports will contain user data.
- If there is no cache or local storage of that data, then it might be fine.
- Adding APIs
- OSPRs would be against master; while they are on Ginkgo.
- Need an API to list the users per course, with filtering.
- edX is also planning to invest in APIs - needed for Frontend and Backend split as well.
- However, thinking about those APIs from the business needs perspective, not necessarily from the data model perspective.
- Can look at Figures' business requirements as input to API discussion.
- Would like to see
- More things pulled out of the core.
- For Insights, we depended on the event log rather than the SQL models.
- We assumed the models would change more often.
- While the event log could be translated.
- Historically, though, it seems we never really changed our models.
- edX.org's scale would likely not be able to execute Figures as is it currently designed.
- Currently, testing out rebuilding the LMS - in React with decoupled backend.
- Cron tab
- Pulls from platform's data and puts in Figures' data model
- Figure's frontend calls APIs in Platform LMS as well as APIs for aggregated data in Figures
- Are real-time use cases a reality?
- How is progress going on a daily basis, generally.
- Going through the day, hour-by-hour
- for example, for communication campaign
- Jill's post in Discourse also asked for real-time
- edX has heard about the flipped classroom use case - where educator wants to know about learner's activity.
- Lightning talk - CSS modules
- As long as endpoints with APIs are maintained, with advanced notice of changes/deprecation.
