Network 3.0

01Contexto

Network nació como el proyecto 4 de CS50W, el curso de desarrollo web de Harvard: una red social pequeña hecha con plantillas de Django y JavaScript sin framework. Mi primera entrega ya iba más allá de lo que pedía el enunciado —comentarios con respuestas, imágenes, borrado y búsqueda—, pero seguía siendo un monolito de curso.

Network 3.0 es una reescritura completa, no un retoque. Borré el monolito y en su lugar hay dos servicios independientes que sólo comparten un contrato HTTP: una API REST en Django y una aplicación de una sola página en React y TypeScript. La versión actual, la 3.1.0, está desplegada en Railway con una demo pública. Fueron un par de semanas de trabajo, en solitario.

02Problema

Lo difícil de una red social pequeña no son las pantallas: es que todo está conectado con todo y todo cambia mientras lo miras. Un like toca el contador de la tarjeta, la pestaña Likes de un perfil y la lista de quién reaccionó, y crea un aviso para otra persona. El feed se mueve mientras alguien lo lee, cada tarjeta necesita cinco datos agregados y cualquier imagen que sube un usuario es, por definición, contenido en el que no se puede confiar.

03Mi función

Lo hice solo: el diseño del producto y de la interfaz, la API, el frontend, las pruebas, los contenedores, la integración continua, el despliegue y la documentación.

04Lo que pedía CS50W y lo que añadí

El enunciado pedía siete cosas: publicar texto, ver todas las publicaciones, un perfil con seguidores y botón de seguir, la página de las personas seguidas, paginación de diez en diez con botones, editar sin recargar y dar like sin recargar.

La versión 3 añade, encima:

• Arquitectura. API REST versionada y aplicación de una sola página, desplegables por separado; JWT con rotación y lista negra en lugar de la sesión; paginación por cursor, y un esquema OpenAPI 3 con Swagger y ReDoc.
• Producto. Reposts y citas, marcadores privados, hashtags con tendencias de la semana, menciones que notifican, notificaciones de ocho tipos, perfiles con portada y pestañas Posts, Media y Likes, sugerencias de a quién seguir, tema claro, oscuro o del sistema, cambio de contraseña y borrado de cuenta.
• Oficio. 132 pruebas automatizadas donde antes no había ninguna, integración continua, imágenes Docker, procesado de imágenes en el servidor y cabeceras de seguridad.

05Restricciones

• Nada obligatorio para desarrollar. Arranca con SQLite y caché en memoria; PostgreSQL y Redis se activan con variables de entorno. Todo lo que usa la caché tiene que funcionar sin ella.
• Sin almacenamiento de objetos garantizado. Los archivos subidos van al disco salvo que se configure un bucket compatible con S3.
• Una sola persona y ningún usuario al que preguntar. Todas las decisiones de producto se tomaron sin datos de uso.

06Cómo lo construí

Primero borré el monolito, en su propio commit; después vinieron el backend, el frontend y, al final, los contenedores. Cuando volví para llevarlo a producción, el orden fue este: primero la integración continua, luego las dependencias con avisos de seguridad y sólo después las funciones nuevas, el rediseño y la documentación.

El backend son cuatro apps de Django separadas por dominio y no por capa técnica: core, users, posts y notifications. En el frontend, TanStack Query gobierna todo lo que vive en el servidor y Zustand sólo lo que es del cliente: la sesión, el tema y los avisos. Cada página se carga por separado.

07Decisiones de arquitectura

• Paginación por cursor en los timelines. Ordenada por fecha e id, con el id como desempate: publicar algo nuevo no desplaza la página siguiente ni repite lo ya leído. Las listas acotadas, como personas o comentarios, siguen por número de página. La página sigue siendo de diez, como pedía CS50W, pero se carga sola al llegar al final.
• Contadores sin JOIN múltiples. Cada tarjeta trae likes, comentarios y reposts como subconsultas independientes, y «¿le di like?», «¿lo reposteé?» y «¿lo guardé?» como EXISTS. La publicación citada recibe las mismas anotaciones.
• JWT con rotación y lista negra. Cada uso del refresh emite uno nuevo e invalida el anterior, y cambiar la contraseña invalida todos los demás. En el cliente, las peticiones que fallan a la vez comparten un solo refresco.
• Repost y cita, un solo modelo. Una restricción única condicional impide repostear dos veces lo mismo sin impedir citarlo varias veces, y la base de datos prohíbe seguirse a uno mismo.
• Las notificaciones, un dominio propio. Una app de Django con sus ocho verbos, sus endpoints y un índice compuesto pensado para las dos consultas que existen: la lista y el contador de no leídas.
• Redis opcional y no crítico. Sólo guarda las tendencias y las sugerencias, con tiempos de espera cortos: si cae, la aplicación se ralentiza, no se rompe. El health-check informa de la caché, pero sólo marca el servicio como caído si falla la base de datos.

08Seguridad e imágenes

• Cada imagen subida se valida con Pillow, se rota según su EXIF, pierde sus metadatos, se reescala según su uso y se reescribe como WebP, con un tope de 40 megapíxeles contra las bombas de descompresión.
• El registro, el acceso y el cambio de contraseña tienen su propio límite: diez peticiones por minuto y por IP.
• En producción, Django pone HSTS, cookies seguras y las cabeceras de seguridad, y nginx pone la política de seguridad de contenidos. La aplicación se niega a arrancar con la clave secreta de desarrollo.

09Desafíos

• Que el feed no se repita al paginar: cursor con desempate por id.
• Que dos reposts simultáneos no rompan nada: la restricción única en la base de datos y el error de integridad capturado.
• Que un token caducado no dispare una tormenta de refrescos: una sola promesa compartida en el cliente HTTP.
• Que el tema no destelle al cargar: un script en index.html aplica el tema antes de que React monte.
• Que los avisos no se dupliquen ni queden huérfanos: se crean una sola vez y se borran cuando se deshace el like, el follow o el repost.
• Que los datos de demostración sean reproducibles: generadores con semilla fija.

10Lo que enseñó el despliegue

El primer despliegue en Railway sacó a la luz lo que el entorno local no podía enseñar: los permisos del volumen de archivos, el directorio personal del usuario sin privilegios del contenedor, una migración que no coincidía con el modelo y la necesidad de sembrar la demo al arrancar. Los cuatro se resolvieron en un pull request propio, y la integración continua comprueba que no falte ninguna migración.

11Diseño y UX

Interfaz propia con Tailwind CSS 4 y la tipografía Inter servida desde el propio sitio, sin peticiones a terceros. Todos los estados están diseñados: los de carga replican la tarjeta real, los vacíos explican qué irá ahí y ofrecen la acción que los llena, y los diálogos destructivos nombran lo que se pierde. El tema oscuro no es un filtro invertido y respeta el del sistema, y en el teléfono la navegación baja a una barra de cuatro destinos.

12Lo que no tiene

Para que nadie lo dé por supuesto: no hay tiempo real —ni WebSockets ni sondeo; los datos se refrescan al volver a pedirlos—, no hay cola de tareas y no hay service worker. El manifiesto hace la web instalable, pero no funciona sin conexión.

13Sobre las capturas

Las capturas salen de una instancia local sembrada con un elenco inventado —diez personas con avatares de iniciales generados por código— e imágenes abstractas generadas con Pillow. Los nombres y las cifras que aparecen, como likes o seguidores, no son métricas de nada. La demo pública usa otras cuentas de ejemplo, así que los nombres no coinciden. Las pantallas con algún defecto visible se dejaron fuera.

14Probar la demo

La demo está en web-production-9475c.up.railway.app. Entra con ada, grace, linus, margaret, alan, katherine, tim o hedy; la contraseña de todas es network123. La pantalla de acceso ofrece cuatro de ellas con un clic, y también puedes crear tu propia cuenta. La documentación de la API está en Swagger.

15Aprendizajes

Reescribir fue más limpio que refactorizar: al borrar primero el monolito, la API se diseñó sin heredar la forma de las plantillas. Y el despliegue enseñó lo que el desarrollo no podía: permisos, usuarios del contenedor y migraciones sólo fallan de verdad en producción.

16Estado actual

Terminado y en funcionamiento en la versión 3.1.0: desplegado de forma permanente en Railway sobre PostgreSQL y Redis, con el repositorio público bajo licencia GPL-3.0, la integración continua en verde y 132 pruebas automatizadas —98 de backend y 34 de frontend— que pasan. No tiene usuarios reales, así que no publico cifras de uso: es un proyecto para demostrar cómo construyo.