Construí un diff de Git en navegador: los desafíos ocultos 🤯
Imaginen un Git diff que funcione directo en su navegador, sin servidor ni instalación. Es lo que busqué al crear 'Duff' para optimizar mi flujo con agentes de IA. Pero la ruta estuvo llena de sorpresas técnicas que poco
Artículo
Una lectura sobre tecnología y sistemas digitales, escrita para ir al punto y dejar claras las ideas principales.
Tema principal
desarrollo web
Fuente
dev.to
Puntos clave
- Imaginen un Git diff que funcione directo en su navegador, sin servidor ni instalación. Es lo que busqué al crear 'Duff' para optimizar mi flujo con agentes de IA. Pero la ruta estuvo llena de sorpresas técnicas que poco
- Con la explosión de agentes de codificación, revisar cambios en múltiples repositorios a la vez se volvió un cuello de botella brutal. Saltaba entre terminales, configuraciones complejas... Necesitaba agilidad, ver 'qué
- La clave residió en combinar dos APIs potentes pero complejas: `File System Access API` para acceso local y `isomorphic-git` para la lógica de Git en el browser. Su integración es una mina de oro, pero no sin sus trampas
- `instanceof` vs `kind`: Las handles de `File System Access API` pueden engañar en tests. `handle.kind === 'file'` es más robusto que `instanceof` para evitar roturas en mocks.
Bloque 1
Imaginen un Git diff que funcione directo en su navegador, sin servidor ni instalación. Es lo que busqué al crear 'Duff' para optimizar mi flujo con agentes de IA. Pero la ruta estuvo llena de sorpresas técnicas que pocos mencionan.
Con la explosión de agentes de codificación, revisar cambios en múltiples repositorios a la vez se volvió un cuello de botella brutal. Saltaba entre terminales, configuraciones complejas... Necesitaba agilidad, ver 'qué cambió dónde' al instante, sin fricción.
Bloque 2
La clave residió en combinar dos APIs potentes pero complejas: `File System Access API` para acceso local y `isomorphic-git` para la lógica de Git en el browser. Su integración es una mina de oro, pero no sin sus trampas:
• `instanceof` vs `kind`: Las handles de `File System Access API` pueden engañar en tests. `handle.kind === 'file'` es más robusto que `instanceof` para evitar roturas en mocks.
Bloque 3
• Operaciones "read-only" que escriben: `isomorphic-git` escribe en `.git/index` incluso para un simple `git status`. Esto forzó a mi adaptador a soportar escritura (`createWritable`) donde esperaba solo lectura. ¡Sorpresa!
• Rendimiento 100x más lento: La seguridad del navegador hace que cada lectura por `FSA API` sea lentísima. Tuve que implementar una cascada de cachés (resolución de refs, objetos de isomorphic-git, instancias del adapter, guardas de React) para que fuera usable.
Bloque 4
• Persistencia con permisos: Guardar `FileSystemDirectoryHandle` en `IndexedDB` funciona, pero al recargar la página se revoca el permiso. Toca pedir `requestPermission()` de nuevo, lo cual impacta la UX.
Este viaje demuestra que llevar funcionalidades complejas a la web es posible, pero exige un profundo entendimiento de los motores subyacentes y un dominio de estrategias de optimización no convencionales. La web se expande, y con ella, nuestros desafíos.
Bloque 5
¿Qué otros usos disruptivos le ven a la `File System Access API` en desarrollo, y cómo abordarían sus limitaciones de rendimiento/permisos?