Sunbird Portal :: Resource Bundle Externalisation

Introduction

1 Introduction
2 Background
3 Problem Statement
4 Design
- 4.1 Solution 1
  - 4.1.1 Scenario 1
    - 4.1.1.1 Configuration
    - 4.1.1.2 Folder Structure
- 4.2 Solution 2
5 References
6 Links

Background

Currently, Sunbird has a high degree of interdependence with assets (platform specific) and language translation JSONs¹ which are being served through filesystem. This tightly coupled modules approach make it difficult for

Understanding the system / module
Difficulty in maintaining the system
- Changes in a tightly coupled module can have ripple effects throughout the system, making it mandatory for deployment of application
Difficulty in modifying the system
Difficulty in reusing the system
- Tightly coupled modules can make it difficult to reuse the system, as modules are tightly bound to other modules / process
Difficulty in scaling the system
- Tightly coupled modules can make it difficult to scale the system, as the dependencies between modules can limit the ability to add new functionality or distribute the system across multiple adopters

Problem Statement

As a adopter of Sunbird;

System must be capable and independent using of serving assets and JSONs¹
Configurable BLOB storage² using Client Cloud Services
- For additional configuration and key mapping please refer to https://github.com/Sunbird-Ed/client-cloud-services

Design

Solution 1

This approach will
- Take configuration in the form of JSON object
- Based on the jobs specified in configuration, jobs will be loaded with appropriate and required config params
- Once the loader is completed with onboarding configuration, all the jobs are executed by executor
- Uploading to BLOB will be based on configuration across multiple providers
- Allows to extend / add custom jobs, so that additional automation are handled automatically based on configuration
Impact
- Code reuse:
  - By externalising a module, adopters can easily reuse the functionality in their projects, saving time and effort
- Maintenance:
  - Externalising a module can make it easier to maintain the code, as it can be updated and tested independently of the main project
- Modularity:
  - Externalising a module can improve the overall design of the project by making it more modular, which can make it easier to understand, test, and maintain
- Collaboration:
  - Externalising a module allows developers (adopters) to collaborate more easily, as they can work on different parts of the codebase simultaneously without interfering with one another

Scenario 1

Configuration

[
  {
    "tenant": "Tenant 1",
    "container": "tenant_1",
    "jobs": [
      {
        "name": "resourceBundles",
        "isEnabled": true,
        "cloudServiceProvider": "azure",
        "folders": [
          {
            "name": "consumption",
            "path": "/resourcebundles/data/consumption/",
            "dest": "/resourcebundles/json/",
            "blobName": "label",
            "uploadPath": "tenant_1/labels/consumption"
          },
          {
            "name": "creation',",
            "path": "/resourcebundles/data/creation/",
            "dest": "/resourcebundles/json/",
            "blobName": "label",
            "uploadPath": "tenant_1/labels/creation"
          }
        ]
      },
      {
        "name": "assets",
        "isEnabled": true,
        "cloudServiceProvider": "aws",
        "folders": [
          {
            "name": "logos",
            "path": "/logos",
            "blobName": "images",
            "uploadPath": "tenant_1/images"
          }
        ]
      }
    ]
  },
  {
    "tenant": "Tenant 2",
    "container": "tenant_2",
    "jobs": [
      {
        "name": "resourceBundles",
        "isEnabled": true,
        "cloudServiceProvider": "azure",
        "folders": [
          {
            "name": "consumption",
            "path": "/resourcebundles/data/consumption/",
            "dest": "/resourcebundles/json/",
            "blobName": "label",
            "uploadPath": "tenant_2/labels/consumption"
          },
          {
            "name": "creation',",
            "path": "/resourcebundles/data/creation/",
            "dest": "/resourcebundles/json/",
            "blobName": "label",
            "uploadPath": "tenant_2/labels/creation"
          }
        ]
      },
      {
        "name": "assets",
        "isEnabled": true,
        "cloudServiceProvider": "aws",
        "folders": [
          {
            "name": "logos",
            "path": "/logos",
            "blobName": "images",
            "uploadPath": "tenant_2/images"
          }
        ]
      }
    ]
  }
]

Folder Structure

.
├── ekstep
│   ├── assets
│   │   ├── contact.png
│   │   └── logo.png
│   └── resource-bundles
│       ├── data
│       │   ├── consumption
│       │   │   └── en.properties
│       │   └── creation
│       │       └── en.properties
│       └── json
├── jobs
│   ├── asset-parser
│   ├── blob-uploader
│   └── resource-bundle-parser
── sunbird
│   ├── assets
│   │   ├── contact.png
│   │   └── logo.png
│   └── resource-bundles
│       ├── data
│       │   ├── consumption
│       │   │   └── en.properties
│       │   └── creation
│       │       └── en.properties
│       └── json
├── .env
└── configuration.json

Solution 2

This approach will
- Requires manual intervention and processing of all the properties files to JSON conversion
- Uploading directly to BLOB storage requires special access
- Maintaining assets is overhead
- Managing multiple BLOBs required special attention and care

References

¹ Resource bundles properties and JSON files

² BLOB storage provider

Links

Sunbird Portal :: CSP implementation