Feedback on the diagram, iteration 1:

I find it hard to understand. But I love the detail. I would like to see another iteration.

Suggestions for the next draft:

• Orient all text horizontally or vertically; don't mix orientations

• Use the term "resource" instead of "file". There are no files, only APIs. Web servers hide all the details of how the resources are implemented. A Web server is not a file server even though it can act like one.

• It is not clear what the arrows mean. It seems like maybe this diagram is showing multiple workflows happening independently of each other. If yes, put them on separate pages so that we don't get the steps in one workflow confused with the steps of another. Indicate graphically places where output or events created by one workflow get consumed by another workflow.

• Right now the diagram shows work-performing units as boxes with acronym labels. Add icons or labels to show the name of a recognizable software product, so that people will know which technologies they'll be responsible for knowing. Developers often use the name of a software product as a shortcut to signify the function it performs. You can use this to help them and others get the basic idea. Place a note somewhere to indicate that the software used will vary based on context, e.g., running on a developer's computer versus running on the open internet.

• There appears to be an error with the box labeled "IGB-User adds generated link to Quick-Load links". When a user selects and opens a new genome version, it requests data from the annots.xml endpoints for all Quickload data sources that declare support for that genome version. Each annots.xml endpoint provides XML data consisting of "file" elements corresponding to datasets. Each of these elements contains information regarding the URL location of a dataset resources. These dataset resource URLs can reside anywhere on the internet. Dataset URLs can be either fully qualified URLs or they can be indicated a relative to the base URL of the Quickload site itself. Therefore a Quickload service can provide the fully qualified URL or it can provide a relative URL. I recommend that track hub converter service provide the fully-qualified URL to locations specified by the Track Hub being converted. The diagram as currently drawn doesn't make these interactions very clear.

Regarding implementation:

• I suggest making each task or module in the workflow into a separate App
• REST endpoints can be different Apps

https://app.diagrams.net/#G1kgMJWS5sC_gFOZVLNbWywLoVSvFbeVUf

Track hub system diagram.

Trackhub Diagram updated with No database module.

Track Hub system diagram with no database module.