reusable_frontend_design_notes

Problem analysis

We want to structurize frontend in order to increase its scalability and extensibility, as bunch of different formats will have to be supported and handled.

Dimensions that require special attention:

• different types of visualization
• different types of algorithms

Visualizations

Creation of npm package has been proposed. It would consist of several components responsible for different kinds of visualization.

Proposed solution for now:

Let's create separate directory in the Angular client, for the sake of reusable components based on Plotly or Material.

Eventually, when the number of components rises, extract it to separate repository.

======= Place result of separate repository solution investigation here ========

How to build and publish Angular module - written by a guy struggling to do it himself How to create library in Angular 2 and pushlish it to npm from scratch - possibly more detailed but harder to follow Verdaccio - a tool for private npm registers

Algorithms

There are 2 problems right now:

• connecting to different endpoints of REST API
• placement of algorithm-related components in Preparation view

Sample cases

Heatmaps

We have several techniques of heatmap normalization. We want to select an algorithm, parameterize it and display result - a scaled heatmap. Different parameters exist for different heatmaps.

ROI Approximation

We have several algorithms for ROI approximation. They will produce different ROIs, based on a reference ROI. Each of them has some parameterization. It would be good to see results of approximation for each different parameters set.

DiviK

There is one algorithm, but has multiple parameters. We want to set them all, run the algorithm and see the results when available.

Analysis of the cases

Algorithm scheduling

1. We can have a list of algorithms provided by the server, or hardcoded. We support only implemented algorithm, the rest is grayed out or something.
2. Visualization + spectrum should be visible for each preparation as it is primary representation of the data.
3. All of the algorithms / algorithms groups are enveloped into a single component (algorithm component), that exhibits specialized components to gather the data and sends it to API.
4. Algorithm component will be adapted by a component common for the group of algorithms, responsible for providing each of its variations. It will be called specialization component.
5. Based on the selection made in the specialization component, we create (through a factory) a new component dedicated for parameterization of the specific algorithm - this will be called parameterization component. Parameterization component will have backend of single interface, that will be further directly passed to the REST API.
6. Parameterization component is not required for each of the single algorithms, it is necessary for algorithms groups.

General Algorithm Exposure - Design Example

(===================DIVIK 1======================)

(===================DIVIK 2======================)

(===================DIVIK 3======================)

(===================DIVIK 4======================)
(                                                )
(  +=========+            +============+         )
(  | Regions |            | Parameters |         )
(  |   map   |            +============+         )
(  +=========+                                   )
(                         +============+         )
(                         |  Detailed  |         )
(                         | summaries  |         )
(                         +============+         )
(================================================)

(===================DIVIK 5======================)

(===================DIVIK 6======================)

(=================NEW ANALYSIS===================)
(  HERE WILL BE THE ABOVE PART RESPONSIBLE FOR   )
(                CONFIGURATION OF NEW RUN        )
(                                                )
(     OPENS WHEN CLICKED ON "NEW ANALYSIS"       )
(================================================)

Component

1. We need generic component that lists all the known runs of any algorithm
2. Each run will be expanded on click / whatever.
3. On clicking NEW ANALYSIS (or similar), there expands the component defined above for run parameters specification.
4. Analysis in progress is listed and active. After expansion we have parameters shown. The bar should be in different color. We should display short information, that analysis is in progress indeed.
5. Provide a color code for analyses: a) analysis done - green b) analysis in progress - blue c) analysis failed - red d) analysis scheduled - TBA e) new analysis - gray
6. On bars we may provide name of the analysis instead.
7. For analysis we need: a) name b) kind of ID c) specialization
8. On clicking the component related to an analysis, a component dedicated for its specialization is created through a factory.
9. Opened algorithms must be linkable - there should be possibility to create a link that points to a specific analysis.

Organization in the repository

- src
|- app
   |- algorithms
      |- shared (reusable parts generic for each algorithm / analysis)
      |  |- analysis-types-service (for fetching available analysis types)
      |  |- analysis-list-service (for fetching list of analyses of given type)
      |  |- analysis-service (for fetching data on single analysis)
      |  |- list-of-analyzes (for listing analyzes of specific type)
      |  \- algorithm-component (for generic scheduling - look above)
      |
      |- divik (algorithm without specialization)
      |  |- parameterization (for specification of parameters)
      |  \- visualization (for visualization fo results)
      |
      \- roi-approximation (algorithm with specializations)
         |- specialization (for specialization of approximation algorithm type)
         |- factory (for creating different specializations)
         |- visualization
         \- parameterization
            |- exroi
            \- greedy

Requirements for Backend

List all available analyses for preparation:

GET rest/preparation/$id$/analyses

should return

200 [
    "analysis type 1",
    "analysis type 2",
    ... // further analysis types
]

List all analyses of specific type (e.g. $analysis_type$ == 'DiviK'):

GET rest/preparation/$id$/analyses/$analysis_type$

should return

200 [
    {
        "name": "custom analysis name",
        "id": "unique analysis id",
        "status": "scheduled / in progress / done / failed"
    },
    ... // further analyses
]

Schedule new analysis of specified type, with some parameters:

POST rest/preparation/$id$/analyses/$analysis_type$

payload:

{
    "name": "friendly name",
    ... //algorithm-dedicated payload
}

should return

202

Get result of an analysis run:

GET rest/preparation/$id$/analyses/$analysis_type$/$analysis_id$

should return

200 { // if status == done
    ... // algorithm-dedicated payload (parameters)
}

404 // if nonexistent

204 // if in progress or scheduled

410 // if failed

Summary

Following is to be done:

1. Backend - adapt the REST API to the requirements
2. Visualizations (Roman): a) create separate directory just for different kinds of data presentation b) move heatmap component c) move spectrum component d) create boxplot component e) extract short summary component - this means the table with parameter names in first column and values in another f) create detailed summary table - this means table with title row and mostly numeric or repeatable content g) extract above components to separate repository and create npm package h) TBA
3. Algorithms (Sebastian): a) list of algorithms to switch to b) list of analyses for given algorithm c) summary of DiviK embedded into list of analyses d) parameterization component for DiviK analyses scheduling e) TBA
4. Move from DEPRECATED Http to HttpClient (Roman)

To Consider

1. Long polling - allows for tracking changes @ REST API.