Building on the success of the design sprint last month, the MoodleNet team has started laying down some milestones for the project. One of the first is to define the system architecture, upon which Mayel de Borniol (Technical Architect) has begun work, with input from Doug Belshaw.
We’ve defined three approaches to building MoodleNet, from a fully-federated architecture through to a centralised SaaS architecture:
(Note: right-click on images and select ‘open link in new tab’ to see detail)
Our current preference is for an approach which takes some of the benefits of both, which is a federated architecture with an additional HQ API-as-a-service. The extract below from a overview document we’re putting together, with terms in bold defined in the glossary at the end of that document:
In this scenario, Moodle HQ runs a single MoodleNet API-as-a-service serving as a central index of information across the network. This enables consistent discovery and search experiences across all MoodleNet instances (including the one provided by Moodle HQ).
Each federated MoodleNet instance stores the full data of local users, communities, and collections (including personal information, private messages, and public comments/discussions).
The database of the MoodleNet HQ API service contains lists of all public communities, collections, resources, and users across the network, along with a copy of some metadata. A search index also sits behind the API to enable fast and accurate search results. Each item always refers back to the originating MoodleNet instance for the full data (e.g. membership, permissions, comments/discussions).
In practice, this means that the MoodleNet network, while federated, can benefit from the MoodleNet HQ API service for search and discovery. This provides users with a better and more consistent experience, reducing fragmentation and spreading the shared content more widely.
This network can also be based on existing protocols and standards to form a decentralised collection of nodes that send, receive, and store data. The data handling module can be based on an extended ActivityStreams data format and at least some of the APIs on the ActivityPub protocol to ensure compatibility between systems.
We invite comments from the community, after which we will update the overview document and move it to the project wiki. You are welcome to give your feedback here in the comments section or in the discussion forum.