DSTs Architecture Preliminary Design

Project Name: DST Database/API Architecture

Date: 08/23/2022

Written By: Mikah Pinegar

Introduction

This document will be the starting point for solidifying the thoughts from the meetings we’ve had thus far. Feel free to add or edit sections or leave comments. This process will need a lot of hands.

System Overview

There are 5 tools meant to assist farmers in the cover crop decision making process. The goal is to modularize the tools in a way that will allow seamless navigation between the tools while still maintaining their independence.

The 5 tools are listed below

1. Cover Crop Species Selector

   1. The species selector DST is used to help farmers select a cover crop that fits their goals and constraints. The user can either input specifics about their field location and cover cropping goals or explore cover crops without entering those details. The tool is mainly used to explore expert recommendations and ratings for cover crops in the farmer's USDA Plant Hardiness Zone. This allows farmers to make educated decisions that are best suited for their specific goals and can save time as opposed to calling the extension office.

2. Cover Crop Economics Calculator

   1. The economics calculator is used to help farmers get a quantitative idea of how much money it will cost to implement cover crops for their specific farms. They enter in data about their farm and the cover crops that they want to grow and the calculator will estimate the initial cost as well as the long term savings of cover cropping. This allows the farmer to make better informed financial decisions that are tailored to their situation.

3. Cover Crop Nitrogen Calculator

   1. The nitrogen calculator is used to help farmers by giving an estimate of the nitrogen output for a given cover crop. The farmer will enter data about their fields, cover crop(s), cash crop, and important dates and the model will output the expected nitrogen output as a function of time. It also is estimates the cash crop nitrogen uptake as a function of time.

4. Cover Crop Seeding Rate Calculator

   1. The seeding rate calculator is designed to help farmers determine the ratio of seeds needed to optimally cover crop their specific fields. The farmer will input metadata about the field and which cover crops they want to plant and the tool will give a recommendation about what ratio of seeds they should plant.

5. Water Calculator

   1. The water DST provides a Web interface and an API for the MAIZSIM corn simulation model.

Design Considerations

There will be 5 independent DSTs that will have a shared user history and some inputs and outputs will be shared between tools.

Assumptions and Dependencies:

Each DST needs to be fully independent and be able to easily be moved to a different provider. We want to have shared user experience data for our first iteration but we don’t want this user data to bog down the individual DST DBs in the event that a big provide (Bayer, John Deere, Farmers.gov, etc.) decides to acquire any of the tools.

General Constraints

We want new members of the team to be able to quickly get up to speed with how things are architected and not get slowed down with one off design choices.

Goals and Guidelines

The tools should all follow the best practices outlined in the Onboarding space.

Development Methods

We will be using a simple version of the scrum methodology.

Architectural Strategies

The front end will be written in React, and styled using material ui. The API language will be Node.js (TBD). The databases will be PostgreSQL. DevOps TBD.

System Architecture First Draft

This is the first draft overview of the design discussed in the 8/22/22 DST meeting.

• Each DST will have its own PostgreSQL database that only stores the data and logging needed to make the app run (no user history)

• Each DST will have its own API (first guess Node.js) that will interact with its DB. This API will likely only be reading data and will not need authentication

  • The API will represent the app as a whole: it will take the inputs and return a recommendation

• There will be a shared PostgreSQL DB and API that requires authentication that will hold user history and meta data to be used throughout all the DSTs

Open

• Each DST will be able to be used via its API alone so that they can call any of the others and get a recommendation. This will be important for setting default values etc.

• Three user tiers for the applications that the user will choose from

  • Anonymous

    • no history between visits

  • Logged in but data is not to be used for research or aggregated (default)

    • Users will have history between visits and be able to view their previous recommendations and info about their farms

  • Logged in and data can be used for research or aggregated

    • Users will have history between visits and be able to view their previous recommendations and info about their farms

    • We will be able to analyze this user data for research purposes

System Architecture Second Draft

This is the second draft overview of the design based on meetings

• Each DST will have its own PostgreSQL database that only stores the data and logging needed to make the app run (no user history)

• Each DST will have its own node.js API that will interact with its PostgreSQL DB

  • The API will represent the app as a whole: it will take the inputs and return a recommendation without the need of a front end. This will be important for setting default values for the other DSTs etc.

• There will be a shared PostgreSQL DB and API that requires authentication that will hold user history to be used throughout all the DST front ends

• There will be a shared PostgreSQL DB and API that will hold shared cover crop data to be used throughout all the DST APIs

Open

• The shared CC data will be the single source of truth, and the entry point for maintaining general cover crop data. The Shared CC Data API will utilize the observer pattern to ensure that any service that subscribes to it will always be notified when data changes occur, and it will be the responsibility of the subscribed service to update its databases. This allows any service that depends on cover crop data the ability manage its own data dependencies and creates a loose coupling, giving all services the ability to be cloned and capable of running without the need of external resources, but will be able to utilize the Shared CC Data as an external data source.

Detailed System Design

CC Image Storage

• Store original resolutions images in azure blob storage

  • Folder structure will be /<CC Species Name>/<images> so it’s obvious to the users what images are associated with what crops and where to put new images

• Store metadata in a table inside the shared CC data DB so it doesn’t need to get split out of the file name

• Resize the images in the front end using CSS

• Return image metadata and locations with routes like below

  • List all species (ex GET /images)

    [ { "ccName": "Alfalfa", "images": [ { "imageURL": "<blob url>", "isThumbnail": <true or false> "growthStage": "<stage>", "owner": "<owner>", "yearTaken": "<year>", "notes": "<notes>" }, ...etc ], }, ...etc ]

  • List a specific species (ex GET /images/<species>)

    { "ccName": "Alfalfa", "images": [ { "imageURL": "<blob url>", "isThumbnail": <true or false> "growthStage": "<stage>", "owner": "<owner>", "yearTaken": "<year>", "notes": "<notes>" }, ...etc ], },

Phases

1. Research

2. Design meeting

3. Architectural decisions

4. Implementation

Glossary

An ordered list of defined terms and concepts used throughout the document.