Movimiento 0deps: Dependencias locales y contratos inmutables
Los desarrolladores de software suelen instalar cientos de librerías externas. Los frameworks modernos dependen de miles de dependencias transitivas. Esto significa que tu aplicación ejecuta código de desconocidos.
Esto crea un riesgo en la cadena de suministro de software.
Cada dependencia aumenta tu superficie de ataque. Puede:
- Introducir fallos de seguridad.
- Convertirse en un objetivo para ataques de la cadena de suministro.
- Ser abandonada por sus mantenedores.
- Cambiar su API pública.
- Romper la compatibilidad con versiones anteriores.
El movimiento 0deps plantea una pregunta sencilla: ¿Qué pasaría si tu aplicación solo dependiera de código que tú controlas?
En el modelo 0deps, integras las dependencias necesarias directamente en el repositorio de tu proyecto. Dejas de descargarlas dinámicamente durante las compilaciones. Todo lo necesario para ejecutar la aplicación permanece en el repositorio desde el principio.
Este enfoque proporciona:
- Compilaciones reproducibles.
- Menor dependencia de registros externos.
- Auditorías de seguridad centralizadas.
- Mayor previsibilidad.
El principio fundamental no es mantener el código estático. Las implementaciones y los algoritmos deben evolucionar para corregir errores y mejorar la seguridad. Lo que permanece estable es el contrato público.
Cada librería expone una interfaz cuidadosamente diseñada. Algunos ejemplos incluyen:
- authenticate()
- createSession()
- verifyPasskey()
Estas funciones definen un contrato. El contrato nunca cambia. Puedes reescribir el código que hay detrás o sustituir la librería por completo. El resto de tu aplicación no notará el cambio.
Cuando aparece una vulnerabilidad, normalmente te enfrentas a dos problemas:
- Corregir el fallo.
- Comprobar si la actualización rompe tu aplicación.
En una arquitectura 0deps, el segundo problema desaparece. Actualizas la implementación interna mientras la API pública permanece igual. Tu aplicación sigue funcionando sin cambios en el código.
Aislas las integraciones externas utilizando un adaptador interno: Aplicación -> Interfaz pública -> Adaptador -> Implementación
Si una librería desaparece mañana, solo tienes que cambiar el adaptador. Ninguna otra parte de tu aplicación se romperá.
0deps no hace que el software sea perfecto. Reduce los riesgos de la cadena de suministro. Previene problemas como paquetes maliciosos, compromisos de registros y confusión de dependencias.
Los proyectos duran décadas. Las librerías y los frameworks cambian. Con 0deps, tu aplicación sigue utilizando los mismos contratos estables, independientemente de cómo evolucione el ecosistema.