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 On Thursday, March 29, 2018 at 9:23:43 PM UTC-7, Samuel Marks wrote: > > 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 > -- 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.
