{"id":48360709,"url":"https://github.com/infraspecdev/faas-engine-go","last_synced_at":"2026-04-05T12:06:57.991Z","repository":{"id":337622782,"uuid":"1147831282","full_name":"infraspecdev/faas-engine-go","owner":"infraspecdev","description":"A Go-based FaaS engine designed as a mentorship project to understand container runtimes, cold starts, cli and event driven designs.","archived":false,"fork":false,"pushed_at":"2026-04-01T10:17:54.000Z","size":25288,"stargazers_count":0,"open_issues_count":8,"forks_count":0,"subscribers_count":0,"default_branch":"main","last_synced_at":"2026-04-01T10:22:23.054Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":null,"language":"Go","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/infraspecdev.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null,"notice":null,"maintainers":null,"copyright":null,"agents":null,"dco":null,"cla":null}},"created_at":"2026-02-02T09:02:38.000Z","updated_at":"2026-03-24T09:45:07.000Z","dependencies_parsed_at":null,"dependency_job_id":null,"html_url":"https://github.com/infraspecdev/faas-engine-go","commit_stats":null,"previous_names":["infraspecdev/faas-engine-go"],"tags_count":1,"template":false,"template_full_name":null,"purl":"pkg:github/infraspecdev/faas-engine-go","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/infraspecdev%2Ffaas-engine-go","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/infraspecdev%2Ffaas-engine-go/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/infraspecdev%2Ffaas-engine-go/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/infraspecdev%2Ffaas-engine-go/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/infraspecdev","download_url":"https://codeload.github.com/infraspecdev/faas-engine-go/tar.gz/refs/heads/main","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/infraspecdev%2Ffaas-engine-go/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":31434724,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-04-05T08:13:15.228Z","status":"ssl_error","status_checked_at":"2026-04-05T08:13:11.839Z","response_time":75,"last_error":"SSL_read: unexpected eof while reading","robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":false,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2026-04-05T12:06:56.210Z","updated_at":"2026-04-05T12:06:57.957Z","avatar_url":"https://github.com/infraspecdev.png","language":"Go","funding_links":[],"categories":[],"sub_categories":[],"readme":"# Lambda (FaaS)\n**Duration:** 8 Weeks\n**Team Size:** 2 Developers\n**Focus:** Serverless Computing, Event-Driven Architecture, Containerization\n\n## 1. Project Overview\nThe goal of this internship is to build a simplified **Function as a Service (FaaS)** platform similar to AWS Lambda using **Go** programming language.\n\nBy the end of this project, you will have built a system that allows a user to deploy serverless functions via a CLI command (e.g., `lambda deploy ./my-function`), which will package the code, run it in an isolated container, and expose it via HTTP (e.g., `http://my-func.localhost`).\n\n### Core Learning Objectives\n*   **Container Runtime:** Building lightweight, fast-spinning containers for function execution.\n*   **Event-Driven Design:** Understanding HTTP triggers, scheduled events, and async invocation patterns.\n*   **Cold Start Optimization:** Learning about container pooling, warm instances, and startup latency.\n*   **CLI Design:** Building intuitive developer tools using a suited Go library.\n\n\n## 2. High-Level Architecture\nThe system consists of three main components:\n\n1.  **The CLI (Client):** A command-line tool running on the user's machine. It packages function code and sends it to the server for deployment.\n2.  **The Gateway (API + Router):** The \"brain\" of the operation. It receives function code, manages deployments, and routes HTTP requests to the appropriate function containers.\n3.  **The Runtime Manager:** Manages Docker containers for function execution—spinning them up, handling invocations, and managing their lifecycle.\n\n### System Diagram\n\n```mermaid\nflowchart TD\n    subgraph \"User's Machine\"\n        CLI[Terminal / CLI Tool]\n        Browser[Web Browser / curl]\n    end\n\n    subgraph \"Cloud VM\"\n        Gateway[HTTP Gateway / API]\n        Runtime[Runtime Manager]\n        DB[(SQLite DB)]\n        Docker[Docker Daemon]\n        Fn1[Container: Function A]\n        Fn2[Container: Function B]\n        Scheduler[Cron Scheduler]\n    end\n\n    %% Deployment Flow\n    CLI -- \"1. lambda deploy (zip)\" --\u003e Gateway\n    Gateway -- \"2. Store metadata\" --\u003e DB\n    Gateway -- \"3. Build image\" --\u003e Docker\n    Docker -- \"4. Create container\" --\u003e Fn1\n    Docker -- \"4. Create container\" --\u003e Fn2\n\n    %% Invocation Flow\n    Browser -- \"1. HTTP Request: func-a.localhost\" --\u003e Gateway\n    Gateway -- \"2. Route to function\" --\u003e Runtime\n    Runtime -- \"3. Invoke\" --\u003e Fn1\n    Fn1 -- \"4. Response\" --\u003e Gateway\n\n    %% Scheduled Execution\n    Scheduler -- \"Trigger on schedule\" --\u003e Runtime\n\n    %% Styling\n    style CLI fill:#e1f5fe,stroke:#01579b\n    style Gateway fill:#e8f5e9,stroke:#2e7d32\n    style Runtime fill:#fff3e0,stroke:#ef6c00\n    style Docker fill:#f3e5f5,stroke:#7b1fa2\n    style Scheduler fill:#fce4ec,stroke:#c2185b\n```\n\n## 3. Example Walkthrough\n\nTo understand the project better, here is how a developer will eventually use your platform:\n\n### User Perspective (The CLI)\nImagine a developer has a simple function in a folder. They will use your tool like this:\n```bash\n$ cd my-function\n$ lambda deploy . --name greet\n[1/3] Packaging function code... Done.\n[2/3] Building image \"func-greet\"... (Docker build output follows)\n[3/3] Starting container... Done.\n\nYour function is live at: http://greet.localhost\n```\n\n### Invoking the Function\n```bash\n$ curl \"http://greet.localhost?name=World\"\n{\"message\": \"Hello, World!\"}\n\n# Or via CLI\n$ lambda invoke greet --data '{\"name\": \"World\"}'\n{\"message\": \"Hello, World!\"}\n```\n\n### Scheduling a Function\n```bash\n$ lambda schedule greet --cron \"0 * * * *\"  # Run every hour\nScheduled function \"greet\" with cron: 0 * * * *\n```\n\n### Behind the Scenes (The Server Logic)\nInternally, your **Gateway** code will look something like this (Go code):\n```go\nfunc handleInvoke(w http.ResponseWriter, r *http.Request) {\n    // 1. Extract function name from the Host header (e.g., greet.localhost)\n    // 2. Look up the function's container info from the database\n    // 3. Forward the request to the container\n    // 4. Return the function's response to the caller\n}\n```\n\n## 4. Weekly Roadmap\n\n### Phase 1: Foundation (Weeks 1-2)\n*Goal: Learn to control Docker with Go and build the function packaging pipeline.*\n\n#### **Week 1: Docker SDK Fundamentals \u0026 FaaS Concepts**\nInstead of typing `docker run`, you will write Go code to do it for you.\n*   **Objectives:**\n    *   Set up the Go development environment.\n    *   Research how AWS Lambda work internally.\n    *   Connect to the Docker Daemon via the official Go SDK (`github.com/docker/docker/client`).\n    *   Write a Go program to spin up/down containers quickly.\n    *   Measure container startup times (baseline for optimization later).\n*   **Deliverable:** A Go binary that spins up a function container and prints invocation latency.\n\n#### **Week 2: Function Packaging \u0026 Build Pipeline**\nTurning function code into a runnable container image.\n*   **Objectives:**\n    *   Create sample functions (hello-world, echo, calculator) with Dockerfiles.\n    *   Implement a Go function to package source code into a `.tar.gz` archive.\n    *   Use the Docker SDK to `ImageBuild` an image from the packaged source.\n    *   Create a lightweight base image optimized for fast cold starts.\n*   **Deliverable:** A Go function that builds a Docker image from function source code.\n\n### Phase 2: Execution Engine (Weeks 3-4)\n*Goal: Route HTTP traffic to functions and deploy to the cloud.*\n\n#### **Week 3: HTTP Gateway**\nRouting requests from the internet to the correct function container.\n*   **Objectives:**\n    *   Implement an HTTP gateway using `httputil.ReverseProxy`.\n    *   Route requests based on subdomain (e.g., `greet.localhost` -\u003e Function \"greet\").\n    *   Inject request context (query params, headers, body) into the function.\n    *   Handle function timeouts and error responses.\n*   **Deliverable:** Invoking functions via HTTP requests.\n\n#### **Week 4: Cloud Deployment \u0026 CI/CD**\nMoving from \"It works on my machine\" to \"It works on the Cloud\".\n*   **Objectives:**\n    *   SSH into the provided Cloud VM and install Docker and Go.\n    *   Create a GitHub Action that triggers on every `git push`:\n        1.  Builds the Go binary.\n        2.  Transfers it to the VM (via SCP/SSH).\n        3.  Restarts the systemd service.\n    *   Configure DNS to point subdomains to the VM.\n*   **Deliverable:** Deploy a function from a laptop to the Cloud VM.\n\n### Phase 3: Event System (Weeks 5-6)\n*Goal: Add scheduled triggers and function versioning.*\n\n#### **Week 5: Scheduled Triggers**\nRunning functions on a schedule.\n*   **Objectives:**\n    *   Implement a cron-style scheduler using a Go library (e.g., `robfig/cron`).\n    *   Add `lambda schedule` CLI command.\n    *   Handle overlapping executions (skip if still running vs. allow parallel).\n    *   Implement async invocation queue.\n*   **Deliverable:** Functions that run on a schedule.\n\n#### **Week 6: State \u0026 Versioning**\nRemembering what is deployed and supporting rollbacks.\n*   **Objectives:**\n    *   Implement SQLite for function metadata persistence.\n    *   Add function versioning (each deploy creates a new version).\n    *   Implement `lambda versions` and `lambda rollback` commands.\n    *   Ensure database persistence across platform restarts.\n*   **Deliverable:** Deploy new versions and rollback to previous ones.\n\n### Phase 4: Polish (Weeks 7-8)\n*Goal: Complete the CLI and prepare for demo.*\n\n#### **Week 7: Observability \u0026 CLI Completion**\n*   **Objectives:**\n    *   Complete the CLI with all commands: `deploy`, `invoke`, `logs`, `list`, `delete`, `versions`, `rollback`, `schedule`.\n    *   Implement `lambda logs` to stream logs from function containers.\n    *   Add basic metrics (invocation count, duration, errors).\n    *   Add authentication (API Key) so only authorized users can deploy.\n*   **Deliverable:** Full-featured CLI with observability.\n\n#### **Week 8: Documentation \u0026 Demo**\n*   **Objectives:**\n    *   Final code cleanup.\n    *   Write user documentation.\n    *   **The Demo:** You will present the project by deploying a fresh function to the live Cloud VM.\n\n\n## 5. Technical Stack\n*   **Language:** Go (Golang)\n*   **Container Engine:** Docker (via Go SDK)\n*   **Database:** SQLite\n*   **CLI Framework:** Cobra\n*   **HTTP Gateway:** Go `net/http` + `httputil.ReverseProxy`\n*   **Scheduler:** `robfig/cron` or similar\n\n## 6. Working Agreements \u0026 Expectations\nWe treat this internship as a simulation of a real engineering environment.\n\n*   **The 3-Hour Rule:** If you are stuck on a specific error for more than 3 hours, stop and ask for help. We want you to struggle enough to learn, but not enough to burn out.\n*   **Quality \u003e Speed:** It is better to have a fully working function invocation than a broken complex system.\n*   **Understanding is Key:** During code reviews, we will ask \"Why?\". You must be able to explain every line of code you write.\n*   **Collaborate:** You are a team. Don't split the work in silos (e.g., \"I do gateway, you do CLI\"). Pair program on the hard parts.\n\n## 7. Standards\n\n### Communication\n*   **Response:** Within 2 hours during working hours\n*   **Meeting Attendance:** Mandatory unless communicated in advance\n*   **Daily Updates:** Required - brief summary of progress and blockers\n*   **Documentation:** All decisions and learnings must be documented\n\n### Work Standards\n*   **Code Quality:** Follow coding standards, passes linting\n*   **Testing:** Should have basic tests\n*   **PR Reviews:** Submit work in reviewable chunks, address feedback promptly\n*   **Deadlines:** Meet timelines or communicate in advance\n\n### General Workflow\n*   **Monday:** Sprint Planning. Review the week's goals. Mentor provides a high-level overview of concepts. (30 min sync)\n*   **Tue-Thu:** Implementation. Async communication over chat to flag blockers.\n*   **Friday:** Code Review \u0026 Demo. Show what was built to the mentor. (30 min sync)\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Finfraspecdev%2Ffaas-engine-go","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Finfraspecdev%2Ffaas-engine-go","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Finfraspecdev%2Ffaas-engine-go/lists"}