API Folder Structure Documentation #

Root Files #

  • main.ts: Entry point of the application.
  • Dockerfile: Instructions for building the Docker image.
  • deno.json / deno.lock: Configuration and lock files for the Deno runtime.
  • .dockerignore: Docker-related ignore file
  • README.md: Overview and setup instructions for the project.
  • dev_deps.ts: Development dependencies for testing and linting.
  • deps.ts: Centralized import of third-party dependencies.

Folders #

api/ #

Contains route handlers for different services (e.g., Yoto and WhatsApp APIs).

controllers/ #

Implements logic for each domain entity and handles incoming requests.

routes/ #

Defines URL endpoints and associates them with corresponding controllers.

services/ #

This folder has service files for each database table to control interaction between the API and the database, along with some other misc services like audio conversion.

models/ #

Database models representing entities such as accounts, playlists, and audio content.

middlewares/ #

Contains reusable middleware functions, such as authentication.

utils/ #

Helper functions and utilities (e.g., JWT handling, logging, error formatting).

constants/ #

Holds static values used across the codebase, like message templates and event names.

events/ #

Manages application-wide event publishing and subscription.

mqtt/ #

Handles MQTT-specific logic, including service configuration and message handling.

database/ #

Manages the connection to the database.

data-init-scripts/ #

SQL scripts to initialize the database schema and seed essential data.

data/ #

Static assets used by the app—includes audio files, icons, and default data like playlists.

Controllers #

account.controller #

This controller is responsible for the Web App's Account manipulation endpoints. For example, creating, fetching, updating accounts.

member.controller #

This controller handles Member related CRUD endpoints for the Web App.

events.controller #

The API uses an events bus system to pass things (e.g. voice notes, or emoji send-attempts) through the process steps they need (e.g. fetching audio, converting audio, uploading to Yoto etc). Unlike the other controllers that are essentially paired one-to-one with an API route, these are generally paired one-to-one with an app event (see constants/events.ts) and handle the event before passing it to the next. See the main.ts file where these events and handlers are linked.

whatsapp.controller #

This controller holds all the logic for Whats App API's webhook when an incoming message is received. It will filter out the unwanted messages and pass the correct ones via the AUDIO_RECEIVED event to the appropriate handler, thus starting the event process.

yoto.controller #

There are some endpoints which essentially hit the official Yoto API and return the results, this controller handles those. Things like fetching Yoto Icons or getting an auth URL.