iit-backend-v2

In this README, the words "Legacy API/Application" and "New API/Application" refer to the following:

• Legacy API: https://iit-backend.com/, Source Code: https://github.com/serotracker/iit-backend
• Legacy Application: https://serotracker.com, Source Code: https://github.com/serotracker/sero-can-webapp
• New API: https://iit-backend-v2.vercel.app/api/graphql, Source Code: https://github.com/SeanKennyNF/iit-backend-v2
• New Application: https://pathotracker.vercel.app/, Source Code: https://github.com/PathoTracker/Pathotracker/

This is a replacement for the legacy API which used to supply data to both the legacy serotracker application and the new serotracker application. This new API comes with the following features:

• The main language has been switched from Python to TypeScript.
• The production database has been switched from Postgres to MongoDB so database migrations are no longer required when the struture of the data changes (Ex. adding a new column, making a column nullable).
• The API layer has been switched from rest to GraphQL.
• The infrastructure is set up in such a way that the ETL script can be run from a local machine connected to the remote database instead of needing to ssh into production server in order to run a migration to prevent accidents from happening and to make the experience of running the ETL script more smooth.
• The arbovirus data ETL script runs noticeably faster.
• The backend can be run locally from Windows, Mac, or Ubuntu without the need for virtual machines.
• The backend is deployed to vercel and has automatic deploys set up so that merging to main automatically deploys a new version of the API without needing to connect to the remote server and pull master.
• Any endpoint or code that is used by the legacy application but not used by the new application has been removed in the interest of keeping the code short and understandable.
• All tables that are unused in the legacy api or are only used by the legacy application were removed.

Running the ETL

The ETL scripts read data from Airtable and populates the MongoDB database using that data. Some ETL scripts also make use of the Mapbox geocoding API to transform city, state, and country names to latitude and longitude values to show on the map of the application.

1. Run bash generate-env-files.sh if you have not already. You can create the environment files manually using the values in the bash script if you don't have access to the bash command.
2. Specify AIRTABLE_API_KEY, AIRTABLE_ARBO_BASE_ID, AIRTABLE_SARSCOV2_BASE_ID, AIRTABLE_EMPLOYEE_BASE_ID, MONGODB_URI, MAPBOX_ACCESS_TOKEN, and DATABASE_NAME in the .env-local-etl or .env-production-etl depending on whether you are running this on the production database or a database that you are using to test. Please reach out to a member of the development team in Basecamp if you are unsure what values to specify here.
3. Run npm i
4. For the Arbovirus ETL, run npm run run_arbo_etl_local if you're running this on a non-production database and run npm run run_arbo_etl_production if you're running this on the production database. There are other ETL scripts, for example the team member ETL script that can be run with run_team_etl_local and run_team_etl_production. You can see a full list of ETL scripts available by looking at the scripts section in package.json.

Starting the API

The API runs on the /api/graphql path.

1. Run bash generate-env-files.sh if you have not already. You can create the environment files manually using the values in the bash script if you don't have access to the bash command.
2. If you're a member of the vercel organization, please run vercel env pull to populate the .env.local file with the production values. This will run the API against the production database so be careful! If you want to run it against a non-production database, simply fill in MONGODB_URI and DATABASE_NAME in .env.local with the values of the database you'd like to run your application against.
3. Run npm i
4. Install the vercel CLI (npm i -g vercel)
5. Run vercel dev
6. Making a POST GraphQL request to http://localhost:3000/api/graphql should give you data.

Regenerating the API types

This repository works with @graphql-codegen to ensure that the types returned by the graphql resolvers match the typedefs defined in the schema. If your pull request makes any changes to GraphQL schema (For example a typedef is changed), please run the following commands and include the changes to the autogenerated files as a part of your pull request to ensure that the graphql schema and the generated types are always in sync.

1. Start the API on http://localhost:3000/api/graphql. Please see the instructions in "Starting the API" for more guidance.
2. Run npm run codegen and wait for the process to finish
3. Commit any changes to the autogenerated files as a part of your pull request.

Deploying your API changes to production

Any changes merged to the main branch should be applied to iit-backend-v2.vercel.app/api/graphql several minutes after they are merged.