keenanrnicholson/contour repository overview

⁠Introduction

⁠Notice: Contour is in development, and is not currently stable.

⁠Features

• Download track data for flights
• Manage logbook
• Get tour statistics

⁠Usage

Typical docker-compose.yml:

version: '3.8'
services:
  contour:
    image: 'keenanrnicholson/contour:local'
    container_name: contour
    restart: unless-stopped
    volumes:
      - /path/to/db/folder:/db
      - /path/to/file/folder:/files
    environment:
      PUID: 1000
      PGID: 1000
      ORIGIN: 'http://localhost:5173'
      TZ: 'America/New_York'
    ports:
      - '5173:3000'

Contour is not designed to be accessible to the public internet. A reverse proxy such as traefik⁠ or Nginx Proxy Manager⁠ should be used if https is required. Access to Contour should be confined to your local network or intelligently managed.

⁠Development

Contour is based on SvelteKit⁠, and therefore is developed using vite. Development for Contour is done inside a developmental Docker image.

If first-time:

# Switch to correct version of node using `nvm`
nvm use

# Install prisma globally
npm i prisma -g

# Create the database file
npx prisma db push

Create the dev image and start a local development session:

# Start dev environment
make dev

Build the project and serve it locally without creating the full Docker image:

# Build to node-adapter and preview result
make preview

Create the Docker image and serve it locally:

# Build the full image and host it locally
make create-local && make local

In all of the above cases, the front-end URL is http://localhost:5173/⁠

⁠Database

Contour uses prisma⁠ for database (sqlite) access and management, with the schema stored in prisma/schema.prisma. When the dev environment is loaded, prisma expects the database to already exist. In the production environment, prisma performs database migrations and will create the database if it does not exist. An automatic database migration is not performed in dev to allow database schema modifications and experiments without creating an official database migration.

⁠After modifying the schema during development

# Check the prisma format
pnpm exec prisma format

# Push the changes to the DB. This may delete DB data.
pnpm exec prisma db push

⁠Before committing / building the prod container

# Check the prisma format
pnpm exec prisma format

# Create a migration & push the changes to the DB
pnpm exec prisma migrate dev --name v0.0.0 # Changes this version

# Check the resulting migration file in `/prisma/migrations` to make sure it will do what is expected during the migration

⁠node_modules

During development, a node_modules folder is created in the top-level directory. Note that the libraries within are not necessarily compatible with your local machine, as they were installed within the Docker container environment. This means that if npm i is ran outside the Docker container, the incorrect libraries will be loaded by the dev environment. If issues are encountered with respect to dependencies, delete the node_modules folder and try again to allow the container environment to install the correct libraries.

⁠Folder Structure

All source code is in src, with lib and routes being the primary development folders.

Directory       Client/Server   Description
───────────────────────────────────────────
src
 ├─lib
 │  ├─components      C         # Svelte components
 │  ├─events          C         # Client-side event library
 │  ├─helpers        S/C        # Client-side and server-side helpers
 │  ├─server          S         # Primary server code
 │  │  ├─helpers      S         # Server-side helper functions
 │  │  ├─prisma       S         # Prisma instance
 │  │  └─settings     S         # Settings sub-system
 │  └─types          S/C        # Shared client-side and server types
 └─routes            S/C        # Front-end routes and API endpoints
    └─api            S/C        # Front-end API endpoints

⁠dev vs prod

There are some differences between the dev environment and the production environment. The primary difference applicable to development is hot-reloading. Since vite watches for changes in files, and the dev Docker container is mounted to the local file directory, changes in code will trigger a reload in the dev environment. This makes for very efficient development, as the container does not have to be restarted to reflect changes. However, the hot-reload is not an actual reload. The following are some examples of async code server-side that will still exist after the hot-reload:

• setTimeout and setInterval functions
• The processes created by child_process.spawn(...) and similar
• Anything stored in global

⁠Debug Logs

During development, it is often useful to see more logs. Activate debug in settings to increase the verbosity of console logs. Use the debug level setting in code when appropriate:

const debug = await settings.get('system.debug');
if (debug) console.log('Debug message here!');