Andal.LND/edx-platform
6
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Merge pull request #24538 from edx/ormsbee/adr-role-of-xblock

Browse Source 
ADR for the role of XBlock
This commit is contained in:
David Ormsbee
2020-08-26 12:12:20 -04:00
committed by GitHub
parent 6e8a114b96 607400c403
commit dfa9755f86
1 changed files with 140 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

140
docs/decisions/0006-role-of-xblock.rst Normal file
View File

@@ -0,0 +1,140 @@
Status
======
Proposed
Context
=======
XBlock was first envisioned as a nearly all-encompassing, dynamic system. How
many points is a problem worth? Call its ``max_score`` method. When is it due?
Check for the ``due`` attribute. What other XBlock content does it contain? Ask
the XBlock for its children. The course content was an object graph of XBlocks
that were free to implement this sort of functionality in different and
potentially very powerful ways, allowing for rapid experimentation in grading,
navigation, etc. This was especially important for edx-platform, which started
life as a rapidly developed prototype for courseware.
Unfortunately, such an open ended system made it extremely difficult to make
guarantees about performance and stability. For instance, many assessment XBlock
types will return a ``1`` for its ``max_score`` method, but ``ProblemBlock``
will introspect its XML to determine how many response fields it has, and use
that figure. In cases where these problems had to run sandboxed code, getting
the maximum possible score might involve forking an entire new process and
making IPC calls to it. If an XBlock wanted to determine its maximum score by
making a blocking HTTP request to a third-party service, there is nothing
stopping it from doing so.
This made operations that traversed many XBlocks (such as navigation, grading,
or sequence rendering) especially unpredictable, as the cost of getting the most
basic information could vary by literally six orders of magnitude. Any one
misbehaving XBlock could sabotage the entire request.
There were also downstream complications with allowing XBlocks so much freedom.
Systems such as analytics could not make basic assumptions about course
structure and problem metadata. If XBlocks wanted to render different child
XBlocks to different users, or make a problem worth more to users named "jarvis"
on Wednesday afternoons, it was free to do so. But the analytics system couldn't
easily introspect all this internal XBlock logic, meaning that it had to either
make assumptions that could be incorrect, or dynamically query XBlocks in a way
that was unpredictably expensive.
To address these issues, we were forced to sharply constrain what XBlocks were
permitted to do in practice. This stabilized the site and brought performance to
a tolerable (though not great) level, but at a significant cost. Numerous low
level optimizations and access patterns complicated the code, while at the same
time compromising some of the expressive power of XBlocks. Many of the API calls
that *look* dynamic were actually constrainted with unstated assumptions–maximum
scores are assumed to be consistent across all user, courses are assumed to have
a Course → Section → Subsection structure, etc.
Reaching beyond these constraints is still possible, but the results are
unpredictable. The LMS will still render unusual navigational structures if you
import it directly via OLX, but mobile clients and analytics will likely break.
You can define different max scores for different students on the same problem,
but you will likely see bugs in various places where those scores are cached and
displayed.
Largely because of these issues, the XBlock runtime gradually shifted away from
the all-encompassing role it once played in courseware:
* Grading and Scheduling became distinct subsystems with their own data models
and APIs. Instead of these systems synchronously pulling data from XBlock at
query time, we push XBlock data into these systems and query them using their
own APIs. This has vastly increased the operational stability of the platform.
* LTI support has been extracted from ``LtiConsumerXBlock``, so that LTI
integration can happen outside the XBlock runtime.
* There is active planning to add limited QTI support to Open edX.
* The ``learning_sequence`` application is being developed to take over Section
and Sequence level navigation, decoupling those concepts from the XBlock
runtime in the LMS.
* There is a strong interest in creating more adaptive and composable courseware
experiences which are difficult to do within the constraints of the XBlock
runtime.
* There have been early conversations around what a successor to XBlock might
look like, though no development work has begun.
At the same time, it's important to note that there are hundreds of XBlocks in
existence and a vast quantity of valuable content that has been written for
those XBlocks. Preserving the viability of this content is critical to the
success of Open edX.
Decision
========
XBlocks have provided us a fantastic source of innovative content, at the cost
of many operational issues. We'll proceed in a way that allows us to preserve
the most valuable parts of the XBlock framework, while developing a more
performant, XBlock-agnostic layer of extensible LMS APIs.
In concrete terms:
* XBlocks will continue to be supported at the Unit and individual module level
(e.g. ProblemBlock, VideoBlock). XBlocks will execute in a container that only
has their Unit (VerticalBlock). They will be allowed to query sibling blocks,
but will no longer be allowed to freely query their ancestors to get at
content in other units, sequences, or the root Course block.
* Responsibility for higher level navigation across collections of content (i.e.
Sequences, Sections, and Courses) will move to dedicated applications that
will have their own, XBlock-agnostic data models and APIs.
* A new application will be created to make an XBlock-agnostic model of Units in
the LMS, similar to the work that is currently being done around Sequences in
``learning_sequences``.
* OLX will continue to be supported, including the OLX for navigational
structures. They will be mapped to new LMS models and APIs, instead of the
XBlock runtime.
* XBlock will eventually become a peer runtime to other systems for pluggable
course content.
* Navigation will have its own set of dedicated, pluggable APIs that are
separate from the rendering of individual Units.
Goals
=====
1. Enable rapid innovation in courseware content and navigation.
2. Preserve backwards compatibility with existing XBlock content.
3. Improve the reliability, security, and performance of the platform.
Consequences
============
A DEPR will be created for removing the ability for XBlocks to reach outside
their unit in various ways, such as calling ``get_parent`` above the Unit level
or ``get_course`` to get the root Course XBlock. This would likely happen in the
Lilac timeframe. XBlocks that are part of the default install of Open edX will
be updated as necessary.
Background
==========
The following give a much more detailed account of the various challenges we've
faced with the XBlock framework over the years:
* `XBlock Lessons Learned <https://docs.google.com/document/d/1Flj2MS5Neyw6ilSMPdjHqP_4ATX3Qs_pcQdLJIpeSLA/edit?usp=sharing>`_
* `XBlock Lessons: Plugin Performance and Grading <https://engineering.edx.org/xblock-lessons-plugin-performance-and-grading-2f85a1d6fb2a>`_
* `XBlock Field Data Complexity <https://medium.com/@dormsbee/xblock-lessons-field-data-complexity-2ef32d961b97>`_