Cardinal #

Cardinal is a web server that serves data from the frc1678/server project to the frc1678/viewer project.

Use #

There are two main uses for Cardinal. Both involve serving data to the Viewer app. The most important data that is sent is from the frc1678/server project and is current match and competition data. The second type of data is auto generated testing data.

Setup #

Export the value DJANGO_SECRET_KEY before running
- This key needs to be completely original
- This key should never be in git
- You can use this command to generate a key
```
dd if=/dev/urandom bs=60 count=1 | base64
```
python3 manage.py migrate
- Create and update the database
```
python3 manage.py migrate
```
python3 manage.py createsuperuser
- Create the admin account used for making a auth token
```
python3 manage.py createsuperuser
```
Create an auth token
- Run the server
- Open the website at /admin
- Log in
- Create a new token
- Copy that token into the request

Running #

Make sure to finish with setup steps

Start the server (test)
```
./scripts/testserver.sh
```
Start the server (production)
```
./scripts/runserver.sh
```

API Usage #

Test Data Generator #

# Format
curl -X GET "https://cardinal.citruscircuits.org/cardinal/api/generate/<schema_name>/?format=json"

# Example
curl -X GET "https://cardinal.citruscircuits.org/cardinal/api/generate/calc_tba_team_schema/?format=json"

# Example with count
curl -X GET "https://cardinal.citruscircuits.org/cardinal/api/generate/calc_tba_team_schema/?format=json&count=10"

Output #

[
  {
    "auto_high_balls_percent_inner": 89.7359,
    "tele_high_balls_percent_inner": 16.1893,
    "climb_all_success_avg_time": 96.7847,
    "team_name": "rNvKwQbEoMBnA",
    "climb_percent_success": 46.9206,
    "climb_all_successes": 13,
    "climb_level_successes": 8,
    "park_successes": 16,
    "auto_line_successes": 42,
    "team_number": 4665
  }
]

Roadmap #

1. System architecture & framework decision #

- Decide what framework we will use
- Decide on the architecture (framework dependent)

2. Basic functioning system & initial tests #

- Run the system on every developer's computer and troubleshoot
- Get automatic testing working with Github actions

3. Automatic test data generator API #

- Fully generate data the view can use to test from this service
- Serve test data for Viewer to easily pull using REST standards

4. Serve current competition data #

- Pull data from Mongodb about the current competition
- Setup views to serve this data
- Collect time deltas per user of when the last data was pulled
- Setup database for time deltas
- Create functionality to pull data that has been changed since last pull

5. Discuss specifics of hosting, etc. #

- Where will we host this web server
	note: this isn't as time-sensitive as development

6. Help frontend integrate this API into Viewer. (Currently here) #

- Create documentation on the API and it's proper use
- Support the Viewer's developers in their implementation efforts

7. Full systems test #

- Run the server with test data from scouts
- Run this web server and pull data from it
- Test Viewer and its ability to pull data