[RFC]: developer dashboard for tracking ecosystem build failures

[Girish-Garg]

Full name

Girish Garg

University status

Yes

University name

MBM University

University program

Bachelor's in Information Technology

Expected graduation

2027

Short biography

I am a second-year student at MBM University, pursuing a Bachelor's degree in Information Technology. My fascination with how websites and applications are built sparked my interest in coding back in 12th grade, when I discovered an Android application that taught me a bit of Python. This experience ultimately inspired me to pursue a career in software engineering.

During my first year of college, I was introduced to C as my initial programming language and gradually started exploring Data Structures and Algorithms (DSA) in Java. However, my desire to see results, such as building websites, drew me towards full-stack web development. I began learning technologies like React.js, Next.js, Express.js, Cloudflare Workers, WebRTC, WebSockets, Docker, and Redis, which deepened my passion for building robust and scalable web applications further because of my collage curriculum i learnt about postgreSQL, Structured Databases and data manipulation using it through DataCamp.

As I progressed, I discovered open-source contributions as a powerful way to learn and collaborate with real-world projects. This led me to contribute to Stdlib, marking my first open-source contribution.

Looking ahead, I am eager to expand my skill set by diving into new WebDev technologies like Three.js for 3D graphics. Additionally, the recent AI boom has sparked my interest in exploring machine learning, further broadening my technical expertise

Timezone

Indian Standard Time ( IST ), UTC+5:30

Contact details

Email: [email protected], Github: https://github.com/Girish-Garg

Platform

Windows

Editor

I prefer VS Code because it's lightweight, fast, and has great support for multiple languages. The built-in Git integration, extensions support and customization options are great and i have been using it for quite a time.

Programming experience

I have a great programming background with experience in full-stack development, data analysis.

My journey started with C and C++ during my early college years, where I built a solid foundation in Data Structures and Algorithms (DSA). Over time, I transitioned into full-stack web development, driven by my passion for creating interactive applications.

On the frontend, I am proficient in HTML, CSS, JavaScript, React.js, and Next.js. I have built dynamic and responsive websites, incorporating modern UI/UX practices and using libraries like Tailwind CSS and GSAP for enhanced styling and animations.

On the backend, I have worked extensively with Node.js, Express.js, and MongoDB, building RESTful APIs, authentication systems, and implementing payment gateways (such as Razorpay) for production-grade applications. I am also skilled in PostgreSQL for relational data management and data analysis.

Some of my key projects include:

Build Your Own Git: A project where I implemented the core functionalities of Git from scratch, including commits, branches, and version control features using JavaScript and libraries like CryptoJS.

PostgreSQL Data Analysis: A project done on DataCamp where I performed data analysis using PostgreSQL, writing efficient queries to extract insights and optimize data retrieval.

Kaahatabook: A full-stack note management platform with login/signup functionality, note-sharing features, and access locks for enhanced security with some filters like data and sorting. Built with EJS, Express.js, and MongoDB.

Domino’s Website reimagine: A frontend project where I reimagined the Domino's Pizza website using HTML, CSS, and JavaScript with GSAP for animations, focusing on UI/UX consistency.

These projects helped me to expend my knowledge toward full stack web development and Data Base Management

JavaScript experience

I have worked with JavaScript on almost all my projects, including full-stack web applications using React.js, Next.js, and Node.js. I enjoy how versatile and powerful JavaScript is it makes building dynamic and real-time applications seamless and enjoyable.

My favorite feature?
Event-driven and asynchronous programming. With async/await, handling API requests, background tasks, and real-time data becomes much cleaner and more readable. It also makes working with WebSockets for live updates incredibly smooth...also web Scrapping is really easy with JavaScript with help of puppeteer rather than other languages like python.

My least favorite?
Implicit type conversion. While JavaScript's dynamic typing offers flexibility, it can sometimes lead to unexpected results which sometime causes frustration that is why typescript comes into play but yah JS sucks sometime.

Node.js experience

I started working with Node.js while building backend services for my full-stack projects, where I handled API development, database operations, and authentication. Through projects used Node.js with Express.js to create RESTful APIs, manage MongoDB queries, and implement real-time data updates.

I’ve also worked with PostgreSQL using Node.js, building a data analysis tool that efficiently processed and filtered large datasets, but it was like a learning phase website made using Prisma ORM. I have also worked with WebSocket for Realtime communication and WebRTC for peer-to-peer connection video calling but have not leant multi peer connections and WebRTC till satisfactory rate yet.

Contributing to Stdlib has further strengthened my Node.js skills, especially in performance optimization, and writing tests.

C/Fortran experience

Thanks to my course curriculum, I learned C as my first programming language, where I gained a solid understanding of fundamentals like data types, loops, and memory management. Through my contributions to Stdlib, I’ve further enhanced my C skills, making header files and writing tests.

As for Fortran, I haven’t worked with it yet, but I’m open to learning it if required for the project which it will not most probably but I’m confident in my ability to pick up new languages and apply them effectively.

Interest in stdlib

What excites me most about Stdlib is that it offers a comprehensive and modular standard library for JavaScript and C (which is where I first discovered stdlib in collage). I admire its focus on performance, consistency, and extensive documentation, which greatly helped me during my contributions. This makes Stdlib an excellent resource for both individual developers and large-scale projects.

My favorite aspect of Stdlib is its incremental statistics and math utilities, which provide efficient, real-time computation of statistical metrics. Contributing to modules like @stdlib/stats/incr/nanmaxabs and @stdlib/math/base/special/kernel-sinf etc...gave me insights into writing clean, reusable, and well-tested code, while maintaining consistent coding standards.

I’m excited about Stdlib’s potential and the opportunity to build a developer dashboard to monitor build failures in real time feels like a meaningful way to enhance the developer experience and contribute to Stdlib with it.

Version control

Yes

Contributions to stdlib

I have contributed multiple pull requests. My main work has been in the math/base/special and stats/incr namespaces. This includes:

Adding C and JS implementations for special math functions like #6191, #6342
Adding NaN Handling to Stats incremental functions like #6116, #6109 etc.
Adding single precision float constants like #6360, #6372 (there are closed as i end up knowing that its already in PR by somebody else)

stdlib showcase

showcase website - Visualizer
Github repo - https://github.com/Girish-Garg/Visualizer

• It uses Probability Mass functions(PMF) of Binomial and Poisson Distributuion and some basic math functions like sqrt, max, and ceil all present in Stdlib to plot graph using ChartJS in ReactJS.

Goals

The goal of this project is to build a developer dashboard for Stdlib to monitor build failures in real-time across its 3500+ standalone repositories. Currently, while the backend database collects build results, there is no frontend interface for viewing and analyzing this data. This project aims to create a comprehensive dashboard that allows developers to track, filter, and investigate build failures efficiently, helping maintain the integrity and reliability of the ecosystem.

As per my thought of the project there should be a main dashboard and a inner dashboard of every repo which can make data less cluttered and visually easy to understand

These are some of my thoughts about usage of technologies:

Frontend:

• ESBuild: A really-fast JavaScript bundler which can be really great to use and mentioned in project description as well.
• ReactJS: It is already in use by stdlib-js/www which can maintain sustainability between different projects.
• React's Context API: state management is needed to reduce unnecessary re-renders if there is any prop drilling happened. I was unable to spot any state management tools used in stdlib-js/www so, i guess context api should be good enough which may not even use if there is no prop drilling happening.
• ShadCN/Material UI: A modern UI component library which can help with building frontend. it is optional as well depends upon finalized frontend design...
• Tailwind CSS: A utility-first CSS framework that allows for faster styling makes easier to style fronted.
• ChartJS: A powerful visualization library for rendering interactive charts and graphs, perfect for displaying historical build metrics and trends clearly which can be used in inner dashboard..i also have some experience with it as well.

Backend:

• PostgreSQL: A already used database in stdlib as described so its effective to carry forward it.
• Express.js/Fastify: Express.js simplifies the creation of RESTful APIs for seamless frontend-backend communication. I have not used fastify but its already in use in stdlib-js/www which can maintain consistency as well make api faster also i am learning about it now.
• JSON caching: I have been thinking how to make it put less load to the DB so my initial though about it is that caching basic filtered data using caching, then use it instead of calling DB and graphical data doesn't need to be updated like in 24hrs so it can be cached as well but i would like to talk about it to mentors like what should be the approach.

Deployment: It will be discussed with mentors as per pre-exisiting devops system

I was going through database give in description here is the visualization:

Here are some Figma designs showcasing my vision for the final product:

Main Dashboard:

• The search on the top is a universal search which will search from all the data it can be description, title, issues no. and anything which is present, in a segregated way with a ctrl k shortcut to quickly excess it anywhere in site.
• The bar in the bottom is a attribute filter bar somewhat like GitHub in which attributes can be filters normal as well as in combinations ( like AND(&&), OR( || ) )...my whole inspiration about it is to make filter custom somewhat like in github it necessary don't need to be custom but its my initial thought about it.
• The filter given above are just for showing how filter will look..the table is not filtered like it.
• Pagination will be implemented to load only a selected portion of data at a time, ensuring the application remains lightweight and efficient.

Repo-Specific Dashboard:

info about things in the design which can be missed:

• The view more button will take the user to a separate page like :repo/commit in which whole data with filter like main dashboard can be applied.
• I did make an updated version of this which looks less cluttered LINK
• The show Statistical data link will take user to a new page which will show different types of data.

Repo Activity:

info about things in the design which can be missed:

• There is a need to talk to mentors about graphs like what data points are really needed to be potted in week 1...this is just a visual representation of how it looks if done
• There is a see visualizer option in the which will help in more visualization with more data like pie charts etc..if needed

These designs will be updated and improved in week 1, while talking to mentors.

There can be still some feature which can be added like email alerts if error arises which can be discussed with mentors as an optional extra time task.

Why this project?

What excites me most about this project is the opportunity to contribute to improving the developer experience for stdlib-js as well as enhancing my knowledge through a real-time developer dashboard. The idea of creating a dashboard that visualizes build failures in real time feels both impactful and meaningful, as it directly helps contributors and maintainers.

Additionally, the technical stack of the project working with PostgreSQL, ReactJS, and modern frontend libraries perfectly aligns with my skill set and gives me a chance to further enhance my expertise. The challenge of building an efficient and user-friendly interface that provides real-time insights in this project as well as things i can learn through mentors especially appealing to me which is good enough motivation to work in this project.

Qualifications

I am well-suited for this project due to my strong technical skills, relevant experience. As a full-stack developer, I have worked extensively with JavaScript, Node.js, Express.js, React, PostgreSQL etc. Technologies that are directly relevant to this project. My experience with building APIs and creating dynamic dashboards makes me confident in my ability to deliver a robust and effective solution.

Additionally, my previous contributions to stdlib-js, including modules like @stdlib/stats/incr/nanmaxabs and @stdlib/math/base/special/kernel-sinf etc. and I have been going thought stdlib-js/www have given me hands-on experience with the codebase, its standards, and its development practices. This familiarity will enable me to collaborate effectively with the maintainers and follow the project's guidelines seamlessly.

Prior art

Similar projects focusing on monitoring build failures and providing real-time insights have been implemented by various CI/CD platforms and developer tools. For example:

NPM Status Board: NPM provides a status board that displays the real-time health of its services, including build and deployment statuses. While it is not specifically designed for stdlib-js, it demonstrates how real-time monitoring can effectively track and visualize service issues, providing transparency and reliability insights.

Buildkite & CircleCI Insights: These CI/CD services provide real-time build failure tracking with metrics and visualizations, but they are proprietary solutions. The proposed project for stdlib-js aims to create a tailored dashboard specifically for its standalone repositories, making the monitoring process more streamlined and project-centric.

Jenkins: Jenkins integrates with Prometheus for scraping metrics, which can be visualized using Grafana dashboards.

Commitment

I am fully committed to working on this project and can dedicate 30+ hours per week throughout the duration of the Google Summer of Code program. Since I will have a two-month holiday from my college, I can focus entirely on this project without any academic interruptions.

My schedule is flexible, allowing me to collaborate effectively across different time zones, attend any mentor meetings, and address feedback. I am eager to make consistent and meaningful contributions during GSoC and continue to support the project even after it.

Schedule

Assuming a 12 week schedule,

• Community Bonding Period:

  • Getting more familiar with the Stdlib codebase, especially stdlib-js/www
  • Set up local development environment
  • Study the existing PostgreSQL database as the database structure given in comments is not giving a 100% idea about some data points
  • Refine project requirements with mentors
  • Finalize technology stack decisions
  • Create detailed wireframes and designs
  • Begin writing test plans and testing strategies discussing after discussing with mentors

• Week 1:
  Goal: Establish project requirements and API architecture

  • Meet with mentors to clarify expectations and priorities
  • Analyze database structure to understand some available data points which is still unclear to me
  • Identify critical vs. secondary data points for dashboard display
  • Plan API structure and endpoints needed for the dashboard
  • Finalize backend approach with mentors

• Week 2:
  Goal: Develop core backend API functionality

  • Implement backend API structure using Fastify
  • Create API endpoints for fetching build status data
  • Develop data aggregation functions for dashboard metrics
  • Conduct integration tests with the actual database
  • Begin documentation for API usage

• Week 3:
  Goal: Complete backend API with comprehensive testing

  • Implement pagination and sorting in API responses
  • Implement throttling for updating
  • Add error handling and logging for API endpoints
  • Set up basic React project structure with ESBuild
  • Conduct performance testing for API endpoints using JMeter
  • Review and refine API based on test results using Postman

• Week 4:
  Goal: Establish frontend foundation

  • Develop core frontend components
  • Create main dashboard layout and navigation
  • Build the universal search functionality with keyboard shortcut (Ctrl+K) with debounce to prevent load
  • Connect frontend to backend API endpoints
  • Implement snapshot testing for UI components using Jest
  • Test cross-browser compatibility like for FireFox and Safari

• Week 5:
  Goal: Create repository-specific dashboard views

  • Implement repository-specific dashboard views(repo specific means all the :repo/ routes as well)
  • Develop navigation between main and repo-specific dashboards

• Week 6: (midterm)
  Goal: Implement basic filtering functionality with tests

  • Design and implement the attribute filter bar UI
  • Develop basic filtering logic for single attributes
  • Test filter functionality with various data scenarios
  • Implement frontend-backend integration for filters
  • Ensure all primary features are working correctly
  • Prepare midterm evaluation documentation
  • Address any feedback from mentors
  • Conduct comprehensive testing of all implemented features

• Week 7:
  Goal: Enhance filtering with logical operators and complete core features

  • Implement logical operators (AND, OR) for attribute filters
  • Create complex filtering capabilities
  • Develop unit tests for advanced filtering
  • Complete core dashboard and repo specific(repo specific means all the :repo/ routes as well) functionality

• Week 8:
  Goal: Develop data visualization components

  • Implement statistical data visualization using ChartJS
  • Create time-based analysis views
  • Implement performance testing for data-heavy visualizations

• Week 9:
  Goal: Implement Repository specific visualization means with graphical representation

  • Adding visual representation for commit , job ,event specific data
  • Adding Visual representation for basic repo activity trends

• Week 10:
  Goal: Enhance user experience with responsive design

  • Implement responsive design for mobile compatibility (I don't think it's needed though so this step can be skipped)
  • Optimize frontend bundle size
  • Test performance on various devices and screen sizes

• Week 11:
  Goal: Finalize features and focus on quality assurance

  • Code freeze and focus on bug fixing
  • Complete all documentation
  • Perform load testing
  • Address all critical and major bugs

• Week 12:
  Goal: Polish the application and prepare for deployment

  • Final polishing and UI refinements
  • Prepare deployment documentation
  • Create user guides and tutorials
  • Address any remaining issues
  • Perform final performance optimizations
  • Complete end-to-end testing of the entire application

Here's my entire plan for the 12 weeks. It's quite extensive, but my goal is to complete it ahead of schedule if possible.

Related issues

#GSOC idea 4

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.

[coehemang]

Nice work dude

[kgryte]

@Girish-Garg Thanks for opening this RFC. A few comments/questions:

1. Thanks for your showcase. Overlaying stats distributions is useful for helping newcomers understand the properties and behavior of those distributions. Looking at the source code, you might stand to benefit from using more of stdlib's array utilities and there's likely a fair number of utilities that stdlib offers to help with various data transformation tasks.
2. You mention end-to-end testing. How are you planning on achieving this? You have particular test frameworks in mind?
3. My guess is that you'll want to display more than 10 repos at a time. Would it be possible to display all 5000+ repositories in a single table? If not, why not? If so, how would you do this and ensure that the page remains performant?
4. It is not clear to me that a vector database is needed.
5. How will you ensure that the dashboard satisfies web accessibility concerns? (e.g., keyboard navigation, aria attributes, etc)

[Girish-Garg]

@kgryte thanks for the review and feedback...

1. yah....my bad actually while building the website it just slipped out of my mind that there are ndarray in stdlib as well😅

2. i particular don't know many frameworks for end-to-end testing except cypress so my plan will be to use it but if there are any framework which i don't knew about and referred by mentors it can also be used.

3. I don't think showing 5000+ repo in a single page is scalable as DOM will start to lag or even can cause crash making it unusable...it will not future proof + Infinite scroll will not be great as per UI standpoint. There might be some tech which can make it happen but i don't knew about that as of now

4. The vector DB is just added as a tech which can be discussed with mentors for its usable in the project which i also mentioned in proposal saying "does project need similarity-based search if not it will not be used". Currently i don't think there is any need for vector DB.

5. • There will be keyboard navigation such as Ctrl K for quick navigation, arrows keys for moving in between pages etc.
   • There will be arial labels and roles in all required places.
   • There will be proper semantic tags used instead of div.