Web Services & Javascript

Introduction and Motivation

We're thinking of reworking the genome browser so that Javascript is responsible for the layout of the page at a high level rather than the C scripts on the server. As part of this we'll be moving the C scripts to more of a web-services oriented architecture, where they'll be returning information in JSON rather than in HTML and GIF images. For the near term at least they probably will return GIF images as well. The goal of this rearchitecting is to make it easier to be more interactive, and to take advantage of the good Javascript user-interface (UI) oriented libraries like jQuery.

As is often the case with software development, the demon is in the details. Nonetheless it is helpful to have a clear, simple high level design to start with - to keep at least the messy details in one location of the code from breeding and exponentially multiplying with messy details in other locations....

Architectural Overview

The overall architecture is based on the flow of data through server side scripts in C at genome.ucsc.edu into Javascript-controlled web pages. The major objects in the system include (some of which have expressions both in the C and the Javascript side) include "user," "dataSource," "genomeAssembly," "track," "item," and "relationship." The user object handles passwords and other security, and the user interface settings. A dataSource represents a place that the system queries for live data. It may include a file or data base on the server, a remote SQL database or file set, a web site that the C scripts know how to query via a web-services interface of some sort, or the user's custom tracks. A genomeAssembly includes a particular genome assembly and a NCBI taxon number. A track is conceptually just a table that _may_ include genome position fields that are hooked to a genome assembly. Tracks may be implemented in a variety of ways, not necessarily as SQL tables. An item is conceptually a row in a track table. A relationship links together fields in the track/table rows.

Server Side in C

Page Setup Query

To minimize the round trips between the web server and the jQuery client, the initial query to the server returns quite a bit of information, which can be broken into two main parts:

Queries to Fetch Data for Genomic Regions

"Browser" query

Map box

List of items in non-dense tracks with just enough info to generate the map-boxes.

Client Side in Javascript

Initialization

The starting point of the Javascript will be the canonical jQuery <script>$( function() { init-code-goes-here } ) </script> This function will be responsible for converting lists of tools and tracks to a toolbar and the track controls, and also for setting up the layout for the displayed tracks, and initiating the asynchronous queries to fetch the displayed tracks.

Displaying Tracks

Each track will be in it's own div, and the div will be filled in asynchronously.