*** This version of Confluence is for testing only and contains a copy of content from June 29th 2026. No changes will be preserved. ***
-
Created by
user-0432d, last updated by user-aab87 on May 10, 2021
3 minute read
Welcome
Welcome! You must be baffled by the project, not having any clear idea as you just joined. Dread not! We'll walk you through the onboarding.
Hopefully after spending some time reading sections below, you'll have a more clear idea.
By all means, please feel free to to ask on Slack general channel!
Understanding the structure of 2 workflows and 5 teams
The project is divided into 2 workflows: online and offline
The members are divided into 5 teams: frontend-mobile, frontend-web, backend-mobile, backend-dashboard, infra
The table below gives a roughly good idea to understand the relations between 2 workflows and 5 teams
| Workflow | User | Interface (frontend) | API (backend) | database |
|---|---|---|---|---|
| Mobile (Online) | e.g. Parents uploading data/photo | app (iOS, Android) | APIs | Database named "BioHPC" |
| (by frontend-mobile team) | (by backend-mobile team) | |||
| Dashboard (Offline) | e.g. Scientists view data | web (React) | APIs | Should also be on "BioHPC" |
| (by frontend-dashboard team) | (by backend-dashboard team) |
You might notice infra team is missing in the table. Infra team builds up the environments (servers/GitHub/certs/domains/etc) to support other teams.
In one word, infra team underlies all other teams.
Workflows and envs
Now having a rough idea about each team's role, let's understand how their code is interacting with each other (workflows) and 3 envs.
To understand the workflows and envs, from the link below, read the the last diagram in the bottom
Project environment and workflow settings
Codebases (GitHub)
You can find a list of all codebases on GitHub for each team at this link.
How do I write/debug code?
After cloning your codebase from GitHub, now it's time to write/debug code.
Probably you won't yet have every required library installed, but worry not! We use docker container to standardise everything (versions/libraries).
In one word, you'll find it more convenient and elegant to write/debug code in docker container env (instead of on your laptop's local env).
Read the doc below to know how.
Where are these 3 envs? (dev, test, prod)
The previous section "Workflows" shows 3 envs (dev, test, prod) in the diagram. Where are they?
After reading the previous docs "How do I write/debug code?", you will be able to write/debug code locally - that is your dev env! (dev env is on everyone's laptop).
Test env and prod env are NOT on your laptop, but rather shared by all members. Where are they and how can I access them? Here's the answer.
Deploy your code
Once you have implemented new features locally and pushed your code to the GitHub repo, you can deploy your changes on the test env to see if they integrate well with other components of the project. After making sure that everything works well, it's time to deploy the new feature on the prod env and have it accessible to all our users!
Read the doc below for instructions on how to deploy.
Access databases
During your development, you might want to connect to our databases to view/modify the data. For data security reasons, databases are host differently for different environments. Our development and test databases are hosted on MongoDB Atlas and our production database is hosted on BioHPC.
Connection strings to the databases and set-up instructions are given in the doc below.
BioHPC and MongoDB Atlas Set-up
Send emails
If you need to send emails in your code, please refer to Send Emails in Your Code and use the approach discussed there.
Resource configuration details
As you have seen in the sections above, this project utilizes many cloud resources (such as AWS, BioHPC, etc.). Currently they are working well, but it's still important to know how to configure them in case the current configuration no longer fits our needs. This doc Configuration Notes contains some important configuration details about our resources. You don't have to read it during your onboarding, just keep in mind that it contains useful information that you can refer to when you want to configure cloud resources.