the-r3aper7/gsoc-2024

TABLE OF CONTENTS

• Introduction
• Goals
  • Roadmap to Status Dashboard
    • Dashboard Designs
    • Project Structure
    • Communication with APIs
    • Implementation of REST API
  • Roadmap to Historical overviews and per package metrics.
    • Per Package Metrics Designs
    • Extending Frontend
    • Extending API
  • Project Documentation
• Why this project?
• Qualifications
• Commitment
• Schedule

Introduction

Full name

Sai Srikar Dumpeti

University status

Yes

University name

Birla Institute of Technology, Mesra

University program

Bachelor of Technology in Computer Science

Expected graduation

2026

Short biography

I am a 2nd year B.Tech. Student in the department of Computer Science and Technology at Birla Institute of Technology, Mesra. I started my programming journey from 2019 in High School i.e 12th Standard. I am a self learnt programmer who likes to learn new things by creating new projects. Here are some programming languages and frameworks which I have learn:

• Go
• Python
• JavaScript
• TypeScript
• Reactjs
• Svelte
• HTML/CSS
• Jest
• Stimulus

In College I have completed many courses like Problem Solving with Programming in C, Object Oriented Programming, Data Structure and Algorithms and many more. Currently attending courses of Database Management Systems, Design Analysis of Algorithms, Operating System. My Interests lie in Web Development and creating new things.

Timezone

Asia/Kolkata UTC +0530

Contact details

• Email: [email protected]
• GitHub: https://github.com/the-r3aper7
• Gitter: https://matrix.to/#/@the-r3aper7:gitter.im

Platform

Linux (Fedora)

Editor

For development I use Fedora as Operating System and my editor is VSCode because it is simple to use, learning curve is less and comes with lots build int features like emmet features and extensions. However, I have learned basics of vim for working on servers.

Programming experience

I have significant knowledge of programming, when I first started to learn programming in high school where I started my first language with Python I was fascinated by it. Afterwards I started to explore various fields but Web Development caught my interest. I have created some projects using Django Framework. Then, I started to learn JavaScript so that I can learn React for the front-end. Then I started contributing to Open Source to learn new things and it was great for exploration. I have learned a lot from Open Source and met a lot of amazing people.

JavaScript experience

I've been having a great time learning JavaScript and working with it on front-end projects in open source environments. The best part about JavaScript is that you can literally build anything with it, from mobile apps with frameworks like React Native to web apps, games, and much more. Recently, I even came across a project where they built a whole operating system in the browser called OS.js

Problems with JavaScript is that it has loose typing which can lead to problems if you don't use tools like TypeScript to add type safety. While JSDoc can help with documentation, it doesn't enforce types.However, there is a RFC going on where we can Static Types in JavaScript in Future. Another challenge is callback hell where nested callbacks can make code difficult to read and hard to maintain.

Here are some of my works with JavaScript:

• Checkout my personal site which I have created while I was learning Svelte link to Repo.
• Checkout Next.js file server which I have created while I was learning Next.js.
• Revamped the media page of Qwik checkout the PR.
• Small Changes to Sidebar to Qwik checkout the PR.
• Another Small Improvement in Qwik's Media Page checkout the PR.
• Here is a website which I created for a client which was needed in 24hrs.

Node.js experience

I haven't directly worked with Node.js yet, but I did leverage the API features of Next.js v12 to create a file server interface for a local network. This project allowed for basic upload, download, and streaming functionalities. Check it out on GitHub here: Nextjs File Server

I'm definitely interested in getting more hands-on experience with Node.js in the future.

C/Fortran experience

While I haven't had the chance to create a full project in C yet, I did take a course in Programming for Problem Solving in C during college. This course involved implementing basic algorithms in C, which provided a strong foundation in the language's core concepts.

Interest in stdlib

While I am still developing my knowledge of statistics and machine learning algorithms, I have been impressed by the stdlib-js/stdlib library. It offers a collection of smaller, focused packages instead of a single, massive library that could bloat your bundle size. What particularly excites me is the ability to perform NumPy-like operations directly in the browser. The plotting API seems like a fantastic example of this functionality. I've also found the stdlib community to be very welcoming and approachable.

Version control

Yes, Currently I am using Git as primary VCS.

Contributions to stdlib

Here, are the statuses of some PR's which i have authored.

Status Merged

All PRs which are merged

• feat: added utils/every-in-by
• feat: add math/base/special/acscd
• feat: add math/base/special/asecd
• feat: add math/base/special/secd
• feat: add math/base/special/cscd
• feat: add math/base/special/acotd
• feat: add math/base/special/atand
• feat: add math/base/special/acosd
• feat: add math/base/special/asind
• feat: add math/base/special/cotd
• feat: add math/base/special/tand
• feat: add math/base/special/cosd

Status Opened

All Prs which are opened

• docs(added readme examples for random/iter): added examples

Issues Opened

All issues which are currently opened

• none

Goals

Abstract

Stdlib is a Open Source Project written in JavaScript, Stdlib provides 3000+ high performance packages which can be used for numerical and scientific computation, statistics. Since, it is written in JavaScript we can used it any where some mobile via react-native, Node.js and Browsers. My proposal is to create a developer dashboard for tracking build status of those 3000+ repository. We may want to achieve this using Reactjs and Fastify for backend which will serve static files and API responses.

Description for Project

For my completing my project I am going to divide it into 2 parts:

• Roadmap to Status Dashboard.
• Roadmap to Historical overviews and per package metrics.

Here are some libraries and tools which will be useful in this project.

• Vitejs is a great build tool as it provides various features like code-splitting, optimized builds and faster workflows.
• Reactjs is a popular framework for building websites. Since we are in the initial stages we may not want to bloat the application with various technologies. Let's go simple and clear.
• postgres we can use this library querying data from database directly in JSON format which we can be easily used for formatting and sending it to frontend for rendering.
• Fastify as the name suggests is fast and less overhead for creating REST API's. Fastify Ecosystem provides lots of plugins which will make DX easier and simpler. Since, we will be serving our react app from the same port as Fastify this will avoid the process of CORS.
• Tape for testing the REST APIs and server.

Roadmap to Status Dashboard

• Here are some designs which I am thinking of for the Status Dashboard.

  Index Page

  

  Index Page Explanation

  

  Index Page when filter button is clicked

  

  Explanation

  

  Index Page when data is fetching

  

  Explanation

  

  Index Page when error occur in data fetching

  

  Explanation

  

  Links for the above designs:

  • Prototype of the website
  • Designs of the website pages and instances
  • Designs of the website components
  • Designs of the website table

• This may be the project structure for our frontend part of the website.

  

  Components: from the above design we may use these components initially.

  • Table.jsx
  • Header.jsx
  • Chip.jsx
  • Icon.jsx
  • Card.jsx
  • Modal.jsx

  Context: Since, we are making it leaner and simple we may want to use Reactjs Context API to avoid prop drilling. We may store recently fetched data, search query and as project requirements while developing.

  Constants: we will store all constants like API urls that may be removed as per suggestion.

• Communication with APIs

  Since, we are seeking the project to be as simple as possible so we will use the Fetch API which is used by browsers natively for communication. We can create a Component for rendering table data.

  Checkout the example component which fetched the data from an API.

  NOTE! This is a mockup component for the proposal that might change in the real project.

  Now, we easily render table data with changing urls and store the api response to a context as it would be easy to modify the data when a user clicks on Sort Icon as this would be deeply nested in the component tree.

• Implementation of REST API

  • / (GET): for serving the index.html file.

  • /assets (GET): for serving static files like css, js, svgs etc.

  • /search (GET): this route serves JSON data for a given query. Here are some search query parameters which it will take.

    • q (required) (type: string) for querying by the package-name.

      Here, are some DX improving shortcuts to search.

      Basic Syntax will [header cell/filter type]=[...]

      • if type is string then use ^.
      • if type is number then use -(for range), >=, >, <=, <.

      1. Initially when you type into search bar it will search for package which contains the package name in SQL which will look like this select packagename from packages packagname like '%q%' (NOTE JUST A MOCK QUERY).

      2. Suppose you want to search for package.

         • Starts with given query you can type name=^name-of-package.
         • Ends with given query you can type name=name-of-package^.
         • if you type name=name-of-package this will be treated as default.
         • Examples: name=^iter

      3. Suppose you want to filter your searches based on stars which is a number.

         • Range of star you can type stars=1-10
         • Less than a specific number you can type stars=<10
         • Greater than or Equal a specific number you can type stars=<=10

      4. You can also combine multiple shortcut which is delimetered by ' ' (space) will look like this.

         • stars which ranges from 1 to 10, having math in their package name you can type something like name=^math stars=1-10.

    • page (required) (type: integer) which will be useful for pagination.

    • size (required) (type: integer) size of table rows which will render on client side.

    • filters (required) (type: string delimetered by ",") we can use these serve only the data required by the client.

    Response Skeleton

    {
      data: [
        {
          id: string, // useful for as key while mapping
          name: string,
          stars: number,
          status: string,
          license: string,
          lastModified: string,
          ... // add more to response as filters are applied
        }
        ...
      ],
      nextPage: string, // url with filters, size and q to next page.
      length: number, // current length of data.
    }

  • /packages (GET) this route will the table data.

    • page (required) (type: integer) which will be useful for pagination.
    • size (required) (type: integer) size of table rows which is currently selected.
    • filters (required) (type: string delimetered by ",") to serve only the data required by the client.

    Response Skeleton

    {
      data: [
        {
          id: string, // useful for as key while mapping
          name: string,
          stars: number,
          status: string,
          license: string,
          lastModified: string,
          ... // add more to response as filters are applied
        }
        ...
      ],
      nextPage: string, // url with filters, size to next page.
      length: number, // current length of data.
    }

Roadmap to Historical overviews and other drill down metrics.

• Here are some designs which I am thinking of for the metrics page.

  Overview Page when Downloads is selected.

  

  Overview Page Explained.

  

  Here are some Ideas for Other Metric like Build Failures.

  Only failures

  

  Only success

  

  Fusion of Both

  

  Links for the above designs:

  • Prototype of the website

• Extending Frontend

  • Currently for demo purposes I have used Lightweight Charts library by Trading View.

  NOTE! this may change as recommended by mentors in Community Bonding Period.

  • Adding Polling to Status Dashboard with dropdown menu for selecting the time interval.

• Extending API

  • /metrics/:package-id (GET) which will take these search params.

    • type (required) (type: string delimetered by ",") this mean we can have downloads, code coverage, build failures and many more .

    Response Skeleton

    {
      pkgName: string,
      githubURl: string,
      documentation: string,
      data: {
        downloads: [
          { date: string, value: number },
          ...
        ],
        codeCoverage: [
          { date: string, value: number },
          ...
        ],
        buildFailures: [
          { date: string, value: number },
          ...
        ]
        // add more data as defined in type
      },
    }

Project Documentation

To ensure the codebase remains well-documented, I plan to document it with each pull request (PR) I submit. This way, the documentation burden stays manageable, especially as deadlines approach. Specifically, I will focus on documenting the changes I introduce in each PR, keeping the overall documentation up-to-date without requiring a separate, time-consuming documentation task.

Why this project?

I am particularly interested in this project because it allows me to use my skills to create a tool that will positively affect the community. Best part of this, I can apply the frontend development skills I have learned through contributions to various open-source projects, along with my experience creating and working with APIs. This project presents a fantastic opportunity to use my knowledge and experience to work on something.

With the help of the developer dashboard, we can quickly view which packages have problems in their build status. This allows us to address issues for specific packages easily. Without the dashboard, you would have to go to every single package repository to check their build statuses. By using the dashboard, we can navigate and work more efficiently.

Qualifications

I've made significant contributions to several well-respected frameworks. Here are some highlights:

• Qwik's website a frontend framework which introduced Resumability to frontend world.
  • I helped enhance the user experience of Qwik's website by redesigning the Media Page
  • I'm also nearing completion on the development of the package manager tabs which will be integrated into production soon.
• Wagtail
  • Implementing a production-ready url generator copy button using stimulusjs
  • Migration of components from vanillajs to stimulusjs here are some migrations enableDirtyFormCheck and tabs.js

In addition to my open-source experience, I'm currently enrolled in a Database Management System (DBMS) course at college. This course is equipping me with the skills to execute queries efficiently and apply optimization techniques, which I'm eager to leverage in this project.

Prior art

Yes, there is similar project like this from npm where they are also tracking the build status, total downloads and many more things. From what I have understand from their Github Repo

They have created a folder named workspaces which contains 2 projects

• www from here they are serving simple HTML, CSS, JS and using jquery for DOM manipulation.
• data from here they are serving their content from REST service or GraphQL as needed.

All these things are automated by using GitHub Actions.

Commitment

I plan on devoting my entire summer to this. I won't have any other kind of job, so I will be able to work a standard 40 hour week for the coding period. Also, my classes will end well before the coding period begins and will not start up again until well after the pencils down date, so I will be totally free for the whole period.

Schedule

Weeks 1: Community Bonding & Planning

• Activities:
  • Finalize frontend design with mentors (including user interface (UI) mockups or wireframes).
  • Discuss and document API routes and website theme.
  • Set up the development environment (including database setup if needed).
• Deliverables:
  • Approved UI mockups/wireframes.
  • Documented API routes and website theme.
  • Development environment configured (including database setup, if applicable).

Weeks 2-4: Frontend Development & Core Functionality (Roadmap to Status Dashboard)

• Activities:
  • Implement core frontend components with clear and concise code.
  • Thoroughly document components with comments and per-PR documentation.
  • Integrate front-end with APIs (if possible at this stage).
• Deliverables:
  • Functional frontend components.
  • Well-documented code with per-PR documentation.
  • (Optional) Initial frontend-API integration.

Weeks 5-7: Midterm and Per Package metrics (Roadmap to Historical overviews and per package metrics)

• Activities:
  • Conduct a mid-term review with mentors to assess progress and address any concerns.
  • Start working on the Package Overview page.
  • Continue documenting code throughout development.
• Deliverables:
  • Fully functional website with core functionality.
  • Functional Package Overview page.
  • Ongoing code documentation.

Week 8: Performance Optimization

• Activities:
  • Analyze and optimize database queries using the Postgres library.
  • Consider performance optimization techniques for the frontend (e.g., caching, lazy loading).
• Deliverables:
  • Optimized database queries.
  • Improved frontend performance (if applicable).

Weeks 9-11: Testing & Refinement

• Activities:
  • Write tests for APIs using Tape.
  • Fix any bugs identified during testing.
  • Continue with code documentation.
• Deliverables:
  • Comprehensive unit tests for APIs.
  • Bug-free website.
  • Well-documented codebase.

Week 12: Finalization & Review

• Activities:
  • Conduct a final review with mentors to ensure project completion aligns with initial goals.
  • Document any remaining parts of the codebase.
  • Prepare for presentation or deployment (if applicable).
• Deliverables:
  • Project reviewed and approved by mentors.
  • Fully documented codebase.
  • Project ready for presentation or deployment.

Notes:

• The community bonding period is a 3 week period built into GSoC to help you get to know the project community and participate in project discussion. This is an opportunity for you to setup your local development environment, learn how the project's source control works, refine your project plan, read any necessary documentation, and otherwise prepare to execute on your project project proposal.
• Usually, even week 1 deliverables include some code.
• By week 6, you need enough done at this point for your mentor to evaluate your progress and pass you. Usually, you want to be a bit more than halfway done.
• By week 11, you may want to "code freeze" and focus on completing any tests and/or documentation.
• During the final week, you'll be submitting your project.

Checklist

• I have read and understood the Code of Conduct.
• I have read and understood the application materials found in this repository.
• I have read and understood the patch 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.