# Brainstorm on application
**Date:** 29/09/2021
## Technology options
* [Blazor](https://blazor.net):
* WebAssembly
* Web-based
* Back-end and front-end in C#
* Fast App development
* Heavy initial loading time but otherwise fast
* [Publish to NPM?](https://github.com/dotnet/aspnetcore/issues/16031)
* [React.js](https://reactjs.org/)
* Popular for SPAs
* Lot's of integrations
* Trivial to abstract parts as NPM packages; JS already
* [Elm](https://elm-lang.org/)
* Language compiles to JS
* SPA framework included
* Trivial to abstract parts as NPM packages: publish compiled JS (from `prepublish` script)
* [Fable](https://fable.io/) + [Elmish](https://elmish.github.io/elmish/)
* .NET/F#
* Compiles to JS
* Can publish packages to NPM??
* [JavaFX](https://wiki.openjdk.java.net/display/OpenJFX/Main)
* [Qt](https://www.qt.io/)

## Datastructures
### Level 0 fragments
* Unique identifier => MP-G-, MP-X-, ...
* Name
* Sequence
* Length
* BSAI overhang:
* AB: Promotor
* BC: Kozak-ATG (+ N-terminal tags)
* CD: Gene Of Interest
* DE: Linkers
* EF: Fusion partner + STOP
* FG: Termination signal (or post-transcr. reg. sequences)

## Database structure

### Table 'destinationVectors'
* bb_ID **INT PRIMARY KEY AUTO_INCREMENT**
* MP-GB-number (suggestion: 'number'-part is the ID. Otherwise user can choose but it has the '**UNIQUE**' constraint)
* Name **VARCHAR NOT NULL**
* level **ENUM(0, 1, 2)**

### Table 'level0'
* lvl0_ID **INT PRIMARY KEY AUTO_INCREMENT**
* MP-G0-number (suggestion: 'number'-part is the ID. Otherwise user can choose but it has the '**UNIQUE**' constraint)
* Name **VARCHAR NOT NULL**
* Owner **VARCHAR NOT NULL**
* Sequence **TEXT NOT NULL**
* BSAIOverhangID: **FOREIGN KEY(BSAIOverhangID) REFERENCES BSAIOverhangs(BSAIOverhangID)**
* Remarks: **TEXT**
* Annotations **TEXT** => Seperate table?

**Should these be included?**
* Length: If we have the sequence, we know the length as well...
* Primer Type
* Restriction Site
* qPCR
* Ordered

>Everything should be accessible from database.
>Sequences are kept in clc-files
>

### Table 'BSAIOverhangs'
* BSAIOverhangID **INT PRIMARY KEY AUTO_INCREMENT**
* BSAIOverhangsName **VARCHAR NOT NULL**
* OverhangID: **FOREIGN KEY(OverhangID) REFERENCES overhangs(OverhangID)**

### Table 'overhangs'
* OverhangID **INT PRIMARY KEY AUTO_INCREMENT**
* OverhangType **NCHAR(2) NOT NULL UNIQUE**
* Nucleotides **NCHAR(4) NOT NULL UNIQUE**

### Table 'level1'
* lvl1_ID **INT PRIMARY KEY AUTO_INCREMENT**
* MP-G1-number (suggestion: 'number'-part is the ID. Otherwise user can choose but it has the '**UNIQUE**' constraint)
* Name **VARCHAR NOT NULL**
* Sequence **VARCHAR NOT NULL**
* Content (!suggestion!: **BLOB NOT NULL**)
* The BLOB would hold an XML or a Json structure of the level1 which could be easily parsed into an object.
* This is a flexibel way for storing and manipulating all information of the level0 elements in a level1.

### Table 'level 2'
* **!Not relevant at this point!**
* lvl2_ID **INT PRIMARY KEY AUTO_INCREMENT**
* MP-G2-number (suggestion: 'number'-part is the ID. Otherwise user can choose but it has the '**UNIQUE**' constraint)
* Name **VARCHAR NOT NULL**
* Sequence **VARCHAR NOT NULL**
* Content (!suggestion!: **BLOB NOT NULL**)

## UI design
### Level 1 constructs or transcript units:
Designed with wireframe.cc:

> James's idea: Better to implement a drag-n-drop system in stead of comboboxes?

### Level 2 Constructs
* **!Not relevant at this point!**

# The current cloning design process at group Eyckerman
## The step-by-step process in CLC
1. Making **Level 0** contructs:
* The predonor fragment of interest is modified by adding a BSAI recognition site along with the desired overhangs. This is obtained through PCR.
* predonor fragments are added together with a destination vector containing a CCDB region (= Kills bacteria). During the cloning process, the CCDB-fragment is swapped for the predonor fragment and transferred to bacteria as expression system.
* If the CCDB region hasn't been swapped for the predonor fragment, no bacterial growth would be observed. If colonies are observed, they contain the level 0 elements.
* In CLC each level 0 is designed seperately and manually:
* Adding annotation to the different parts:
* Gene of interest
* primers for modification of overhangs
* BSAI sites
2. Making a level 1
*

4. Making a level 2

## Extra questions for Delphine (group Eyckerman)
* Are there any restrictions on the choice of destination vectors? Should we check for some sort of compatibility?

>There is a difference in the backbones per level! Backbone for level 1 isn't used for level 2...
>Furthermore: some backbones are only used for some applications. Delphine will ask Sven if it would be useful to let the app guide the user to make the right choice.
>
>**Conclusion:** Backbones should be stored in a seperate table!

* Are there other restrictions between combinations that are theoretically possible but should be banned anyway? In other words: Can we make all combinations possible solely based on overhang compatibility? Or should there be some extra logic integrated?

>Delphine will ask Sven
>

* What is the exact nomeclature regarding the MP-G-, MP-I-, MP-X- identifiers?

>Only MP-GX- is relevant for the application:
>* MP-GP-X: Predonor fragments. Used to construct level 0 constructs
>* MP-G0-X: Level 0 constructs
>* MP-G1-X: Level 1 constructs
>* MP-G2-X: Level 2 constructs

* What is the actual input? Is it the circular construct? Or is it only the fragment of interest which has to go into the destination vector (so without the backbone of the level 0)?

>The input is the circular level 0 as a whole. So we need to perform a BSAI-cut in silico before any string concatination! The circular constructs are designed only have two BSAI-sites so we don't have to worry about other "incidental" occurences of these recognition sites.

# Other Remarks after call with Delphine
* Creating level 0 elements takes more time than making the level 1 constructs.
* Would be great if the application would at some point in the future check the open reading frame

# Second call with Delphine: Sven's idea of the tool step by step for a level 1:
1. Choose whether you want a level 1 or 2.
2. The user should be guided towards the right backbone, so according to the downstream experiment (transfection, piggy back,... ).
3. The user should choose between two options:
* Classic GGW with 6 elements
* Custom GGW with n elements
4. The user should search a catalog of possible elements and filtering out the element which are not allowed on some text the user provides as input!