seqr

|

seqr is a web-based tool for rare disease genomics. This repository contains code that underlies the Broad seqr instance and other seqr deployments. To check for any active incidents occurring on the Broad seqr instance, check here

Technical Overview

seqr consists of the following components: - postgres - SQL database used by seqr to store project metadata and user-generated content such as variant notes, etc. - elasticsearch - NoSQL database used to store variant callsets. - redis - in-memory cache used to speed up request handling. - seqr - the main client-server application built using react.js, python and django. - pipeline-runner - optional container for running hail pipelines to annotate and load new datasets into elasticsearch. If seqr is hosted on google cloud (GKE or GCE), Dataproc spark clusters can be used instead. - kibana - optional dashboard and visual interface for elasticsearch.

Install

The seqr production instance runs on Google Kubernetes Engine (GKE) and data is loaded using Google Dataproc Spark clusters.

On-prem installs using the elasticsearch backend can be created using docker-compose: Local installs using docker-compose

On-prem installs using the hail backend can be created using helm

To help you decide which backend is best suited for your needs, please refer to the discussion post announcing the hail backend.

To set up seqr for local development, see instructions here

Updating / Migrating an older seqr Instance

For notes on how to update an older instance, see

Update/Migration Instructions

Contributing to seqr

(Note: section inspired by, and some text copied from, GATK)

We welcome all contributions to seqr. Code should be contributed via GitHub pull requests against the main seqr repository.

If you’d like to report a bug but don’t have time to fix it, you can submit a GitHub issue

For larger features, feel free to discuss your ideas or approach in our discussion forum

To contribute code:

• Submit a GitHub pull request against the master branch.

• Break your work into small, single-purpose patches whenever possible. However, do not break apart features to the point that they are not functional (i.e. updates that require changes to both front end and backend code should be submitted as a single change)

• For larger features, add a detailed description to the pull request to explain the changes and your approach

• Make sure that your code passes all our tests and style linting

• Add unit tests for all new python code you've written

We tend to do fairly close readings of pull requests, and you may get a lot of comments.

Thank you for getting involved!