GSoC 2026 Project Ideas

[rsamoilov]

Rage Project Coordinator: @shetharp
Mentors: @tonekk @cuneyter @daz-codes @rsamoilov

For proposal instructions, see the Getting Started discussion.

Observability: Metrics & Context Propagation

Mentors: @cuneyter @daz-codes
Difficulty: Medium
Project Size: ~90 hours / ~175 hours

Description

To run Rage in production at scale, it needs robust observability. This project addresses two critical gaps in running Rage at scale: Context Propagation and Runtime Metrics.

1. Context Loss: Many Rage applications use ActiveSupport::CurrentAttributes to track global request data (e.g., Current.user). However, because Rage's background tasks are executed in separate fibers, this context is lost when execution moves to the background. This project involves introducing Active Support integration to ensure Current attributes automatically travel with a task when it is enqueued.
2. Missing Metrics: Users cannot see how hard the engine is working. Critical indicators like "Event Loop Lag" or "Socket Backlog" are currently invisible.

This project aims to close these gaps, making Rage fully observable out of the box.

Goals / Expected Outcomes

• Implement a mechanism for Rage::Deferred to capture ActiveSupport::CurrentAttributes at the moment of enqueueing, and restore them inside the fiber when the task runs.
• Implement low-level health checks for the reactor:
  • Event Loop Delay: Measure the delay between scheduled and actual execution.
  • Queue Depth: Measure socket backlog.
  • GC Pressure: Measure if the amount of memory allocated overwhelms the Garbage Collector.
• Update the Rage::Telemetry interface to introduce metric helpers.
• Update the official OpenTelemetry integration to export the new health stats.
• Deliverable: A Grafana dashboard showing metrics for an example application.

Skills Required

• Ruby Internals: Understanding Active Support internals and Fiber storage.
• Systems Programming: Understanding event loops and sockets.
• OpenTelemetry: Understanding tracing and metrics.

HTTP Streaming

Mentors: @tonekk @rsamoilov
Difficulty: Hard
Project Size: ~175 hours

Description

Modern applications (like ChatGPT) rely heavily on HTTP Streaming to deliver content incrementally. Rage is built on fibers, making it a perfect candidate for handling long-running requests. Currently, Rage buffers responses, which prevents this behavior.

This project aims to unlock real-time capabilities in Rage by implementing support for Chunked Transfer Encoding.

Crucially, the API must be designed to be protocol agnostic: while the underlying transport will initially be HTTP/1.1, the interface must be abstract enough to support HTTP/2 streams in the future.

Goals / Expected Outcomes

• Modify the Rage engine to support Transfer-Encoding: chunked.
• Create a developer-friendly API for streaming responses (e.g., render stream: enumerator or render file: file).
• Deliverable: A demo app showing a "Chat with LLM" style interface streaming text via Rage.

Skills Required

• Networking: Understanding HTTP/1.1 and HTTP/2 protocols, buffering, and sockets.
• Rack: Understanding the Rack interface and body proxies.

SQL Adapter for Background Tasks

Mentors: @cuneyter @rsamoilov
Difficulty: Hard
Project Size: ~350 hours

Description

Rage's background system (Rage::Deferred) currently relies on a disk-based Write-Ahead Log (WAL) for durability. While it introduces no dependencies and requires no setup, this approach is problematic for modern cloud deployments (like Heroku, K8S, or Serverless containers), where disk storage is ephemeral. If a container restarts or is redeployed, the local file is wiped, and pending background tasks are lost.

To make Rage cloud-native, we need to allow users to store pending tasks in a database (PostgreSQL/MySQL) instead of a local file.

Important Note: This project is not about creating a distributed queue like Sidekiq. The execution model of Rage::Deferred will remain local (tasks are processed by the same process that enqueued them). The goal of the project is purely data durability in stateless environments.

Goals / Expected Outcomes

• Create an adapter that persists job data to a SQL table.
• Ensure that when a Rage application boots up, it checks the database for jobs that were pending/interrupted during the last shutdown and resumes them.
• Deliverable: A configuration option (e.g., config.deferred.adapter = :active_record) that ensures jobs survive a container restart.

Skills Required

• Software Architecture: Designing clean interfaces (Adapter Pattern).
• Cloud Concepts: Understanding ephemeral storage vs. persistent storage.
• Relational Databases: Integrating with SQL databases.

Extension System (Railtie Equivalent)

Mentors: @daz-codes @cuneyter
Difficulty: Medium
Project Size: ~175 hours

Description

As Rage grows, external libraries need a standard way to hook into the framework's lifecycle. Currently, integrating third-party gems requires manual setup. In Rails, this is solved by "Railties" - a system that allows gems to automatically configure themselves, add initializers, or extend core classes when the application boots.

We need a similar extension architecture for Rage. This will allow the Ruby ecosystem to build drop-in integrations for Rage (e.g., rage-sentry, rage-devise, etc.).

Goals / Expected Outcomes

• Design specific hook points in the Rage boot process (e.g., before_configuration, after_initialize).
• Create a Rage::Extension (or similar) base class that gems can inherit from to register themselves.
• Allow extensions to expose their own configuration namespaces (e.g., Rage.config.my_extension.enabled = true).
• Deliverable: A dummy extension or a port of a simple real-world gem to verify the system works.

Skills Required

• Ruby Metaprogramming: Understanding how gems are loaded and how to modify classes at runtime.
• Framework Architecture: Understanding boot sequences and dependency injection.

Blueprinter Integration for OpenAPI

Mentors: @tonekk @daz-codes
Difficulty: Hard
Project Size: ~175 hours

Description

Rage::OpenAPI is a tool that automatically generates OpenAPI documentation by statically analyzing your code. Currently, it supports the Alba serializer for defining response structures. Blueprinter is another highly popular serializer in the Ruby ecosystem.

Because Rage generates docs via static analysis, this project involves parsing Blueprinter classes to extract their schema without loading the entire application environment.

Goals / Expected Outcomes

• Analyze how Blueprinter defines views and fields.
• Implement a parser (likely utilizing Prism) within Rage::OpenAPI to read Blueprinter definitions.
• Map Blueprinter DSL (fields, associations, views) to OpenAPI schemas.
• Deliverable: A minimal example app that uses Blueprinter with Rage::OpenAPI and generates a valid OpenAPI spec.

Skills Required

• Ruby Metaprogramming & Parsing: Understanding Abstract Syntax Trees (AST) and Static Analysys (Prism) .
• API Specifications: Understanding OpenAPI specifications.