Full REST API - rebuilding OpenEdX frontend in JavaScript [&etc]

[Samuel Marks]

Seen some work done on this, but no updates in a while:

https://openedx.atlassian.net/wiki/spaces/OpenDev/pages/18350757/edX+REST+API+Conventions

http://course-catalog-api-guide.readthedocs.io/en/latest/intro_edx_apis.html

https://edxapi.docs.apiary.io/#reference/xblocks/read

Been using Angular's variants since an early beta of AngularJS. It's great, because you're decoupled from the backend, so it enables both codebases to evolve independently (with different teams and a shared interface).

Also you can chuck the static files on a CDN, and do things asynchronously, which makes it a significantly faster experience for the end-users.

Because there's a huge amount of work put into OpenEdX already, I'm not expecting this to be a short project. But we should at least be able to put a modular scaffold in place for people to slowly extend over time.

CRUD APIs needed:

• authentication;
• course
• list courses
• enrolment
  
• CRUD content
• certificate generation
  
• &etc.
  
• JavaScript-only XBlocks
• gotta figure out how we'd rebuild minified code here, probably needs linkage with CI/CD servers
• e-commerce APIs
• analytics
• grading
• regression
• &etc.
  

As for implementation details for the frontend, I would personally use TypeScript with the latest Angular (and @angular/material). Would refactor all the interfaces to have clean HTML5 routes.

First version could be just simply: auth; list course; view course; view plain text; interactive multi-choice quiz. I think that would make a good alpha release, then everyone can jump in and extend from that scaffold?

How does that sound?

[or is there no interest in this kind of thing anymore?]

Samuel Marks
http://linkedin.com/in/samuelmarks

[Clinton Blackburn]

edX has mostly adopted React+Redux for frontend development (http://open-edx-proposals.readthedocs.io/en/latest/oep-0011-bp-FED-technology.html). I like the simplicity of React, but not the complexity of Redux.

I did some work on a marketing site prototype for server-side rendering to static pages (with Wagtail) and running serverless (with Node.js). See https://github.com/edx/marketing-site/branches. edX.org (powered by Drupal) is/was mostly Backbone with some React. Considering how static much of the content on those pages is, client-side rendering for the whole page seems like overkill compared to rendering to static pages and injecting JS components where needed.

I digress...the marketing site can be built today with the endpoints in the Catalog Service. See https://prod-edx-discovery.edx.org/api-docs/ and https://github.com/edx/course-discovery/. The E-Commerce Service has an API; however, we ultimately stopped using it in favor of simply redirecting users with a URL containing the products to add to the basket. I don't think the Analytics API is exposed publicly. There is an endpoint for OAuth access token generation; it supports bearer tokens and JWTs.

I vaguely recall some work taking place to make parts of LMS use client-side rendering.

Clinton

[Ned Batchelder]

There is definitely interest in building out the APIs, both to support front-end development in a more modern way, and for other kinds of extension.  Our thoughts are more toward GraphQL than REST, because of the flexibility and power it puts in the caller's hands.  But that is all still in the eye-twinkle stage than anything else.

--Ned.

--
You received this message because you are subscribed to the Google Groups "General Open edX discussion" group.

To view this discussion on the web visit https://groups.google.com/d/msgid/edx-code/4dbdc92a-38fb-4b77-80c9-a4df4f851dce%40googlegroups.com.