Page Comparison

...

1. Create a new XBlock in its own Git repository
   • XBlocks allows you to define new types of components that can be used in courseware, e.g. new problem types
   • For edX to consume your XBlock, it should just be added as a requirement to: https://github.com/edx/edx-platform/blob/master/requirements/edx/github.in
   • Consider the following before choosing to create an XBlock:
     • Testing of authoring views is challenging as there is no straightforward way to run with the block embedded in Studio
     • There are aspects of XBlock integration into Studio that have not been completed, e.g.

       • Jira Legacy
         server JIRA (openedx.atlassian.net) serverId 13fd1930-5608-3aac-a5dd-21b934d3a4b4 key TNL-851

       • Jira Legacy
         server JIRA (openedx.atlassian.net) serverId 13fd1930-5608-3aac-a5dd-21b934d3a4b4 key TNL-850

   • Examples of XBlocks:
     • Recommender XBlock: https://github.com/pmitros/RecommenderXBlock
     • Staff Graded Assignment XBlock: https://github.com/mitodl/edx-sga
     • XBlock Poll: https://github.com/open-craft/xblock-poll
   • See the documentation below: Create a new XBlock in its own Git repository
2. Create a new IDA (independently deployable application)
   • If a feature doesn't need to be tightly integrated into Studio or the LMS then it can be built as an independent app
   • It can make use of the Open edX ReST APIs to get any platform data that it requires
   • IDAs are a good choice when:
     • They need to scale independently of the edX platform
     • They will be built, deployed and managed by a separate team
     • LMS and Studio should continue unaffected even if the application goes down
   • Consider the following before choosing to make a new IDA:
     • There is more operational complexity for the community to deploy and manage your feature
     • There are performance implications with introducing extra network calls
     • There is more application complexity when working with related data from external APIs, e.g. joins and referential integrity must be implemented in the application layer
   • Examples of IDAs:
     • edX Analytics Dashboard: https://github.com/edx/edx-analytics-dashboard
     • edX eCommerce Service: https://github.com/edx/ecommerce
     • edX Student Notes API: https://github.com/edx/edx-notes-api
   • See the documentation below: Create a new IDA
3. Create a new Django app in its own Git repository
   
   • New Django apps can be implemented in a separate repo and pip installed into the platform
   • A Django app in its own repository is a good choice when:
   1. • it provides new services that will be consumed by other parts of the platform
      • if it requires new UI for LMS or Studio, it provides it via extensions and does not introduce new URLs
        • See Web Fragments OEP-12 for the recommended way to add pluggable user interfaces
   • Consider the following:
     • If the feature has no UI then it may be better suited as an IDA if it doesn't require direct access to platform data models
     • See /wiki/spaces/TNL/pages/40862230 for descriptions of some of the challenges involved with this approach
   • Examples of Django apps in their own repositories:
     • ORA 2: https://github.com/edx/edx-ora2
     • Submissions: https://github.com/edx/edx-submissions
     • Milestones: https://github.com/edx/edx-milestones
   • See the documentation below: Create a new Django app in its own Git repository
4. Add a new Django app to the edX platform
   
   • If your feature cannot be built using the existing extension points, then it can be added directly to the edx-platform
   • Consider the following:
     • It would be better to introduce a platform extension point and then use it from a separate app
     • It is best to build your new Django app in its own directory so that there is an option to move it into its own repo later
       • Our current thinking is to add your new Django app to the directory openedx/features
     • See Web Fragments for the recommended way to add pluggable user interfaces
   • Examples of Django apps in the edX platform:
     • LTI Provider: https://github.com/edx/edx-platform/tree/master/lms/djangoapps/lti_provider
     • Teams: https://github.com/edx/edx-platform/tree/master/lms/djangoapps/teams
   • See the documentation below: Adding a new Django app to edx-platform
5. Update the platform directly
   • This is the option of last resort
   • When should you update the platform directly?
     • When the feature you are implementing updates core functionality in fundamental ways
     • When there are no extension points that you can use to build the functionality you need
   • Consider the following before doing this:
     • Features which update the platform directly require the most scrutiny in code review
     • There is far more risk of unexpected fallout from your changes
     • Consider whether it is possible to introduce a platform extension point and then use it
     • Be sure to discuss your proposed approach with the Open edX community first to ensure that this is the best way to move forward
   • Examples:
     • Cohorted Courseware: PR 6299
     • CCx (custom courses): PR 6636
   • See the documentation below: Update the platform directly

For more background when making this decision, see these architecture council meeting notes: 2015.09.23 - IDA discussion.

...

• Be sure to propose your new IDA to the Architecture and Engineering: Home
• See the architecture council meeting notes on IDAs: 2015.09.23 - IDA discussion
• Create your new project using the cookiecutter: https://github.com/edx/cookiecutter-django-ida
• Consider how the IDA will integrate with the edX platform
  • Ideally these integrations will be implemented as extension points using a Django app in a separate repo
  • Determine how to test all of the integration points

...