El framework que elige por ti
Un framework te ahorra decisiones. El problema es que también las toma por ti: dónde se despliega, qué base de datos conviene, quién te aloja. Cómo reconocer el bloqueo antes de firmarlo y qué pedirle a una herramienta para seguir siendo dueño de tu proyecto.
Hace unos años, migrar un proyecto de un framework a otro costaba reescribir código. Hoy cuesta reescribir código y cambiar de proveedor de hosting, de base de datos, de sistema de caché y, a veces, de forma de pensar. El framework ya no es una biblioteca: es una plataforma, y las plataformas tienen dueño.
No es una conspiración. Es un incentivo. Cuando la empresa que mantiene el framework también vende el hosting que mejor lo ejecuta, cada decisión de diseño tiene un empujón suave hacia su producto. El empujón es pequeño, razonable, bien documentado — y acumulativo.
Las cuatro puertas que se cierran solas
Las he visto cerrarse en proyectos reales, y casi nunca de golpe.
El despliegue. La ruta "recomendada" funciona de maravilla. La ruta de "despliégalo tú mismo" existe, pero con un asterisco: algunas funciones rinden peor, otras requieren una configuración que nadie documentó, y la respuesta en el foro es "¿por qué no usas nuestro servicio?". Al cabo de un año, salir de ahí es un proyecto en sí.
Los datos. Las integraciones "nativas" con una base de datos concreta, la caché que solo funciona con un proveedor, el almacenamiento de archivos con una API propia. Cada una te ahorra una tarde. Cada una es un cable más atado al mismo poste.
El modelo mental. Esta es la más sutil. Un framework te enseña a pensar el servidor de una manera — funciones que viven lo que dura una petición, sin estado, sin conexiones abiertas, sin trabajos largos — porque eso es lo que su infraestructura sabe ejecutar barato. Y cuando necesitas una conexión abierta, un proceso que vive horas, una tarea pesada, descubres que el framework no tiene una palabra para eso. No es que sea difícil: es que no está en el vocabulario.
El ritmo. Las versiones mayores llegan más o menos cada año, a veces antes. Cada una mueve una API "por tu bien". Si tu proyecto no sigue el ritmo, se queda en una versión sin soporte; si lo sigue, paga con horas. El framework ha decidido cuánto de tu tiempo le pertenece.
Cómo reconocerlo antes de firmarlo
Hay preguntas que hago ahora antes de adoptar cualquier herramienta de servidor, y la respuesta honesta suele llegar en cinco minutos leyendo la documentación.
- ¿Puedo ejecutarlo en una máquina cualquiera con un comando? No "en un contenedor con doce variables de entorno": un binario, un puerto, ya está. Si la respuesta implica la palabra edge o el nombre de un proveedor, la puerta ya está medio cerrada.
- ¿Dónde vive el estado? Si el framework asume que no tienes ninguno — que cada petición nace y muere sola — te está diciendo qué clase de producto puedes construir.
- ¿Qué pasa con una conexión que dura una hora? Un websocket, un stream de eventos, una exportación larga. Si la respuesta es "usa un servicio externo", ya sabes quién la vende.
- ¿Quién pierde si me voy? Si la empresa detrás del framework pierde un cliente de hosting cuando migras, su incentivo y el tuyo no están alineados, por muy buena que sea la herramienta.
Lo que pido ahora
No pido "sin framework". Escribirlo todo a mano es otra forma de quedarse atrapado, en este caso con uno mismo. Pido otra cosa: que la herramienta sea pequeña donde importa y aburrida donde puede.
Pequeña en el contrato: un servidor que es un proceso normal, escucha en un puerto normal, se despliega con systemd o con Docker o copiando un archivo, y funciona igual en mi portátil, en un VPS de ocho euros y en la nube grande. Aburrida en la infraestructura: una base de datos que elijo yo, una caché que es un directorio, conexiones abiertas que son simplemente conexiones abiertas.
Y una prueba concreta que hago antes de comprometerme: despliego la aplicación de ejemplo en el servidor más tonto que tengo a mano, sin leer la guía del proveedor recomendado. Si funciona en veinte minutos, la herramienta es mía. Si no, soy yo quien es de la herramienta.
La mejor infraestructura es la que puedes dejar. Lo aprendí tarde, y cada vez que una migración me costó un trimestre fue porque alguien — a veces yo — había firmado sin leer la letra pequeña que nadie escribió.