Discovery: Backend vs. Frontend (clipboard app on backend or do everything client-side)

[ormsbee]

Create an Arch Decision Record (ADR) for the high level approach we're taking. See tech approach notes for some context and discussion of tradeoffs.

This will likely be influenced by wireframes output and the kinds of validation/display work we need to do.

[bradenmacdonald]

@ormsbee

We have the final UX design: https://www.figma.com/file/y2qfzidTxxfYK8ONgyT7KP/Modular-Learning-Wireframes?node-id=823%3A778&t=TEJeqjOoWnxaYltO-1

I am thinking now that a backend app makes more sense:

• we need to copy OLX plus all the references to static assets. For sections/subsections this may be slow. If we are doing it on the server side, we can queue the task and immediately return a clipboard ID to the user, so that the actual copying can be done asynchronously / optimistically. (Though for MVP we'll probably do it synchronously.) Most likely, we can finish the copy in the time the user takes to find the place they want to paste and hits the paste button. This will feel way more responsive to users than if there is a delay while the copying happens. (Though this is a bit of a UX question, and surfacing errors during an optimistic async copy process is hard in the absence of a notifications system in Studio. May need to discuss this with @ali-hugo once we get to larger pieces of content.)
• validation is much easier on the backend
• less bandwidth is used for the copy-paste cycle if all data is stored on the server side
• if we go client-side, there may be cross-platform/cross-browser nuances in how large or complex data gets stored in the actual local clipboard or localStorage or whatever API is in use.

What are your thoughts? And would this belong in learning core or integrate with it?

[ormsbee]

Agree with backend for the reasons you listed. Other thoughts:

Separating Clipboard and Content Preparation

I'd like to see if we can build two complementary concepts–a clipboard interface that matches closely to how copy-paste is used, as well as a more general concept of a staging space to prepare content–with the notion that it could eventually expand to include things like partial-import.

So it might look like this (though I'm not attached to any naming):

# Copy something to the clipboard by sending a UsageKey
POST /api/content_prep/v1/clipboard

# Get an individual's clipboard
GET /api/content_prep/v1/clipboard/{username}

But the act of copying actually creates a new type of resource that's referenced from clipboard:

# Description of the content (metadata, links to files, etc.)
GET /api/content_prep/v1/staged_content/{staged-content-uuid}

# Same as above, but see it modified for the particular context it would be pasted into
# (so UsageKeys would be modified, certain values might be stripped, files renamed, etc.)
GET /api/content_prep/v1/staged_content/{staged-content-uuid}?destination={learning_context}

We can then do a POST that says to insert this staged content into a particular place in another learning context, and re-use that part of the logic whether things are coming in via clipboard, templates, partial import, or something else.

Learning Core: XBlock Separation, Normalization, and Ephemeral Content

I'm conflicted on where this should live. Just a brain dump of those thoughts:

• I do think some version of this would work well in core, but it doesn't have to be there (at least not immediately).
• We have some flexibility in that clipboard data isn't assumed to live forever, and we can probably wipe things up in an upgrade early on in the process without causing too much pain.
• I don't want to hobble the development effort by making a dependency on Learning Core too early.
• But this is a great opportunity to try out some of these concepts on a smaller scale.
• I've been trying to keep UsageKeys out of Learning Core because I really do think we want to have QTI and other formats down the line, but I don't know how cleanly that line can be drawn here.

It's also interesting how this might fold into the Learning Core data model that's evolving. One of the big departures is that clipboard content is ephemeral. We really don't want to keep it around. But there are other interesting ways we can slice things. For instance, we can make it so that each "Staged Content" entity is in fact a LearningPackage that just has a very short life-span. That allows an arbitrary amount of content to be loaded into it, possibly over a long period of time, and provides the ability to do cascade-style cleanups afterward by deleting the entire LearningPackage.

I'm currently leaning to doing it in edx-platform in the simplest way possible for the component and unit milesones, but refactor and shift parts of it to Learning Core as part of the work we'll likely end up tackling to make this feature work for subsections and sections.

[bradenmacdonald]

Alright, backend it is.

a more general concept of a staging space to prepare content–with the notion that it could eventually expand to include things like partial-import.

This is an appealing idea but I still feel a bit reluctant to build it now if we don't have well-defined use cases for it other than this.

I'm currently leaning to doing it in edx-platform in the simplest way possible for the component and unit milesones, but refactor and shift parts of it to Learning Core as part of the work we'll likely end up tackling to make this feature work for subsections and sections.

Sounds good to me.