Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Current »

Introduction

Background

Currently, Sunbird has a high degree of interdependence with assets (platform specific) and language translation JSONs1 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;

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"
          }
        ]
      }
    ]
  }
]

Folders

.
├── 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

1 Resource bundles properties and JSON files

2 BLOB storage provider

  • No labels