...
External Guests in 2021 - In the past, we’ve invited special guests from other orgs, including a QA expert and an MFE expert. What topics/specialties would folks be interested for guests for next year? (Could also be from another edx-internal function or from the community.)
Early thoughts on approaches to splitting LMS and Studio (link) +1 +1 +1+1
Best Practices for having frontend code fail gracefully when backend APIs go down+2
When we upgrade backend services, the frontend also fails
ex: admin portal
portal.edx.org
https://github.com/edx/frontend-app-admin-portal/blob/master/src/components/TableComponent/index.jsx#L105-L114
ex: When SRE & Purchase upgraded ecommerce to avoid using an EOL database they decided it was ok that payment showed errors for a bit (partially because it was hard to fix)
It’s currently inconsistent - only available if the MFE chose to handle it
From frontend-platform’s perspective, it raises the error up to the caller
Can there be a toolbox for FE developers to choose from to handle graceful degradation?
Error page
Spinner
Banner
Message: "Oops, an error has occurred, please check our <status page> or reach out to <support> if you continue to see this message"
How to prioritize this effort?
Options
Have the default in frontend-platform be opinionated and fail strongly - the squad can then override ("How do we make the right way the easy way")
Don’t do the upgrade for the squad until the squad has demonstrated they are aware of this issue or addressed the issue
Currently it defaults to an error page with the message: “An unexpected error occurred. Please click the button below to refresh the page.”
ACTION
How to make it easy to add consistent alerting logic for MFEs
On call best practices and discoverability
Where should we be building docker images +2
Status Page(s) Best Practices
Maintenance Banner Best Practices
Things we don’t know about that will make containerizing edxapp hard +1
Backlog of Questions/Discussions
...