Diseñar correctamente los modelos de datos que viajan entre el cliente y el servidor marca la diferencia entre una aplicación móvil rápida y una que desperdicia recursos. Comprender qué información solicitar, cuál omitir y cómo negociar con el equipo de backend es una habilidad fundamental para cualquier desarrollador mobile que busque alto rendimiento.
¿Qué es un modelo de datos y por qué se define entre equipos?
Cuando una aplicación se comunica con un servidor a través de APIs, existen datos de entrada y datos de salida. El modelo de datos es la estructura que define exactamente qué información se envía y se recibe en cada petición [0:20]. Este modelo no lo decide un solo equipo: se construye en conjunto entre el equipo de backend y el equipo front mobile, que representa la parte del cliente.
El formato más utilizado en el mercado para este intercambio es JSON (JavaScript Object Notation), un estándar ligero, fácil de leer y ampliamente adoptado [0:47]. Su simplicidad lo convierte en la opción preferida para estructurar la comunicación entre servicios.
¿Por qué enviar solo los datos estrictamente necesarios?
Un error común es diseñar respuestas de API que incluyan toda la información disponible, sin considerar lo que la vista realmente necesita. El ejemplo planteado es claro: si una pantalla de cursos solo muestra imagen, nombre y descripción, no tiene sentido recibir datos como el rating, la disponibilidad, la información completa del profesor o un array con todos los estudiantes graduados [1:08].
- Incluir datos innecesarios aumenta el peso de la respuesta.
- El procesador de un dispositivo móvil es limitado, y las aplicaciones de alto nivel exigen performance y velocidad [3:20].
- La responsabilidad de procesar y transformar datos debe recaer en el backend, no en el cliente.
¿Qué sucede cuando necesitamos contar elementos?
Si la vista requiere mostrar la cantidad de estudiantes graduados, la tentación es recibir el array completo y contarlo del lado del cliente. Sin embargo, esto es incorrecto [2:52]. Lo óptimo es que el backend envíe directamente un campo como graduated_students_count con un número entero, por ejemplo 230, en lugar de un arreglo con la información detallada de cada estudiante [3:43].
¿Qué datos nunca deben viajar en una API?
Uno de los errores más graves es incluir contraseñas en las respuestas o solicitudes de la API [2:17]. Esto representa una vulnerabilidad de seguridad crítica. Existen métodos seguros de autenticación como OAuth que resuelven este problema sin exponer credenciales [4:08]. Tampoco es necesario enviar datos como el email o la foto del profesor si la vista solo requiere su nombre y un ID para relacionarlo.
¿Cómo aplicar requerimientos funcionales al diseño del modelo?
Los requerimientos funcionales y no funcionales juegan un papel directo en la definición del modelo de datos [4:38]. Si un requerimiento establece que no se deben mostrar cursos no disponibles, entonces esos cursos simplemente no deberían llegar en la respuesta del API. No tiene sentido recibir el dato, leerlo y luego ocultarlo; esa lógica de filtrado pertenece al servidor.
El resultado de aplicar estas prácticas es notable: un JSON que inicialmente contenía decenas de líneas con información redundante se reduce a una estructura limpia con solo los campos imprescindibles [5:08].
¿Cómo mejorar APIs que ya existen en producción?
En la práctica profesional es común encontrar APIs que no están bien diseñadas [5:23]. Lo que un desarrollador mobile puede hacer es:
- Argumentar técnicamente por qué ciertos datos sobran o generan problemas de rendimiento.
- Proponer al equipo de backend las modificaciones necesarias con datos concretos.
- Trabajar en equipo para alcanzar un consenso sobre la estructura óptima [5:15].
Reducir el tamaño de las respuestas, eliminar campos innecesarios y delegar el procesamiento al servidor son acciones que impactan directamente en la experiencia del usuario. La próxima vez que definas un modelo de datos, pregúntate: ¿realmente necesito este campo en la vista? Si la respuesta es no, ese dato no debería estar ahí.
