Service-to-Service Communication

Relevant source files

The following files were used as context for generating this wiki page:

• src/processors/recognizeRecording.ts
• src/processors/readText.ts
• stt/src/main.rs
• docker-compose.prod.yml
• src/env.ts
• src/processors/translate.ts
• src/commands/join.ts

The Discord Live Translator employs a microservices architecture to handle the complex process of voice translation. The main Node.js application (the bot service) orchestrates the workflow by communicating with specialized backend services for Speech-to-Text (STT), translation, and state management. This distributed design allows each component to be developed, scaled, and maintained independently.

Communication between the main bot and these services is primarily done via HTTP requests. The locations of these services are not hardcoded but are configured through environment variables, which are injected into the bot's container at runtime. This approach facilitates flexible deployment and configuration, as seen in the Docker Compose files.

Sources: docker-compose.prod.yml, src/env.ts

Architecture Overview

The system is composed of four main services, as defined in the production Docker Compose configuration: bot, stt, libretranslate, and redis. The bot service is the central coordinator that interacts with the Discord API and delegates tasks to the other backend services.

The following diagram illustrates the high-level service architecture and their primary interactions.

Service Configuration

The bot service discovers the network addresses of the other services using environment variables. These are defined in src/env.ts and populated by Docker Compose.

Environment Variable	Description	Default Value	Source File
STT_HOST	The URL for the Speech-to-Text service.	N/A (Required)	src/env.ts:16
TRANSLATION_HOST	The URL for the LibreTranslate service.	N/A (Required)	src/env.ts:17
REDIS_URL	The connection URL for the Redis instance.	N/A (Optional)	src/env.ts:15

Sources: src/env.ts:11-18, docker-compose.prod.yml:9-11

Speech-to-Text (STT) Service

The STT service is responsible for transcribing raw audio data into text. It is a Rust-based web server built with actix-web.

Sources: stt/src/main.rs

API Endpoint

The service exposes a single endpoint to handle audio uploads.

• Endpoint: POST /
• Request Body: Raw audio/wav data.
• Response: The transcribed text as a plain string.

The server uses the whisper-rs crate to process the audio. It is configured to always translate the audio into English (en).

Sources: stt/src/main.rs:21, stt/src/main.rs:33

Client Interaction

The main bot application interacts with the STT service in the recognizeRecording processor. It reads the recorded .wav file and sends its contents in the body of a POST request to the STT_HOST.

The following sequence diagram shows the interaction:

Translation Service

For translation, the application utilizes a libretranslate service instance. The communication is handled by the translate processor.

Sources: src/processors/translate.ts, docker-compose.prod.yml:19-25

API Endpoint

The bot interacts with the /translate endpoint of the LibreTranslate service.

• Endpoint: POST /translate
• Request Body: A JSON object with the text to translate, source language, and target language.

  {
    "q": "text to translate",
    "source": "en",
    "target": "de"
  }
  

• Response: A JSON object containing the translatedText.

Client Interaction

The translate function in src/processors/translate.ts constructs the JSON payload and sends it to the TRANSLATION_HOST. The source language is hardcoded to en because the STT service always outputs English.

Text-to-Speech (TTS) Process

Unlike STT and translation, Text-to-Speech is not handled by a network-based microservice. Instead, it is performed by executing a local Python script from within the Node.js application. This is a form of Inter-Process Communication (IPC) rather than service-to-service network communication.

The readText processor uses the execa library to spawn a python3 process.

Sources: src/processors/readText.ts:9-10

Execution Flow

The Node.js readText function is responsible for orchestrating the TTS generation.

1. It constructs the path to the Python script: src/lib/tts/read_text.py.
2. It determines the correct TTS model to use based on the target language.
3. It calls the Python script with command-line arguments for the model, text, and output file path.
4. The Python script generates the .wav file.
5. The Node.js application then adds this file to the audio playback queue.

The following diagram illustrates this local process flow:

Conclusion

The service-to-service communication in Discord Live Translator is a well-defined system that leverages a microservices pattern for core functionalities like STT and translation. The main bot application acts as an orchestrator, communicating with these services via HTTP APIs. Service discovery is managed flexibly through environment variables, making the system adaptable to different deployment environments. While TTS is handled via local process execution, it follows a similar pattern of delegating a specialized task to a separate component, contributing to the project's modular design.

Sources: docker-compose.prod.yml, src/env.ts, src/processors/recognizeRecording.ts, src/processors/translate.ts, src/processors/readText.ts