Saltar al contenido
Framework Ecosystems LabsUn contrato, muchos ecosistemas, la misma prueba.

Por qué sí y por qué no — Qué hace tu framework con el socket#

⬅️ Clase 025 · 📚 Parte 1

Esta clase no compara frameworks entre sí: compara capas. La pregunta es cuánta pila quieres debajo de tu código.

Capa Por qué sí Por qué no Qué se paga
Sin framework (Node.js) Transparencia total: no hay nada que no hayas escrito Escala mal: veinte rutas son una cascada de if Reescribir en cada proyecto lo que ya existe
Gin Muy poco encima de un servidor que ya trae el lenguaje Aporta poco más que enrutado y utilidades Todo lo demás lo montas tú
Express Envuelve el servidor sin ocultarlo: puedes bajar a Node cuando haga falta Sin opinión sobre nada más Cada proyecto acaba con una combinación distinta
FastAPI La frontera ASGI permite cambiar de servidor sin tocar la aplicación Dos piezas que desplegar y un modelo asíncrono que entender Una pieza más en la operación
Spring Boot Cinco capas que resuelven cinco problemas reales; artefacto de una pieza Arranque más lento y más superficie que entender al depurar Un fallo en una capa que no escribiste exige aprenderla

🧭 Cuándo bajar una capa#

Casi nunca por rendimiento. La diferencia entre Express y Node crudo es despreciable frente a una consulta a base de datos mal hecha. Optimizar ahí es mirar donde no está el problema — el error que la clase 137 desmonta con mediciones.

Sí por comprensión. Escribir una vez el servidor sin framework cambia cómo lees la documentación de cualquier framework: dejas de ver magia y ves capas.

Sí por depuración. Cuando algo falla en una capa intermedia, saber qué hay debajo es la diferencia entre diagnosticar y probar cosas al azar. Es lo que Feathers describe como la ventaja de tener un modelo del sistema antes de tocarlo [feathers-legacy-code].

🎓 Lo que cierra la parte 1#

Las quince clases de esta parte demuestran una tesis del repositorio:

Los diez frameworks implementan el mismo estándar. Sus diferencias están en los valores por omisión, en el reparto entre configuración y código, y en qué te dejan olvidar.

Ninguna de las quince clases necesitó una capacidad que un framework tuviera y otro no. Lo que cambió siempre fue cuánto había que escribir y qué se podía olvidar sin aviso.

Ese es el criterio con el que la parte 11 enseña a elegir: no «cuál puede», sino cuál hace fácil lo correcto para el equipo que va a mantenerlo.

Fuentes#