PostulaDo

Stack

Framework

NestJS · Next.js · TypeScript

Datos

Prisma · PostgreSQL · Redis

Análisis

SGLang (XGrammar, RadixAttention) · Cheerio

Dominio

Taxonomía de 8 oficios con alternativas por tema

Colas

BullMQ · Redis

Seguridad

JWT · Passport · guards por rol · ownership checks

Testing

e2e contra PostgreSQL y Redis reales en Docker Compose

Arquitectura

  Lote de URLs
      │
      ▼
  ┌─────────────────────────────────────────────┐
  │ API NestJS                                 │
  │  ─ AuthModule (JWT + Passport + Roles)      │
  │  ─ UsersModule (ownership por recurso)     │
  │  ─ PostulacionesModule (CRUD + lote)        │
  │  ─ AnálisisModule                           │
  │     ├─ BullMQ producer (URL → job)          │
  │     └─ BullMQ worker                        │
  │         ├─ Scraping con Cheerio             │
  │         └─ Extracción estructurada SGLang   │
  │  ─ Taxonomía (8 oficios + alternativas)      │
  └─────────────────────────────────────────────┘
      │                    │
      ▼                    ▼
  PostgreSQL           Redis + BullMQ
     (Prisma)              │
                          ▼
                    Inferencia SGLang

  ┌─────────────────────────────────────────────┐
  │ Frontend Next.js (estático)                 │
  │  encolar → poll → guardar → analizar el lote │
  └─────────────────────────────────────────────┘

Problema

Estudiar sin saber qué se pide es caro. Un profesional junior abre diez ofertas, ve diez listas de herramientas distintas y no sabe si el 10% o el 70% de lo que estudia le va a servir. Lo que hay en el mercado no es difícil de encontrar: está desperdigado en cada posting, y separado no dice nada.

El reto no era resumir una oferta: era comparar un lote entero y sacar de ahí el plan de estudio. Y hacerlo sin mentir —cada porcentaje tiene que poder auditarse contra las ofertas que lo produjeron.

Enfoque

Una API NestJS con arquitectura en capas. La capa de auth resuelve JWT con Passport, guards por rol y un ownership check en cada recurso por usuario: los roles y la propiedad son ejes separados, y un admin no es el dueño de un recurso.

La clave está en una taxonomía: 36 tecnologías mapeadas a 8 oficios —pruebas, integración y entrega, nube, contenedores, datos, caché, backend, frontend— y cada oficio con las alternativas que lo cubren. El plan no dice "aprendé AWS": dice "despliegue en la nube" y ofrece AWS, Azure, GCP y Cloudflare. El denominador es siempre el lote, no el historial entero del usuario: un porcentaje sin el conjunto al que corresponde no significa nada.

Y todo lo que no necesita estar en el camino del request —scraping, extracción, inferencia— va a una cola de BullMQ con Redis. El frontend es una app Next.js estática que encola, espera y consulta el análisis del lote; no hay proxy: habla directo con la API.

Resultado

El usuario pega cinco ofertas y recibe un plan: el tipo de trabajo que comparten, los oficios que las cubren con su cobertura sobre ese lote, y por cuál entrar. No treinta y seis herramientas: los pocos temas que de verdad importan, con alternativas para no quedar atado a un vendor.

El análisis corre en background: el frontend encola, sigue trabajando y consulta el estado hasta que el lote está listo. Y la landing es estática —se publica dentro de este mismo portfolio— así que no necesita servidor propio para existir.

Límites conocidos

La taxonomía es una tabla fija: 36 tecnologías mapeadas a 8 oficios. No descubre oficios nuevos, y una tecnología que no esté en la tabla no entra en ninguna cobertura. Es deliberado —un plan auditable vale más que uno que se inventa— pero es un límite real.

El tipo de trabajo se detecta por la firma de temas, no por un modelo: es heurístico y puede equivocar el nombre del oficio aunque los porcentajes sean correctos.

El scraping sigue siendo texto plano de una URL pública. Sin navegador headless, las ofertas que sólo existen detrás de JavaScript en el cliente no se leen.

Enlaces