Dashboard que Visualiza tu Actividad en GitHub
Un desarrollador argentino armó un dashboard interactivo en JavaScript vanilla que lee tu perfil de GitHub y te devuelve visualizaciones de commits, lenguajes usados y contribuciones en un heatmap estilo GitHub nativo. El proyecto, publicado en dev.to el 10 de abril de 2026, usa la API REST de GitHub directamente desde el navegador y ya recibe pedidos de contribuciones de otros desarrolladores que quieren mejorar el UI y optimizar el rendimiento.
En 30 segundos
- Un dashboard visualizador de actividad GitHub creado con HTML, CSS y JavaScript vanilla que muestra datos reales de tu perfil directamente desde la API de GitHub.
- Funciones principales: tarjeta de perfil (avatar, bio, followers), repos con estrellas y forks, gráfico de commits a lo largo del tiempo, heatmap interactivo y estadísticas de lenguajes usados.
- Usa Chart.js para gráficos y la API REST de GitHub (5000 requests/hora con token personal); sin dependencias pesadas.
- Retos resueltos: manejo de edge cases (repos vacíos), procesamiento de datos de eventos, diseño responsive, visualización de datos significativa.
- Existen alternativas como GitHub Wrapped, Grafana GitHub Data Source, Sourcerer y GitHeat, pero este proyecto prioriza simplicidad y entendimiento de cómo funciona la API.
Qué es un visualizador de actividad GitHub
Un dashboard visualizador de actividad GitHub es una aplicación web que toma los datos públicos de tu perfil de GitHub —commits, repos, lenguajes, contribuciones— y los transforma en gráficos, tablas e heatmaps interactivos para que entiendas tu patrón de desarrollo de un vistazo.
Ponele que subís a tu perfil de GitHub y ves tus repos listados, tus followers y poco más. Ahora imaginá poder hacer click en tu usuario y obtener un resumen visual: acá están tus commits por mes, acá los lenguajes que más usás, acá un mapa de calor de cuándo trabajás. Eso es lo que propone este proyecto.
Diferencia con GitHub Pulse o las vistas nativas de GitHub: esas se enfocan en actividad de un repo en particular. Este dashboard mira tu perfil completo, toda tu actividad como desarrollador, y la presenta en un formato que es casi una tarjeta de presentación técnica.
Características principales del proyecto
El proyecto que publieron en dev.to el 10 de abril incluye varios componentes visuales claros:
Tarjeta de perfil limpia. Avatar, bio, y contador de followers. Es lo primero que ves. El diseño es minimalista (y correcto), sin ruido visual.
Sección de repositorios. Lista tus repos con indicador de si es fork o no, count de estrellas, count de forks. Ojo: para repos sin stars ni forks, la vista no se quiebra. Eso es importante.
Visualización de lenguajes. Un gráfico muestra qué lenguajes usaste, cuánto código en cada uno. No es solo conteo de repos, es análisis real de los bytes de código en cada lenguaje (si GitHub lo permite via API). Complementá con ejecución local sin APIs externas.
Gráfico de commits a lo largo del tiempo. Timeline que muestra tu actividad commit-by-commit o agregada por período. Si usaste Chart.js, probablemente un line chart o bar chart que responde a mouseover.
Heatmap estilo GitHub. Lo que más enganchador: una grilla de 52 columnas (semanas) × 7 filas (días de la semana), donde cada celda es un cuadradito coloreado según cuántos commits tuviste ese día. El mismo formato que ve GitHub nativamente en tu perfil.
Tecnologías y APIs utilizadas
Acá viene lo que hace que este proyecto sea valioso para quien quiera aprender: es vanilla. Sin frameworks, sin bundlers, sin configuración.
HTML, CSS, JavaScript puro. Chart.js para los gráficos. La API REST de GitHub como fuente de datos.
¿Por qué REST y no GraphQL? Probablemente porque REST es más simple para un proyecto inicial, no requiere aprender la sintaxis GraphQL (que tiene su curva), y para los datos que necesita —repos, commits, lenguajes— REST alcanza sin problemas.
Limitaciones conocidas: sin token personal, GitHub te permite 60 requests por hora. Con token, 5000. Para un dashboard interactivo donde el usuario entra su username y todo se carga, un token es casi mandatorio. El proyecto probablemente espera que el usuario suministre su propio token (o usa un servidor backend que maneja el token, pero eso sería more complex).
Retos principales al construir un visualizador
El desarrollador fue honesto en el post: mencionó qué lo complicó. Eso es buena señal.
Manejo de edge cases. ¿Qué pasa si un usuario tiene repos totalmente vacíos (sin commits, sin lenguaje detectado)? ¿Qué si no tiene followers? ¿Qué si tiene 10 repos pero hizo todos los commits en un solo día hace dos años? El código tiene que no morir silenciosamente. Charts vacíos necesitan un mensaje honesto (“no hay datos”), no un error 500. Te puede servir nuestra cobertura de consideraciones de privacidad en GitHub.
Procesamiento de datos de eventos. GitHub expone eventos pero no todos los datos que querés están en un único endpoint. Tenés que hacer multiples llamadas a la API: primero usuarios, luego repos, luego lenguajes (que vienen en un endpoint separado), luego eventos para commits. Sincronizar todo eso sin que se dispare la latencia es un arte.
Diseño responsive y UI limpia. El heatmap ve bárbaro en desktop (52 semanas × 7 días caben bien en ancho). ¿Y en móvil? ¿Lo scrolleás horizontal? ¿Lo comprimes? Las opciones no son bonitas. El equipo eligió qué sacrificar.
Hacer que la visualización sea significativa. Un gráfico sin contexto es ruido. Un gráfico con etiquetas, colores coherentes, y hover-info que te diga “15 commits ese día” es útil. La diferencia está en los detalles.
Herramientas alternativas y comparación
No es el único proyecto que visualiza GitHub. Acá hay varias opciones que circulan:
| Herramienta | Tipo | Costo | Mejor para | Requisitos |
|---|---|---|---|---|
| GitHub Activity Visualizer | Web app | Gratis | Aprender cómo funciona la API de GitHub | Token personal (opcional con límite) |
| GitHub Wrapped 2025 | Web app | Gratis | Estadísticas anuales estilo “Spotify Wrapped” | OAuth con GitHub |
| Grafana GitHub Data Source | Plugin | Gratis (Grafana base) | Monitoreo de repos en equipo | Grafana instance + GitHub token |
| GitHeat | CLI + web | Gratis (open source) | Heatmap detallado tipo GitHub nativo | Node.js + token |
| Sourcerer | Web app | Freemium | Perfil visual 3D isometric de tu código | OAuth |
| Cal-Heatmap | Librería JS | Gratis | Heatmaps customizables en tu propio sitio | Datos propios |
Cada una tiene un ángulo diferente. El proyecto del artículo está en el punto medio: no es tan simple como Wrapped (que te muestra un resumen bonito pero genérico), ni tan complejo como Grafana (que requiere setup). Es educativo.
Cómo usar la API de GitHub en JavaScript
Si querés replicar lo que hizo este proyecto, los endpoints principales son:
/users/{username} — devuelve bio, followers, avatar, link al perfil. Una sola llamada y tenés casi todo para la tarjeta de perfil.
/users/{username}/repos — lista todos los repos públicos del usuario. Respuesta paginada (30 por página por defecto), así que si el usuario tiene 200 repos, necesitás 7 requests. Esto se conecta con lo que analizamos en herramientas de IA para análisis.
/repos/{owner}/{repo}/languages — desglose de lenguajes en ese repo como porcentaje. Esta es cara (1 request por repo) si un usuario tiene muchos repos.
/users/{username}/events/public — eventos públicos (commits, PRs, issues). Limitado a los últimos 90 días y máximo 300 eventos, pero es ahí donde sacás la data de commits para el heatmap.
Autenticación: Sin token, 60 requests/hora desde una IP. Con token personal (que generás en GitHub settings), 5000/hora. El token es un string, lo pasás en el header Authorization: token TU_TOKEN. NUNCA commitees el token al repo (usa .env o variables de entorno).
Rate limits: GitHub devuelve headers X-RateLimit-Remaining y X-RateLimit-Reset. Si golpeás el límite, recibís 403. El proyecto probablemente chequea estos headers y avisa al usuario “esperá X minutos para refrescar”.
REST vs GraphQL: GraphQL es más eficiente (una query en vez de multiples endpoints), pero REST es más directo si no necesitás datos hyper-específicos. Para este proyecto, REST fue la opción pragmática.
Errores comunes al trabajar con la API de GitHub
Ignorar los rate limits. Un desarrollador hace un loop que llama la API para cada repo del usuario sin chequear cuántas llamadas lleva. Resultado: 403 a mitad del proceso. La solución es mantener un contador y frenar si te acercas al límite.
Asumir que todos los datos existen. Un repo puede no tener lenguaje detectado (si es 100% YAML o configuración). El endpoint /languages devuelve un objeto vacío `{}`. Si tu código hace `Object.keys(languages)` sin chequear, explota. Siempre validá que los datos existan antes de usarlos. Cubrimos ese tema en detalle en plataformas alternativas a GitHub.
No parsear fechas correctamente. GitHub devuelve timestamps en ISO 8601 (ej: “2026-04-10T14:32:15Z”). Si no los parseás y los tratas como strings, tus gráficos de timeline quedan desordenados o vacíos. Convertí a Date objects, ordená, luego formatea para presentar.
Cargar la página completa en un viaje. Si haces 200 requests de forma síncrona uno tras otro, la página se queda cargando 30 segundos. Usá Promise.all() o async/await con paralelo: `await Promise.all([…URLs])`. Mucho más rápido.
Preguntas Frecuentes
¿Puedo ver el código del proyecto y contribuir?
Sí. El desarrollador abrió el proyecto (probablemente en GitHub bajo un username tipo “your-username/github-activity-visualizer”) y explícitamente pidió contribuciones. Podés reportar issues, mejorar el UI, optimizar el JavaScript, o agregar features como dark mode, filtros por fecha, o exportar datos. No es un proyecto cerrado.
¿Necesito un servidor backend o funciona 100% en el navegador?
Funciona 100% en el navegador. JavaScript puro consultando la API pública de GitHub. Si querés esconder el token (para no exponerlo en el cliente), necesitarías un backend que haga de proxy. Pero para un proyecto personal o portfolio, el setup vanilla es más que suficiente.
¿Cómo genero un token personal de GitHub para usarlo?
Entrá a GitHub Settings → Developer settings → Personal access tokens → Tokens (classic). Generá uno nuevo con permisos `read:user` y `public_repo`. Copiá el token, metelo en una variable de entorno (no en el código), y usalo en el header de las requests. Tratalo como una contraseña: nunca lo compartás ni lo commitees.
¿Funciona con repositorios privados o solo públicos?
Solo públicos, a menos que el token tenga permisos de acceso a privados (que sería tu propio token). El proyecto actual visualiza datos públicos, así que funciona para cualquier usuario de GitHub sin necesidad de autenticación de ellos. Si querés privados, necesitarías que el usuario autentique con su propio token.
¿Puedo usar este dashboard en mi sitio web o portfolio?
Completamente. Cloná el repo, adaptá el CSS a tu branding, metelo en tu portfolio. Incluso podés hostear una versión pública donde otros usuarios entren su username y vean su dashboard (aunque ahí sí necesitarías un backend que maneje tokens o un proxy para no exponer API keys).
Conclusión
Este proyecto es más valioso por lo que enseña que por lo que hace. No es la herramienta de visualización de GitHub más pulida (eso sería GitHub Wrapped o Grafana). Pero es código que podés leer, entender cómo maneja la API, y mejorar. Es exactamente lo que un junior o mid-level debería estudiar antes de meterse en integraciones más complejas.
Para empresas o equipos que quieren un dashboard visualizador de actividad GitHub para presentación interna, esto sirve como punto de partida. Para un desarrollador individual que quiere mostrar una estadística visual de su perfil, puede ser la herramienta definitiva (especialmente si la deployás en Vercel o Netlify en 5 minutos).
Lo que cambió acá en 2026: la API de GitHub sigue siendo gratis, los límites siguen siendo generosos con token, y la comunidad sigue armando herramientas sobre ella. Este proyecto se suma a ese ecosistema con una propuesta clara: aprende cómo funciona la API armando algo útil.
