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
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.
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
For notes on how to update an older instance, see
(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!