mooclet policy schema table and endpoint

[danoswaltCL]

In the name of keeping the UI dumb and not needing to create data/validation objects on both ends that need to be kept in sync, we should send over all of those details on app startup when moocletToggle is true. This will require:

1. Create an enum for supported mooclet policy names. (this may already be done in other PR)
2. Create a "supported_mooclet_policy" table that will contain a policy name and schema object per row.
3. Create an endpoint to select and send all data from the table as GET /supportedMoocletPolicySchema for UI.

When we are ready to declare support of new mooclet policies, this table will be the source of truth, we will add the policy as an enum and as a row w/ policy parameters schema. I'm not sure of the best way of making sure this info is in database, I don't feel like we need to support CRUD endpoints for this stuff....

• Create an enum for SUPPORTED_MOOCLET_POLICY_NAMES that we will be a list of exact mooclet policy names that we will officially support. These should match what will be in the table, which is mentioned next.

export enum SUPPORTED_MOOCLET_POLICY_NAMES {
    TS_CONFIGURABLE = 'ts_configurable',
    SOMETHING_ELSE = 'something_else'
}

• Create a table called supported_mooclet_policy_schema" that will contain a column for POLICY_NAME` as primary key and a second column that contains a JSON schema.

import { Entity, PrimaryColumn, Column } from 'typeorm';
import { SUPPORTED_MOOCLET_POLICY_NAMES } from './enums';

@Entity('supported_mooclet_policy_schema')
export class SupportedMoocletPolicySchema {
  @PrimaryColumn({
    type: 'enum',
    enum: SUPPORTED_MOOCLET_POLICY_NAMES,
    enumName: 'SUPPORTED_MOOCLET_POLICY_NAMES',
  })
  policy_name: SUPPORTED_MOOCLET_POLICY_NAMES;

  @Column({ type: 'json', nullable: false })
  policy_parameters_schema: Record<string, any>;
}

For instance, a mooclet "policy_parameters_schema" object could contain something succinct like this that gives the policy parameters shape, type constraints, and default values together :

const policyValidator = {
   policy_name: "ts_configurable"
   policy_parameter_schema: {
      "prior": {
        "success": [ 'number', 1 ], // user must enter a number for prior.success, it will default to 1, etc...
        "failure": [ 'number', 1 ]
      },
      "posteriors": { 'object', undefined },
      "batch_size": [ 'number', 1 ],
      "max_rating": [ 'number', 1 ],
      "min_rating": [ 'number', 0 ],
      "uniform_threshold": [ 'number', 0 ],
      "tspostdiff_thresh": [ 'number', 0 ],
      "outcome_variable_name": "[ 'string', '' ]"
    },
 },

We should create an endpoint for the UI to fetch all data in this table and store it so that in Frontend we have all the policy names we need for the dropdown selection in the experiment stepper step (1), and a validator object that can be used in step (2) to display a default policy params object in the json editor and be able to offer validation before submission.

[danoswaltCL]

another benefit of having a table for mooclet policy metadata in the database is that it won't require any code or configuration updates in order to add/remove/update those supported policy choices.

[danoswaltCL]

It would be really nice to be able to add/modify mooclet policies without coordinating a code deployment / release, even if it's infrequent, that's my main reason for thinking it would be a good idea of keeping these things in the db.

That being said, it is a great deal simpler to put this data in the types folder and use it the same way. That would be more complex to update, but easier to implement.

I spent the afternoon trying out both ways, have found a library to use for validating an object that might be much easier than rolling our own validation code, which can be used on both ends: ajv.

I think we can close and I will put the schema into the types in the open PR that I already have.