High Level Design (HLD) Architecture

Cloud-Native Compiler Service

This document outlines the high-level design and architecture of the Multi-Language Compiler, a cloud-native platform engineered to provide a robust, scalable, and efficient environment for compiling and executing code across multiple programming languages.

The core architectural philosophy is centered on a decoupled, service-oriented model. This design leverages modern DevOps practices, including full containerization and an automated Continuous Integration and Continuous Deployment (CI/CD) pipeline, to ensure rapid development cycles and reliable deployments on the Google Cloud Platform (GCP). The system is logically separated into two primary domains: the Core Application Services that deliver functionality to the end-user, and the Automated Infrastructure Services that govern the build, test, and deployment lifecycle.

2. Core Application Architecture

The application itself is structured as a classic three-tier architecture, ensuring a clear separation of concerns between presentation, logic, and data. This model enhances scalability and maintainability by allowing each component to be managed and scaled independently.

• 2.1. Frontend Service (Presentation Tier)

  • Technology: A modern web application built with Next.js, React, and TypeScript.

  • Responsibility: This service is the sole entry point for user interaction. It provides a rich, responsive user interface featuring a code editor, language selection dropdowns (LanguageSelector.tsx), and a real-time output panel (OutputPanel.tsx). It is a pure client-side application that communicates with the backend exclusively through API calls.

• 2.2. Backend Service (Application Tier)

  • Technology: A high-performance, asynchronous API developed in Rust using the Axum framework.

  • Responsibility: This service functions as the brain of the operation. It exposes a stateless REST API—primarily the /api/compile endpoint as seen in main.rs—to handle all incoming compilation requests. Its duties include:

    • Receiving and validating incoming code and language specifications.

    • Orchestrating the execution of code by invoking the appropriate sandboxed runtime (e.g., rustc, the Python interpreter, gcc, or the custom language's own evaluator).

    • Capturing the stdout and stderr from the execution process.

    • Communicating with the database to persist request and result data.

• 2.3. Database Service (Data Tier)

  • Technology: A PostgreSQL relational database, with its schema and migrations managed declaratively by Prisma ORM (schema.prisma).

  • Responsibility: This tier provides a persistent, reliable storage layer. It is the single source of truth for all data, including historical code snippets, execution times, language choices, and compilation outputs, as defined by the CodeSnippet model.

3. CI/CD and Deployment Architecture

The project is underpinned by a fully automated CI/CD pipeline that facilitates a seamless and reliable path from code commit to production deployment on Google Cloud Platform.

• 3.1. Source Control & Trigger

  • Platform: GitHub.

  • Functionality: Acts as the central code repository. Any git push or pull request to the main branch automatically triggers the CI workflow.

• 3.2. Continuous Integration (CI)

  • Platform: GitHub Actions, configured via .github/workflows/rust.yml.

  • Functionality: This automated workflow is responsible for:

    • Building: Compiling the Rust backend and the Next.js frontend.

    • Testing: Running automated tests to validate code integrity and functionality.

    • Packaging: Creating immutable, versioned Docker container images for each service, as defined in their respective Dockerfile.

• 3.3. Container Registry & Deployment

  • Platform: Google Cloud Platform (GCP).

  • Functionality:

    • The Docker images generated by the CI process are pushed to a secure, private registry like Google Artifact Registry.

    • A Continuous Deployment process, also managed via GitHub Actions or GCP's Cloud Build, automatically deploys the new container images to a scalable, serverless environment such as Google Cloud Run, ensuring zero-downtime updates.

4. System Data Flow

The system operates on two distinct data flows: the user interaction flow and the development/deployment flow.

• User Interaction Flow:

  1. The user writes code in the Next.js Frontend.

  2. The frontend sends a secure POST request to the /api/compile endpoint of the Rust Backend API running on GCP.

  3. The backend executes the code, captures the output, and logs the transaction to the PostgreSQL Database.

  4. The backend returns the result in a JSON response to the frontend.

  5. The frontend dynamically renders the output for the user.

• Development & Deployment Flow:

  1. A developer pushes a code change to the GitHub Repository.

  2. GitHub Actions is triggered, which builds, tests, and packages the code into Docker images.

  3. The new images are pushed to the Google Artifact Registry.

  4. The Google Cloud Run services automatically pull the new images and deploy the updated application.