Aplicaciones web BIM: cuando el modelo sale del escritorio
La petición llegó en una frase: «Necesitamos que el cliente vea el modelo desde el navegador». El equipo preparó un visor y, durante la primera demostración, el cliente pidió filtrar por planta, consultar superficies, comentar elementos y comparar la entrega anterior. En veinte minutos, una página con un modelo 3D se había convertido en una aplicación de colaboración, datos y versiones. El navegador no había cambiado; el problema sí.
Las aplicaciones web BIM pueden visualizar modelos, gestionar incidencias, analizar información o conectar servicios. Elegir o construir una exige saber qué decisión debe apoyar. Un visor muestra geometría; una aplicación controla usuarios, contexto, estados, datos y efectos. Confundirlos produce interfaces espectaculares que dejan el proceso en correos y hojas paralelas.
Tabla de contenidos
El primer alcance cabía en una pregunta
El cliente quería revisar una entrega sin instalar software. Necesitaba abrir un modelo, navegar, aislar disciplinas y consultar algunas propiedades. Esa necesidad podía resolverse con un visor web y un backend que preparase el artefacto.
Los comentarios y aprobaciones añadían identidad, permisos e historia. Comparar versiones exigía conservar referencias y estados. Los informes necesitaban una capa de datos. El equipo separó una primera fase de consulta y una segunda de colaboración.
Esta división evitó diseñar desde el inicio una plataforma universal. También dejó contratos para crecer sin fingir que un marcador dibujado en pantalla era ya un sistema de incidencias.
La arquitectura empezó fuera del canvas
El frontend gestionaba interfaz y sesión. Una API propia aplicaba usuarios, proyectos, permisos y operaciones. Workers preparaban modelos y procesos largos. La base de datos guardaba estados y relaciones.
El visor consumía una representación optimizada, no necesariamente el archivo nativo completo. El backend controlaba tokens y acceso. Los secretos no viajaban al navegador.
Esta separación permitía cambiar de tecnología de visualización sin perder incidencias ni membresías. El modelo de negocio no dependía de la forma exacta en que se dibujaba una viga.
El formato siguió al uso
Para un flujo abierto, IFC podía transportar objetos, propiedades y relaciones. En otros ecosistemas se utilizaban formatos derivados o APIs específicas para visualización. El equipo evaluó fidelidad, propiedades, tamaño y compatibilidad.
Un archivo válido para intercambio no siempre era óptimo para renderizado directo. Podía procesarse en servidor y generar teselas, geometría y un índice de propiedades. La aplicación conservaba relación con la versión original.
El procesamiento no convertía datos incorrectos en correctos. La plataforma distinguía «listo para visualizar» de «validado para el uso».
El navegador recibió solo lo que podía manejar
Los modelos grandes exigían carga progresiva, compresión, niveles de detalle y límites de memoria. El equipo midió tiempo hasta primera vista útil, no solo descarga completa.
Las propiedades se consultaban bajo demanda o mediante índices. Enviar cada parámetro de cada elemento al iniciar habría castigado red y dispositivo. Los filtros frecuentes podían precomputarse.
Se probaron portátiles normales y redes de obra. Una demo en el ordenador del desarrollador no representaba el entorno. La GPU también tiene derecho a expresar desacuerdo.
Las versiones dejaron de ser archivos con fecha
Cada publicación creaba una versión vinculada con su fuente y estado de procesamiento. La interfaz mostraba cuál estaba abierta. Los comentarios y vistas se asociaban a esa versión.
Al comparar, el sistema necesitaba correspondencia entre objetos. IDs internos de un visor podían cambiar. Se utilizaron identificadores estables cuando existían y se marcaron casos ambiguos.
La versión anterior no se sobrescribía. Un informe histórico debía poder reconstruirse. «Último modelo» era una acción de navegación, no una clave de base de datos.
La consulta de datos tuvo su propio contrato
El cliente quería superficies por uso. La aplicación no sumaba cualquier propiedad llamada Área. Definió entidades, unidades, fases y clasificación. El backend procesaba resultados reproducibles.
Los filtros visibles compartían ese esquema. Una etiqueta de interfaz se relacionaba con un campo conocido. Las propiedades desconocidas no aparecían por casualidad tras una actualización.
Para análisis complejos, se extraían datos a un almacén adecuado. Recorrer el visor como si fuese una base analítica funcionaba en pequeño y envejecía rápido.
Las incidencias añadieron un ciclo de vida
Crear un comentario requería modelo, versión, objetos, cámara, descripción y responsable. Los estados y permisos se definieron. Una captura ayudaba, pero no era el único contexto.
El cierre se verificaba sobre una versión posterior. Las referencias que no sobrevivían se resolvían o marcaban. Los duplicados se agrupaban con criterio.
Las notificaciones seguían acciones, no cada cambio. La aplicación web debía reducir persecución, no trasladarla al correo con un diseño más reciente.
BCF aportó interoperabilidad cuando el flujo lo soportaba
Para compartir incidencias entre herramientas BIM, BCF podía transportar vistas, comentarios y referencias. El equipo probó importación y exportación reales.
No asumió que todos los identificadores y cámaras sobreviviesen igual. Se conservaron fallbacks y se documentaron límites. Un estándar ayuda a intercambiar; las aplicaciones todavía deben interpretar.
Cuando el proceso era interno y necesitaba campos adicionales, la aplicación mantenía su modelo y ofrecía BCF como frontera. No forzó toda la lógica dentro del formato.
La seguridad se diseñó por proyecto y acción
Los usuarios pertenecían a organizaciones y proyectos. Los roles controlaban consultar, comentar, publicar y administrar. Cada llamada verificaba acceso en servidor.
Las URLs temporales y tokens se acotaban. Los modelos no quedaban públicos por conocer una ruta. Los logs no almacenaban secretos ni propiedades sensibles sin necesidad.
También se consideraron residencia, retención y borrado. Una aplicación web distribuye acceso con facilidad; por eso necesita saber a quién, desde dónde y durante cuánto tiempo.
La colaboración offline tuvo límites honestos
En obra, la conexión podía ser mala. Algunas vistas y datos podían cachearse, pero editar incidencias offline introducía sincronización y conflictos.
El equipo permitió consulta parcial y cola de borradores con estado visible. No prometió el mismo comportamiento que online. Al reconectar, los cambios se validaban.
Los modelos completos no se descargaban indiscriminadamente a dispositivos. La estrategia equilibraba uso, seguridad y almacenamiento.
Las APIs convirtieron la aplicación en una pieza del ecosistema
El portal recibía versiones, enviaba incidencias y alimentaba informes. Cada integración tenía contrato, scopes, idempotencia y errores. Los procesos largos utilizaban jobs.
Los webhooks avisaban de cambios; la API confirmaba; la reconciliación reparaba. El frontend no coordinaba sistemas externos directamente.
La aplicación publicaba una API solo donde había un caso. Abrir todos los datos «por si acaso» aumentaba superficie y soporte.
Open source y producto comercial se compararon por operación
Una base abierta podía ofrecer control, extensibilidad y menor dependencia de un proveedor. También exigía construir distribución, seguridad, procesamiento y soporte. Una plataforma comercial podía acelerar capacidades y añadir costes y límites.
El equipo comparó formatos, APIs, hosting, comunidad, roadmap y capacidad interna. No utilizó precio de licencia como coste total.
La elección podía ser híbrida. Un visor abierto con backend propio o servicios gestionados en tareas concretas. La arquitectura seguía responsabilidades y riesgo.
Las pruebas cruzaron interfaz y modelo
Se probaron permisos, versiones, modelos grandes, propiedades ausentes, objetos eliminados y dispositivos distintos. Las capturas visuales ayudaban a detectar regresiones del visor.
Los contratos de API, la base real y los workers se validaban en integración. Un modelo conocido permitía comprobar recuentos y filtros. Los fallos de procesamiento no se ocultaban.
La accesibilidad también formó parte. Navegar un 3D no podía ser la única forma de consultar estado. Tablas, búsqueda y teclado ofrecían rutas alternativas.
La observabilidad siguió el trabajo del usuario
Las métricas incluían procesamiento, carga, errores, búsquedas e incidencias, con privacidad. Se medía si un usuario podía abrir una entrega y completar una revisión.
Los logs correlacionaban versión, job y petición. Un fallo mostraba si estaba en carga, derivado, permiso o cliente. La frase «el modelo no abre» empezó a tener apellidos.
Las alertas vigilaban colas, tiempos y servicios externos. El mantenimiento era parte del producto, no una tarea posterior a la demo.
Cuándo un visor sencillo es suficiente
Si el objetivo es enseñar un modelo ocasional y no hay colaboración ni datos sensibles, una solución embebida puede bastar. Construir usuarios, jobs y auditoría sería excesivo.
Si el proceso necesita edición nativa intensiva, el navegador quizá no reemplace la herramienta de autor. Puede complementar revisión y acceso.
También conviene no construir cuando una plataforma existente cubre requisitos y el equipo no tiene capacidad operativa. La diferenciación debe justificar el mantenimiento.
El modelo salió del escritorio y entró en un proceso
La primera versión permitió revisar sin instalar. La siguiente añadió incidencias y datos con contratos claros. El cliente sabía qué versión veía y qué podía hacer.
Diseñar aplicaciones web BIM exige separar visor, datos y colaboración. Elige formatos, procesa modelos, controla permisos y mide rendimiento en dispositivos reales. Después integra solo los flujos necesarios.
Si una petición dice «solo queremos verlo en web», anótala con cariño. Puede ser cierta. También puede ser el primer requisito de una plataforma completa vestido con una frase muy pequeña.
Respuestas