Saltar al contenido
Caso · 09 / 09← Todos los trabajos

Trading analytics dashboard

Un panel privado para seguir y controlar mis bots de trading en varias cuentas de bróker.

Rol
Herramienta interna: diseñada y construida para mis propios bots de trading
Stack
Next.js 15, React 19, TypeScript, Recharts, Tailwind CSS 4
Resumen
ResumenExport estático, todos los datos se piden desde el navegador
(01) El problema

Los bots corren solos y operan en varias cuentas de cTrader. Revisarlos era leer logs. Necesitaba equity, P&L diario y estado del bot en una pantalla. También poder pausar un bot sin abrir una terminal.

Mi rolDiseñé y construí el panel como herramienta propia, sobre la API de los bots.
(02) ResultadosContados en el código
4pantallas privadas: resumen, motores, calendario y reporte
6tipos de evento en vivo que llegan por SSE
52llamadas tipadas a endpoints en un único cliente de API
(03) Arquitectura

Tres decisiones que lo definieron.

  1. 01

    Export estático, todos los datos se piden desde el navegador

    Por qué. El panel se publica como archivos, sin un servidor Node que mantener. Cada request lleva la cookie de sesión a la API de los bots.

    El costo. El guard de auth es una redirección en el cliente. La API tiene que validar todo, y cada pantalla arranca con un skeleton.

  2. 02

    Los eventos SSE disparan refetch y el polling queda de respaldo

    Por qué. Un trade cerrado o un snapshot nuevo refresca la tarjeta justa al instante. Un polling de 15 a 60 segundos cubre si se corta el stream.

    El costo. Cada componente que escucha abre su propio EventSource. El resumen mantiene tres a la vez.

  3. 03

    El reporte mensual es una hoja de estilos de impresión

    Por qué. El reporte se renderiza como una página más. Una regla @page A4 apaisada y window.print() lo convierten en PDF.

    El costo. No hay PDF automático. Alguien tiene que abrir la página e imprimirla.

(04) GaleríaSeguí scrolleando →
Resumen
Resumen · Seis KPIs de todas las cuentas y la curva de equity de siete días de la cuenta elegida.
Calendario de P&L
Calendario de P&L · Una grilla mensual sombreada por P&L diario. Tocás un día para ver el detalle, o exportás el mes a CSV.
Motores
Motores · Prendés o apagás cada motor, los recargás y elegís la cuenta de cTrader activa.
Reporte mensual
Reporte mensual · Una página por mes y cuenta, armada para imprimirse en A4 apaisado.
(05) Qué haría después
01Compartir un único EventSource desde un contexto y que cada componente se suscriba a los eventos que necesita.
02Pasar el código manual de fetch, intervalos y flags de montaje a SWR. Ya es dependencia, pero no se usa.
03Darle una ruta a la tabla virtualizada de trades y al detalle de cada trade. Están hechos pero sin enlazar.
Próximo proyecto · 01 / 09
Vimo →Una plataforma SaaS multi-producto donde una cuenta se mueve por todos los productos
Caso · 09 / 09

Trading analytics dashboard

Un panel privado para seguir y controlar mis bots de trading en varias cuentas de bróker.

Rol
Herramienta interna: diseñada y construida para mis propios bots de trading
Stack
Next.js 15, React 19, TypeScript, Recharts, Tailwind CSS 4
Trading analytics dashboard
(01) El problema

Los bots corren solos y operan en varias cuentas de cTrader. Revisarlos era leer logs. Necesitaba equity, P&L diario y estado del bot en una pantalla. También poder pausar un bot sin abrir una terminal.

Mi rolDiseñé y construí el panel como herramienta propia, sobre la API de los bots.
(02) Resultados
4pantallas privadas: resumen, motores, calendario y reporte
6tipos de evento en vivo que llegan por SSE
52llamadas tipadas a endpoints en un único cliente de API
(03) Arquitectura

Tres decisiones que lo definieron.

01

Export estático, todos los datos se piden desde el navegador

Por qué. El panel se publica como archivos, sin un servidor Node que mantener. Cada request lleva la cookie de sesión a la API de los bots.

El costo. El guard de auth es una redirección en el cliente. La API tiene que validar todo, y cada pantalla arranca con un skeleton.

02

Los eventos SSE disparan refetch y el polling queda de respaldo

Por qué. Un trade cerrado o un snapshot nuevo refresca la tarjeta justa al instante. Un polling de 15 a 60 segundos cubre si se corta el stream.

El costo. Cada componente que escucha abre su propio EventSource. El resumen mantiene tres a la vez.

03

El reporte mensual es una hoja de estilos de impresión

Por qué. El reporte se renderiza como una página más. Una regla @page A4 apaisada y window.print() lo convierten en PDF.

El costo. No hay PDF automático. Alguien tiene que abrir la página e imprimirla.

(04) Galería
Resumen
Resumen · Seis KPIs de todas las cuentas y la curva de equity de siete días de la cuenta elegida.
Calendario de P&L
Calendario de P&L · Una grilla mensual sombreada por P&L diario. Tocás un día para ver el detalle, o exportás el mes a CSV.
Motores
Motores · Prendés o apagás cada motor, los recargás y elegís la cuenta de cTrader activa.
Reporte mensual
Reporte mensual · Una página por mes y cuenta, armada para imprimirse en A4 apaisado.
(05) Qué haría después
01Compartir un único EventSource desde un contexto y que cada componente se suscriba a los eventos que necesita.
02Pasar el código manual de fetch, intervalos y flags de montaje a SWR. Ya es dependencia, pero no se usa.
03Darle una ruta a la tabla virtualizada de trades y al detalle de cada trade. Están hechos pero sin enlazar.
Próximo proyectoVimo →
Nahuel SantillánES