API backend
NestJS expone recursos académicos y administrativos. No existe frontend en este repositorio.
SCHOLAR SYNC.
API académica modular con NestJS
Backend para coordinar cursos, comunidad académica, sesiones de apoyo y progresión mediante una API REST con persistencia relacional.
01 / CONTEXTO
Proyecto colaborativo de Computación en Internet III, desarrollado como API backend; el repositorio no incluye una interfaz web.
02 / EL RETO
Modelar en un solo servicio la identidad académica, la matrícula, la interacción entre estudiantes y docentes, y la trazabilidad de sesiones e insignias.
03 / LA SOLUCIÓN
Arquitectura modular en NestJS con controladores, servicios y repositorios TypeORM sobre PostgreSQL, autenticación JWT, validación de DTOs y documentación Swagger.
04 / MI TRABAJO
El repositorio evidencia trabajo colaborativo, pero no documenta qué piezas pertenecen individualmente a Juan Pablo. Por eso este caso presenta el resultado técnico sin reclamar autoría exclusiva.
05 / PUNTOS CLAVE
- 13 entidades y 68 rutas REST
- JWT, roles Admin y validación Professor/TA
- 14 suites unitarias y 7 archivos E2E en el repositorio
TRANSPARENCIA
Implementación backend amplia, con límites reales: no hay frontend; varias rutas de dominio permanecen públicas; Docker Compose solo levanta PostgreSQL; y el workflow de CI actual referencia un package-lock.json ausente.
01 / ESTADO VERIFICADO
Un backend amplio, con fronteras claras.
La lectura del código, la documentación y la automatización permite separar lo implementado de lo que el repositorio todavía no demuestra.
Implementada
13 entidades TypeORM sobre PostgreSQL, con relaciones explícitas para roles, permisos, cursos e insignias.
Parcial
JWT y guards funcionan en administración y respuestas; otros controladores de dominio siguen sin protección.
Histórica
Hay una evidencia visual del endpoint desplegado, pero el README declara el servicio apagado y no se afirma disponibilidad actual.
02 / PROBLEMA + OBJETIVO
Coordinar la vida académica más allá de una lista de cursos.
Scholar Sync reúne identidad, matrícula, conversación académica, tutorías y reconocimiento por participación. El objetivo técnico fue convertir esos flujos relacionados en una API modular, validada y persistente, preparada para distintos perfiles de usuario.
Identidad y acceso
Usuarios, roles, permisos y sus asignaciones explícitas.
Cursos
Catálogo y relación de estudiante, profesor o TA con cada curso.
Comunidad
Posts, respuestas anidadas, likes, validación y experiencia.
Acompañamiento
Sesiones suplementarias, asistencia e insignias por nivel.
03 / ARQUITECTURA
Capas simples, dominios separados.
AppModule compone cinco dominios principales. Cada recurso pasa de controladores y DTOs a servicios y repositorios TypeORM; PostgreSQL conserva el modelo relacional.
Controllers + DTOs
68 rutas REST y ValidationPipe global con whitelist.
NestJS services
Reglas CRUD, relaciones, XP, niveles y asignación de badges.
TypeORM repositories
13 entidades y tablas puente modeladas como entidades propias.
PostgreSQL 16
Configuración local por variables o DATABASE_URL con SSL para cloud.
JWT / Passport autentica tokens; RolesGuard restringe administración y validación Professor/TA. Swagger publica el contrato en /api.
04 / FUNCIONALIDADES
Flujos comprobables en servicios y controladores.
El alcance real combina administración académica, conversación y gamificación; no incluye experiencia de usuario visual ni cliente web.
Autenticación
Registro con hash bcrypt, login JWT y carga de roles/permisos. El logout es stateless: pide descartar el token en el cliente.
Administración
CRUD de usuarios, roles y permisos, más asignaciones usuario–rol y rol–permiso protegidas para Admin.
Interacción
Foro con posts, respuestas anidadas, likes y validación de respuestas reservada a Professor o TA.
Gamificación
Crear posts y respuestas, recibir likes y validaciones suma XP; el nivel puede activar insignias elegibles.
Gestión académica
Cursos, matrículas con tipo de relación, sesiones suplementarias y registros de asistencia.
Contrato API
Swagger, DTOs con class-validator, colección Postman y seed SQL para desarrollo y pruebas.
05 / CALIDAD + ENTREGA
Pruebas presentes; automatización todavía incompleta.
El repositorio contiene una base de pruebas considerable, pero su presencia no equivale a una ejecución exitosa vigente.
suites unitarias
147 casos localizados en servicios con mocks de repositorio.
archivos E2E
86 casos que requieren una PostgreSQL real y datos seed.
workflow de CI
Build y unit tests para main; no ejecuta E2E ni despliega.
Docker Compose levanta únicamente PostgreSQL 16; no existe Dockerfile para la API.
El workflow usa npm ci y busca package-lock.json, pero el repositorio conserva bun.lock: la CI actual necesita alinearse con el gestor de paquetes.
La captura original acredita que el endpoint raíz respondió en Railway; no acredita frontend, salud actual ni un pipeline de CD.
Respuesta del despliegue histórico
Captura original incluida como “Deployment Evidence.jpeg”. Muestra el dominio de Railway y la respuesta Hello World del endpoint raíz; se conserva sin presentarla como interfaz de producto.
06 / RETOS + PENDIENTES
Lo difícil no fue solo modelar; fue cerrar las garantías.
El código cubre el núcleo funcional, pero una lectura de producción exige observar también las brechas entre documentación, autorización y entrega.
Relaciones densas
El sistema conecta usuarios con roles, permisos, cursos, posts, respuestas, sesiones e insignias mediante entidades intermedias y relaciones bidireccionales.
Autorización desigual
Cursos, posts, badges y sesiones no aplican guards aunque el README los describe como autenticados. PermissionsGuard existe, pero ningún controlador lo usa.
Validación de identidad
Varios DTOs aceptan userId desde el body; el backend no siempre vincula la acción con el usuario autenticado, un punto importante antes de producción.
Entrega reproducible
Falta alinear CI y lockfile, incorporar PostgreSQL para E2E y definir una imagen o estrategia explícita de despliegue de la API.
07 / CONTRIBUCIÓN
Atribución limitada por la evidencia disponible.
El README habla de módulos bajo responsabilidad del equipo, pero no nombra responsables individuales. El historial Git disponible tampoco vincula commits con Juan Pablo. Por rigor, el portafolio presenta Scholar Sync como proyecto académico colaborativo y no atribuye a Juan una implementación específica ni la autoría total del backend.
Fuentes: README, package.json, módulos, controladores, servicios, entidades, DTOs, guards, pruebas, inserts.sql, Docker Compose, workflow de GitHub Actions y evidencia de despliegue del repositorio original. No se modificó ni desplegó Scholar Sync.
05 / CONTACTO
DISPONIBLE PARA CONVERSAR
TU IDEA.
NUESTRO SIGUIENTE
PROYECTO.
¿Tienes un producto por construir o buscas a alguien para tu equipo? Conversemos.