- Reach LMS Backend — Java | Spring Boot | REST
Reach LMS is an open-source learning management system designed for the developing world. Reach lets organizations offer education and training to anyone—whether they're working from a laptop in a city center or a solar-charged flip phone in a remote village.
This repository contains the source code for the RESTful Java Spring Boot backend application that drives the creation, storage, and access of data that drive this product.
Reach LMS is intended to serve as a general-purpose, open-source Learning Management Systems for various educational circumstances. Our goal is to provide users with an infrastructure wherein they can design curriculum however they see fit and serve that curriculum to any sort of student body. Whether it be an online school for coders across the US or a training program aimed to enable women in rural Africa to trade legally, safely, and profitably... Reach LMS aims to provide the backbone for any organization to create, manage, and distribute educational curricula of every shape and size.
Long-term, we hope to provide users with the following:
- Complete agency over how their content is organized, formatted, and shipped; this would hopefully include large-scale control over the hierarchy of various resources
- Flexible control over groups of users all the way down to granular permissions for what each user specifically can and cannot do to any content in the system
- Support for Assignments, Grades, and Graduation Lifecycles
- Support for User Management Lifecycles from user on-boarding to editing user's roles or outright blocking user access
- Incredibly fast response times of all media from the Database to the End-User, whether that user is on a desktop or solar-charged mobile phone.
This product has spent the last two months building up, breaking down, and refining an incredible foundation for future developers to build upon.
The last two months have focused on developing a powerful foundation for the following broad-strokes features:
- Building a base-level hierarchy for educational content
- User Authentication: Sign-Up, Log-In, Deletion, Profile-Updates; integration with Okta
- Designing role-based interaction with educational content that grants various operations and resources to users based on their role. This includes the creation, editing, deleting, or viewing of any content in the curriculum hierarchy.
- Coherent and flexible relationships between any users and any entities in the curriculum hierarchy.
We have designed the following hierarchy to define what educational curriculum should look like to start out:
Programs should contain the following fields:
programname— The name of the programprogramtype— K-12, Higher Education, Training, etc.programdescription— A description of this program's focus; what does it teach?, who is it for?, etc.user— An ADMIN who claims "ownership" over this program.courses— A collection of courses that belong to this programtags— A collection of ADMIN-defined tags that represent the possible sub-categories for courses in this program.
Courses should contain the following fields:
coursename— The name of the coursecoursecode— A natural identifier — a unique text field that allows creators to control how a course is identifiedcoursedescription— A description of this course—what does it teach? who does it teach?program— The program to which this course belongsusers— A collection of users "enrolled" in this course. This set will include both TEACHER and STUDENT users- TEACHER and STUDENT users are differentiated by their role, not a separate join table
modules— A collection of modules that belong to this coursetag— A tag selected from the list defined of available tags set by the ADMIN when creating the Program to which this course belongs.
Each Module should contain the following fields:
modulename— The name of the modulemoduledescription— A description that gives an overview of what this module focuses onmodulecontent— Markdown content that contains all the learning content in this modulecourse— The course to which this module belongs
The first step towards user-defined hierarchies... an ADMIN has the ability to define a group of Tags for a program.
Each Tag will have a simple title and hexCode to represent the name of this tag and the associated color.
For example, if I were to go create a program called "Web Development," I might opt to keep my number of tags slimmer:
- Frontend
- Backend
- Computer Science
Or, maybe I'd prefer to have a BUNCH of different tags, like so:
- Frontend
- Backend
- Computer Science
- React
- State Management
- Java
- Spring Boot
- NodeJS
Either way I prefer it as the admin, I can make all these tags. Then, each course that belongs to this program could specify a tag with which it should be associated.
- Authenticate users with Okta, Spring Security, and JWTs
- Authorize resources dependent on the Roles, Scopes, and/or Okta Groups that the user belongs to
- Send resources through various endpoints
- Attach relational links to resources based on (1.) who requested it and (2.) the resource itself
- Maintain backwards compatibility by thoughtfully evolving the API and supporting fields/operations/endpoints long-term so that clients need not worry about updating code
- Drive application state via hypermedia links
- Keep response data nesting to a minimum to provide faster serialization
- Clearly define relationships between entities through the use of hypermedia links rather than documentation alone or knowledge of this source code
- Organize user privileges and agency based upon their role
This database schema includes the following models:
UserRolesProgramCourseModuleTags
The aforementioned models are organized into the following tables:
USERS- Every user in this system will be either an ADMIN, TEACHER, or STUDENT
ROLES- ADMIN, TEACHER, or STUDENT are the primary role types for this application
PROGRAMS- The parent of the Program > Course > Module curriculum hierarchy
COURSES- The middle child of the Program > Course > Module curriculum hierarchy
MODULES- The smallest child in the Program > Course > Module curriculum hierarchy
TAGS- ADMIN users can create "tags" for any given Program that act as the possible sub-categories for that program
- Each course in that Program will then have the ability to "belong to" one specific Tag that exists in the categories ("ProgramTags") defined for that Program
- Explicit Join Tables:
PROGRAM_TAGS— Joins Many PROGRAMS to Many TAGS in a MANY to ONE to MANY relationship- Though not an explicit table, it's worth noting that Courses have a Many COURSES to One PROGRAM_TAG relationship with this table
USER_COURSES— Joins Many USERS to Many COURSES in a MANY to ONE to MANY relationship- Users in this table belong to the role of TEACHER or STUDENT, as ADMINS are not attached at the course-level.
USER_ROLES— Joins Many ROLES to Many USERS in a MANY to ONE to MANY relationship
All tables will have the columns pictured in the schema above; additionally, each table will contain the following auditing fields:
CREATED_BY- The user that first created itCREATED_DATE— The timestamp for when it was first createdLAST_MODIFIED_BY— The user that last edited itLAST_MODIFIED_DATE— The timestamp for when it was first created