Buenas prácticas
Esta sección aborda las directrices fundamentales para el uso, modelado y manipulación de datos en Studio alineados con los pilares especificados.
La aplicación de las mejores prácticas permite una gestión de tokens más clara, consistente y eficiente en toda la solución. Estas recomendaciones buscan minimizar los errores, facilitar el mantenimiento y mejorar la interoperabilidad para promover una construcción consistente en todos los proyectos.
Las mejores prácticas generales reúnen recomendaciones transversales para el uso de tokens en Studio que tienen un impacto directo en la claridad y organización de los tokens al crear una aplicación. El objetivo es evitar errores comunes, promover una estructura coherente y facilitar el mantenimiento.
Consideraciones
Utiliza la funcionalidad alias para tokens globales (ID < 1000), siguiendo las mejores prácticas de nomenclatura de las variables. Actualmente, junto con la creación del ambiente, se especifican varios tokens reservados.
Importante
Los alias se declaran a nivel ambiente y afectan a todas las entidades que los utilizan (apps y módulos).
Utilice los tokens reservados solo para su propósito previsto. Los tokens reservados tienen un comportamiento específico dentro de la plataforma. Usarlos para otros fines puede resultar en un comportamiento inesperado o errores que son difíciles de rastrear.
Para representar estructuras con múltiples atributos (como una cuenta, dirección, usuario, etc.), se recomienda utilizar arrays, asignando cada atributo a una columna. Este enfoque simula el comportamiento de una estructura de datos, favorece el desacoplamiento entre entidades, y permite ampliar la información sin romper contratos, simplemente añadiendo nuevas columnas.
La correcta segmentación y administración de tokens en Studio es clave para garantizar el orden, la consistencia y la escalabilidad de las aplicaciones.
La estrategia propuesta en esta sección permite anticipar los conflictos, facilitar el mantenimiento, asegurar la coherencia entre los proyectos y alinear el modelo de datos con iniciativas intersectoriales como procesos lambda front-end y estados.
Consideraciones antes de usar tokens:
Determina a qué segmento pertenece, dependiendo del tipo de información que manejará.
Comprueba que el token no está en uso por:
Comprobación del Excel de la documentación de tokens.
En caso de tokens globales, comprobando la funcionalidad de alias.
En entornos activos, usando la opción Used In. Ten en cuenta que para los tokens globales, se busca en todas las aplicaciones y módulos, tanto por alias como por ID numérico.
Actualizar la documentación, registrando el nuevo token en el archivo Excel correspondiente.
Importante
Los tokens que se pueden reutilizar en pantallas y flujos (por ejemplo, tokens de presentación o de procesos lambda inline) deben limpiarse después de su uso para evitar interferencias o comportamientos no deseados.
El volumen y la manera en que se manipulan los datos pueden afectar significativamente el rendimiento de la aplicación. Encuentra una lista de recomendaciones a continuación:
Evita arrays grandes: Se recomienda evitar el uso de arrays con un gran número de filas o columnas en el canal. Aunque no existe un límite técnico exacto, como buena práctica no se deben manipular arrays con más de 150 filas o más de 15 columnas , ya puede afectar negativamente a la carga de pantalla y a la experiencia del usuario.
Paginación de la transacción: Las transacciones que devuelven arrays deben diseñarse para admitir paginación, permitiendo limitar el número de registros devueltos.
Evita cálculos pesados o filtrado en el canal: Las operaciones tales como filtrado y clasificación deben realizarse preferiblemente en el backend (transacción).
Inicializa los tokens necesarios: Se recomienda inicializar solo los tokens necesarios en cada contexto. La carga de tokens innecesarios desde el inicio puede ralentizar la renderización de pantalla o la ejecución lógica.
Limpia tokens no utilizados: Limpia los tokens que ya no se utilizan, especialmente si contienen datos grandes como documentos, imágenes o arrays grandes. Mantener estos tokens en memoria puede afectar el rendimiento general de la aplicación.
Si bien existe un documento dedicado exclusivamente a las directrices de seguridad, es importante destacar algunas consideraciones generales que deben tenerse en cuenta al manejar datos dentro de la plataforma.
Se recomienda evitar el almacenamiento de datos confidenciales o sujetos a regulación, ya sea internacional, nacional o por las políticas del cliente, en el dispositivo o host (tokens persistentes, caché, bases de datos, etc.). Esto incluye, pero no se limita a:
información de identificación personal (PII);
datos financieros;
credenciales;
tokens de autenticación; y/o
cualquier dato protegido por acuerdos de confidencialidad.
En los casos en que sea estrictamente necesario conservar este tipo de información, se debe aplicar el cifrado adecuado, y también se deben evaluar el tiempo de retención y los mecanismos de acceso.
Cuando una entidad (como un módulo o una transacción) expone una interfaz, se establece un contrato compuesto por tokens de entrada y salida. Estos contratos determinan cómo pueden interactuar otras entidades (como procesos y pantallas Lambda).
Es esencial que estos contratos sean claros, estables y declarativos. El mal diseño, por ejemplo, el uso de un único token con un objeto JSON anidado para múltiples atributos, aumenta el acoplamiento y complica tanto el mantenimiento como la evolución de la solución. Esto también puede provocar errores difíciles de rastrear cuando se modifican atributos dentro de esos objetos.
Además, cualquier cambio en el contrato afecta a todas las invocaciones a esa entidad, lo que puede requerir ajustes en múltiples lugares de la solución (por ejemplo, agregar un nuevo insumo a una transacción requiere modificaciones en todos los procesos Lambda que la invocan).
Consideraciones:
Utiliza tokens explícitos y declarativos en los contratos. Evita pasar estructuras complejas (como objetos JSON) en un solo token. En su lugar, desglosa la información en tokens individuales, que representen claramente cada campo o parámetro esperado.
En las transacciones, cualquier token que deba actualizarse y, por consiguiente, devolverse, deberá declararse explícitamente como parte del contrato de salida. Esta práctica garantiza claridad, previsibilidad y facilita tanto el mantenimiento como la validación de los contratos. Aunque Studio técnicamente permite configurar cualquier token, informando al canal que hizo la invocación, esto representa una mala práctica.
Diseñar contratos estables y en evolución. Antes de presentar un contrato, comprueba que cubre los requisitos actuales sin dejar ningún campo que sea "temporal" o no esté claro. Si es necesario añadir nuevos parámetros en el futuro, considera estrategias de evolución controlada (por ejemplo, mantener la compatibilidad con versiones anteriores si aplica).
Reutilizar estructuras comunes cuando tenga sentido. Por ejemplo, si varios módulos utilizan la misma combinación de datos (usuario, correo electrónico, ID), considera encapsularlos en una estructura reutilizable, manteniendo la claridad de los campos individuales expuestos en el contrato. Aunque las estructuras no existan, como se mencionó anteriormente, se pueden emular con arrays.