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

fix: RST formatting for APIs ADR. (#26336)

Browse Source
This commit is contained in:
David Ormsbee
2021-02-03 08:13:25 -05:00
committed by GitHub
parent 139144350f
commit 185e6c2d76
2 changed files with 27 additions and 25 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
openedx/core/djangoapps/content/learning_sequences/README.rst
View File

@@ -88,4 +88,4 @@ I want to pull data from ModuleStore or Block Structures.
Making any synchronous calls to these systems will break the performance goals
of this app. If you need data from these systems, please find a way to push that
data into smaller mdoels at course publish time.
data into smaller models at course publish time.

50
openedx/core/djangoapps/content/learning_sequences/docs/decisions/0001-extensions-to-inter-app-apis.rst
View File

@@ -31,35 +31,37 @@ to the existing set of Inter-app APIs defined at the top level of edx-platform.
Decision
--------
#. All API data structures will be declared as immutable attrs classes in a
separate ``data.py`` file. All data class attributes will have type annotations.
#. Data structures in ``data.py`` will include basic validation of their inputs,
though this will *not* include validation that requires database access.
#. All public inter-app API functions will use type annotations for arguments
and return values.
#. All public inter-app API functions will be exported in the top level ``api``
package. Other applications will only ever import from this top level package.
#. Views, tasks, and any other parts of the learning_sequences app that are not
in the api package will obey the same rules that external apps would follow.
This means that views for learning_sequences will only import from api and will
not directly import from models.
#. Serializers for REST APIs will be defined as inner classes on the views.
Serializer re-use across use cases will be explicitly discouraged to prevent
modifications from rippling across and breaking compatibility elsewhere.
#. Wherever possible, API-level tests will be written without mocking internals,
or prepping the database with model manipulations. The goal of this is to make
it so that that API-level tests *only* break when there are in fact API changes.
We can mock calls to other services, like grades.
1. All API data structures will be declared as immutable attrs classes in a
separate ``data.py`` file. All data class attributes will have type
annotations.
2. Data structures in ``data.py`` will include basic validation of their inputs,
though this will *not* include validation that requires database access.
3. All public inter-app API functions will use type annotations for arguments
and return values.
4. All public inter-app API functions will be exported in the top level ``api``
package. Other applications will only ever import from this top level
package.
5. Views, tasks, and any other parts of the learning_sequences app that are not
in the api package will obey the same rules that external apps would follow.
This means that views for learning_sequences will only import from api and
will not directly import from models.
6. Serializers for REST APIs will be defined as inner classes on the views.
Serializer re-use across use cases will be explicitly discouraged to prevent
modifications from rippling across and breaking compatibility elsewhere.
7. Wherever possible, API-level tests will be written without mocking internals,
or prepping the database with model manipulations. The goal of this is to
make it so that that API-level tests *only* break when there are in fact API
changes. We can mock calls to other services, like grades.
Consequences
------------
#. It will be easier for other applications to access learning_sequence
functionality in a more easily understood and maintainable way.
#. It will be easier to build and maintain plugin code that depends on this
application.
#. Changes that break backwards compatibility will be more obvious.
1. It will be easier for other applications to access learning_sequence
functionality in a more easily understood and maintainable way.
2. It will be easier to build and maintain plugin code that depends on this
application.
3. Changes that break backwards compatibility will be more obvious.
References