Backend Database and Endpoint Design

[erikhuck]

Part of the design is determining what kind of data is needed from the back end. Here are two possible end points for the back end web API which the front end can use.

• An endpoint which returns the tree structure
• An endpoint which returns specific species information

The tree structure could be built from a collection of branches, the leaves of which could be species names. The branches could each have two children. The children could either be another branch or a species name leaf. The species names could refer to records in a collection of species which contains more information about the species.

Database Schema

The schema follows this format

Collection

field 1: type1 field 2: type2 ...

species

name: String longitude: number latitude: number dnaSequence: String imageUrl: String

branches

height: number width: number length: number child1: ObjectId child2: ObjectId

trees

name: String rootBranch: ObjectId

The front end could send a request for a tree, such as "great apes", and the root branch of the tree would be looked up using the trees collection. The tree would be constructed using the root branch. The front end could additionally request a specific species name and the backend could use that name to return specific species information from the species collection.

[erikhuck]

With a database comes the need for database migrations. We should also be using an ORM. We have discussed using mongoose but we could also use PostgreSQL. Here's some more info I was able to find:

• A popular ORM for mongoDB is mongoose (https://www.npmjs.com/package/mongoose) which does not evidently contain migrations functionality but an additional node package known as migrate-mongo (https://www.npmjs.com/package/migrate-mongo) does
• sequelize (https://sequelize.org/master/index.html) is a popular ORM for SQL databases including PostgreSQL and does contain built-in migration functionality (https://sequelize.org/master/manual/migrations.html)

[jbeatty88]

Height, width, and length are tentative. Frontend needs to work out how the data will be rendered. Will have an update before next class.

[erikhuck]

Changes: Get rid of branches table. The trees table will not point to a root branch but instead will have the entire tree stored as a (maybe BLOB, maybe json string) if our SQL database allows for data that big (otherwise we might need to re-introduce the branches table). The back end needs to take out the species information from the leaves of the tree files and put them in their own table.

[erikhuck]

Much of the decisions for this issue have been made and the remaining are covered in #52 and #43