[RFC]: developer dashboard for tracking ecosystem build failures

[jsndz]

Full name

Jaison Dsouza

University status

Yes

University name

St Joseph Engineering College

University program

Bachelor of Engineering in Computer Science

Expected graduation

2026

Short biography

I am a 3rd Year CSE Engineering student from India. I started my coding journey with NodeJS for backend development in my freshman year through my friends' encouragement. I am a self taught developer and an enthusiastic individual. The thing I like to do most is problem solving and building applications around it. I have been working a lot on college projects and an innovation club. Won some competitions for innovation and regional hackathons. My general interest currently is GenAI.

Timezone

IST(India)

Contact details

email:[email protected],github:jsndz

Platform

Mac

Editor

VS code because VS code is easy to use and comes with lot of extensions that are really useful

Programming experience

I started learning programming when i was in freshmen year with Backend development with nodejs. Explored a lot of Backend concept and spent a year around it. The i started learning Frontend development with reactjs. Then developed some frontend applications. I was good at backend and could work around with frontend. With this i also built some projects for college events. Now i am learning GenAI.

Notable Projects:

Dashboard for College Event
Built a dashboard to manage a product-based competition and sales tracking.
Features included a live leaderboard using long polling and real-time management of products sold by participants.

WebSocket Chat Application
A real-time chat app supporting chat rooms and socket-based communication.
https://github.com/jsndz/mayaverse

E-commerce Website
Full-stack E-commerce platform developed using the MERN stack (MongoDB, Express, React, Node.js).
https://github.com/jsndz/Noatric

Vercel Clone
A simplified clone of the Vercel deployment platform.
https://github.com/jsndz/ercel

SQLite Clone
A basic clone of SQLite to understand database internals and how query execution works.
https://github.com/jsndz/dbaCe

JavaScript experience

Javascript is first programming language I learned properly. It was a very easy language to learn and implement. My favorite feature of Javascript is its ability to run anything on the browser. You can make anything on the browser from games to apps. The least favorite feature will be Promise because i don't really like its writing style I always prefer async await.

Node.js experience

i started Backend development with nodejs. And I am using this till this day. I built almost all my application in NodeJS.

C/Fortran experience

I had C in my first year college curriculum and C taught a lot basic programming skills to me. It is one of my favorite programming language. For any low level development i always prefer C. I even built a SQLite clone with C.

Interest in stdlib

I first came to know about stdlib from a senior who was developing a Math based application. And I looked into that time but I was not skilled enough to contribute to it that time. I really love how many functionalities are available in stdlib.

Version control

Yes

Contributions to stdlib

merged stdlib-js/stdlib#5955
open stdlib-js/stdlib#6328
open stdlib-js/stdlib#6067

stdlib showcase

A Node.js application that demonstrates the usage of the @stdlib/stdlib package for statistical analysis of retail store data.
https://github.com/jsndz/stdlib-showcase

Goals

Abstract

The idea is to build a developer dashboard that will track the stdlib ecosystem. Since the database already exists, the goal is to implement a backend and frontend application that can show a real-time interface. Since the database needs to be less loaded, we will go with static snapshots which will be stored in JSON format. Subsequent rollups will be applied.

Basic Features

• Backend for handling database query
• Frontend Dashboard interface
• Quick Navigation
• Filtering and pagination
• Data analysis for historical overviews and drill down metrics

---

Implementation

1. Backend for Handling Database Queries

Tech Stack

• Fastify → Optimized for performance and used in other stdlib projects.
• PostgreSQL → The existing database for storing repository and build data.
• NodeJS Cron (node-cron) → Used for generating static snapshots periodically.

These are the basic endpoints that will be provided by the server

Method	Endpoint	Description

Cron Job for Generating Snapshots

// Function to generate static snapshot
async function generateSnapshot() {
  const snapshotData = [{ repository_id: 1, name: "repo1", status: "success" }];
  fs.writeFileSync("snapshot.json", JSON.stringify(snapshotData, null, 2));
  console.log(" Snapshot updated at", new Date().toISOString());
}

// Schedule cron job (Runs every midnight UTC)
cron.schedule("0 0 * * *", generateSnapshot);

fastify.get("/", async (request, reply) => {
  return { message: "Welcome to the Ecosystem Build Tracker API!" };
});

fastify.get("/api/dashboard", async (request, reply) => {
  return [];
});

fastify.get("/api/metrics", async (request, reply) => {
  return {};
});

fastify.get("/api/metrics/:id", async (request, reply) => {
  return {};
});

fastify.get("/api/snapshot", async (req, reply) => {
  const data = fs.readFileSync("snapshot.json", "utf-8");
  return JSON.parse(data);
});

Rollups will be done in the backend so that the frontend does not have to do the aggregate.

The important Rollups that I can think of are:

• Metrics for single repository
• Metrics for overall repositories

---

2. Frontend Dashboard Interface

Tech Stack:

• React because familiarity and simplicity
• Tailwind CSS for styling
• ESBuild for bundling

Frontend will provide three views:

• Dashboard: Which consists of a list of repositories and their information
• Metrics: Overall metrics for all the repositories like overall build stats etc
• Repository Metrics: Metrics for specific Repository. Showing all the information on builds

Here is the Figma wireframe:
https://www.figma.com/design/BAi2bJqo1vT2oZciUaGtW5/gsoc?node-id=0-1&t=jytcAuJezuGFBHb5-1

This is my first time using Figma so there might be inconsistency

---

3. Quick Navigation

Navigation Approaches:

Frontend Search

The searching functionality will be fully done on the browser. Can use libraries like minisearch for this.

import MiniSearch from "minisearch";

export function setupSearchIndex(data) {
  // Initialize and configure MiniSearch
  // Add data to the index
}

export function search(query) {
  // Run search against the index
}

async function init() {
  // Fetch snapshot or pre-indexed data
  // Call setupSearchIndex(data)
}

function handleSearchInput(event) {
  const query = event.target.value;
  // Call search(query) and render results
}

Backend Search

Backend search involves indexing the snapshot which is a better method considering the size of the database. This is done by creating a precomputed index file alongside the snapshot.

function generateIndexFromSnapshot(snapshot) {
  // Logic to create an index file from the snapshot
}

function saveIndexToFile(index, filePath) {
  // Logic to write the index to a file
}

function loadIndex(filePath) {
  // Logic to load the index from disk
}

function searchIndex(index, query) {
  // Logic to search the precomputed index
}

app.get("/search", (req, res) => {
  // Handle query and return results
});

Hybrid Approach

Hybrid approach uses both of these. And I am not very sure about it because this might be considered as an overkill.

The specific usage may need to be discussed with the mentor.

The approach I am suggesting will be indexing the database.

---

4. Filtering

Filter Category	Filter Option	Available Options	Purpose
Status Filters	Build Status (Dropdown)	All, Success, Failure, In Progress, Canceled	Allows users to filter builds based on their current status.
	Conclusion (Dropdown)	All, Passed, Failed, Canceled	Refines failure analysis by differentiating between different outcomes.
Repository & Owner Filters	Repository Name (Search)	User-entered text	Enables users to find builds related to a specific repository quickly.
	Owner (Dropdown)	User-entered text	Helps filter builds by repository owner for better organization.
Time-Based Filters	Time Range (Dropdown)	Last 1 hour, Last 24 hours, Last 7 days, Custom date range	Allows users to filter builds within a specific timeframe.
	Build Duration (Slider)	Min - Max duration (e.g., 0 min - 60 min)	Filters builds based on duration to identify short or long-running builds.
Build & Workflow Filters	Workflow Name (Dropdown)	User-entered text	Helps users filter by specific CI/CD workflows executed in the build process.
	Triggered By (Dropdown)	All, Push, Pull Request, Schedule	Allows filtering builds based on the event that triggered them.
	Run Number / Attempt	User-entered number	Helps users locate a specific build run by its unique identifier.
Commit Filters (Optional)	Commit Author	User-entered text	Enables filtering builds based on the developer who authored the commit.
	Commit Message Contains	User-entered text	Allows users to find builds related to specific changes by searching commit messages.
	Branch Name (Dropdown)	User-entered text	Filters builds by branch to differentiate between Main, Develop, and Feature branches.

The filter implementation is given here:

How filtering will be done:

For filtering we are going with doing the filtering in the backend.
Since the database is large and the size will increase, the best approach would be filtering on the backend.

The frontend will send filters with pagination setup. The backend will handle filtering and will send the required data.

Example API call:

GET /api/dashboard?page=1&limit=100&status=failed&owner=stdlib

---

5. Data Analysis for Historical Overviews and Drill-Down Metrics

Stages:

Data Querying & Aggregation

• Querying data based on specific time intervals.
• Based on the time interval we will filter data then we will get analytics for them
• To get accurate data we need aggregate the data
• We can create rollups during the snapshot creation
• Specific rollups need to be decided after talking to the mentors

The ones that I can think of are:

• Metrics for individual repo
• Combined metrics for all repositories (e.g., failures to build graph)

Visualization

• Representing data in graphs and charts.

Some visualization metrics that researched are given here:

• Failure Rate of repositories (Line Chart): repository_id, conclusion from workflow_run
• Overall trend of build successes vs failures across all repos (Bar Chart): status, conclusion from workflow_run
• NPM download trend (Line Chart): repository_id, count from npm_download_count
• How long builds are taking on average (Histogram): repository_id, created_at, updated_at from workflow_run

Drill-Down Metrics

Drill down metrics can be implemented for failure in the repository

Drill-down options are:

• Specific repositories
• Branches
• Individual commits

Why this project?

Participating in Gsoc is a dream come true. This project aligns with my tech stack and experience. And the project needs a lot of optimizations for the backend which I am really excited about.

Qualifications

I have lot of experience building many NodeJS application and features in multiple projects i did overlap with the the requested features in this project.

Some projects that i build are:

Dashboard for College event:
Built a dashboard for product competition and sales management
The product had live leaderboard which was built on long polling and had to manage various products that people were selling

Chat application on Websocket:
A chat application that was built to handle room chat.
https://github.com/jsndz/mayaverse

Ecommerce website that has Pagination and filtering:
https://github.com/jsndz/Noatric

Prior art

NPM statusboard has a similar dashboard they built it using NodeJs
AWS Repository Status Monitor shows metrics for GitHub and Docker repositories and backend is primarily python, and the data is stored and displayed using AWS cloud services.
Netdata uses lightweight agents to collect real-time system metrics and backend is primarily in C and Go.

Commitment

I will be available throughout the gsoc period
In the coding period i will commit to work for 6 hours daily for the project
but during the period of 5th June to 10th June my coding time will decrease
I have no other commitments and will work full time on the GSOC project

Schedule

Assuming a 12 week schedule,

• Community Bonding Period:

1. Familiarize with stdlib’s ecosystem and database schema.
2. Discuss and finalize implementation details with mentors.
3. Get feedback on wireframes and project scope.
4. Set up local development environment and access credentials

• Week 1:

1. Implement project scaffolding for both frontend and backend.
2. Set up Fastify server and basic endpoints (/, /api/dashboard).
3. Connect to PostgreSQL and fetch raw data.

• Week 2:

1. • Implement cron job to generate static snapshots and store as JSON.
2. • Write initial snapshot creation logic and test static file reading.
3. • Start basic frontend using React + Tailwind + ESBuild setup.

• Week 3:

1. Implement cron job to generate static snapshots and store as JSON.
2. Write initial snapshot creation logic and test static file reading.
3. Start basic frontend using React + Tailwind + ESBuild setup.

• Week 4:

1. Implement filtering (status, owner, time range) in backend.
2. Design frontend dropdowns and controls for filters.
3. Create API format like /api/dashboard?page=1&status=failed.

• Week 5:

1. Implement metrics endpoint /api/metrics and /api/metrics/:id.
2. Start visualizing general build metrics (bar/line charts).

• Week 6: (midterm)

1. Complete Dashboard and Metrics views.
2. Finalize filtering and snapshot logic.
3. Submit code for evaluation and fix any review comments.

• Week 7:

1. Begin implementation of Repository Metrics view.
2. Add drill-down capability: view builds by repo, commit, branch.
3. Start work on visualizations like failure trends, build durations.

• Week 8:

1. Create backend logic for historical rollups during snapshot generation.
2. Store computed metrics alongside snapshot for fast access.
3. Add graphs for NPM download trends and success/failure trends.

• Week 9:

1. Implement and test search (frontend + backend).
2. Use minisearch for frontend, index snapshot for backend.

• Week 10:

1. Polish UI/UX: improve filtering interactions, mobile responsiveness.
2. Add loading/error states and improve component structure.
3. Write utility scripts to re-generate snapshot and index.

• Week 11:

1. Test performance on large snapshots.
2. Add caching and optimization for repeated metric queries.
3. Finalize documentation (API usage, local setup, dev guide).

• Week 12:

1. Mentor code review and address final issues.
2. Polish and clean codebase.
3. Prepare demo video or walkthrough if needed.

• Final Week:

1. • Submit final work product.
2. Help with any remaining deployment or integration .

Related issues

No response

Checklist

• I have read and understood the Code of Conduct.
• I have read and understood the application materials found in this repository.
• I understand that plagiarism will not be tolerated, and I have authored this application in my own words.
• I have read and understood the patch requirement which is necessary for my application to be considered for acceptance.
• I have read and understood the stdlib showcase requirement which is necessary for my application to be considered for acceptance.
• The issue name begins with [RFC]: and succinctly describes your proposal.
• I understand that, in order to apply to be a GSoC contributor, I must submit my final application to https://summerofcode.withgoogle.com/ before the submission deadline.

[kgryte]

@jsndz Thank you for opening this RFC. A few comments/questions:

1. You state: "For filtering we are going with doing the filtering in the backend. Since the database is large and the size will increase, the best approach would be filtering on the backend." Why is this the best approach? Would it be possible to do the filtering on the frontend? If not, why not? If so, how would you do it?
2. Re: filter options. No need for "repository owner", "commit message", "commit author", and "branch name" fields.
3. In your showcase, you import the anova API, but you don't appear to use it. Were you planning on doing other statistical analysis in your showcase?

[jsndz]

@kgryte Thanks for your response.
1.
I am leaning towards doing the filtering on the backend and why I thought so because
it lets us return exactly whats needed like the first 50 results out of 120 matches
less work for the client means smoother performance
we avoid sending too much data over the network just the filtered stuff nothing extra
overall, it feels like a more scalable approach as the database gets larger
this is my thought process, If you have a better approach please do tell or anything i am overlooking?
2.
Got it. I will remove those fields from the filter options.
3.
I Thought of using it to do total sales across days but i didn't get enough time to execute