Dejar que la gente suba fotos a tu app hecha con IA (sin que se caiga)

En el momento en que tu app deja de ser solo texto y empieza a dejar que la gente suba una foto, algo cambia. Agregar carga de imágenes y archivos significa dejar que un usuario envíe una foto, un recibo o un documento desde su dispositivo hacia tu app, que lo guarda y lo muestra después — una foto de perfil, un recibo, la foto de un paquete dañado, un contrato en PDF. Es una de esas funciones que parece un simple checkbox y que resulta tener varias aristas filosas por debajo. Ninguna es difícil. Pero las que nadie te advierte son las que aparecen tres semanas después del lanzamiento, casi siempre de tu usuario más entusiasta.

Este es un recorrido por lo que realmente pasa cuando alguien le da a “subir”, los tres errores que muerden después, y las cosas exactas que hay que pedirle a tu builder para no toparte con ellos.

¿Qué pasa realmente cuando subes una foto a una app?

Subir una foto dispara cuatro pasos en orden: tu teléfono le entrega el archivo a la app, la app lo manda a un almacenamiento de archivos separado (no a la base de datos), la app guarda un enlace a ese archivo junto al registro, y después lo recupera usando ese enlace cada vez que alguien ve el registro.

Así se ve, paso a paso:

1. El teléfono le entrega el archivo a tu app. Una foto moderna de celular suele pesar entre 4 y 12 megabytes. Eso no es poco.
2. Tu app manda ese archivo a algún lugar donde se guarde — no en la base de datos de tu app, sino en un depósito de almacenamiento separado, hecho para archivos.
3. Tu app guarda un enlace a ese archivo en la base de datos, junto al resto del registro (este recibo pertenece a este gasto).
4. Después, cuando alguien ve el registro, la app recupera el archivo del almacenamiento usando ese enlace y lo muestra.

La parte donde la gente se equivoca es en los pasos 2 y 3. Se imaginan que la foto queda “guardada en la app”. No es así, y no debería serlo. Los archivos viven en almacenamiento; tu base de datos solo recuerda dónde. Si separas bien esas dos cosas, todo lo demás se vuelve más fácil.

¿Deberías guardar las fotos subidas directamente en la base de datos?

No — y este es el error de carga más común, uno que los builders de IA a veces cometen por defecto si no eres específico. Meter una foto de 10 MB directamente en tu base de datos es como guardar tus muebles en la cartera. La base de datos está hecha para cosas pequeñas y estructuradas — nombres, fechas, precios. Si le echas fotos encima, se vuelve lenta, los respaldos se inflan, y un día una página que antes cargaba al instante tarda seis segundos porque está arrastrando cien imágenes en resolución completa.

Lo que quieres en su lugar: el archivo va a un almacenamiento de archivos (tu builder puede llamarlo “storage bucket” o “blob storage”), y la base de datos solo guarda el enlace. Pídeselo directamente:

“Guarda las imágenes subidas en almacenamiento de archivos, no en la base de datos. Guarda solo la URL del archivo en el registro.”

¿Cómo evitas que los usuarios suban el tipo de archivo equivocado o un archivo enorme?

Decides de antemano qué está permitido — tipo de archivo, límite de tamaño y un mensaje de error claro — y se lo dices explícitamente a tu builder, porque sin esas reglas tu app aceptará cualquier cosa, incluidos archivos que traban la carga por completo. Dos escenarios reales muestran por qué, ambos de apps que funcionaban bien en las pruebas:

Una mujer maneja un pequeño negocio de banquetes y construyó una app para que sus clientes subieran fotos de pasteles que les gustaban. Funcionó perfecto hasta que una clienta subió una foto de 47 MB directo de una cámara profesional. La carga se trabó, la clienta se dio por vencida, y ella se enteró como “tu app está descompuesta”. No estaba descompuesta — simplemente nunca se puso un límite de tamaño, así que se quedó ahí para siempre tratando de tragarse un archivo enorme.

Otro caso: una freelancer construyó un portal de clientes donde la gente sube “su logo”. Un cliente subió un archivo .zip. Otro subió un PDF de 90 páginas. La app aceptó todo porque nadie le dijo qué se suponía que era un logo.

Decide estas tres cosas de antemano:

• ¿Qué tipos de archivo? ¿Solo fotos? Entonces acepta JPG y PNG y rechaza el resto, con un mensaje amable.
• ¿Qué tan grande? Un límite razonable para fotos es de 5 a 10 MB más o menos. Suficiente para una foto real de celular, chico como para frenar un volcado de cámara profesional.
• ¿Qué pasa si está mal? La app debería decirlo con amabilidad — “Por favor sube un JPG o PNG de menos de 10 MB” — no simplemente quedarse congelada.

Dile a tu builder:

“Permite solo imágenes JPG y PNG de hasta 10 MB. Si alguien sube algo distinto o demasiado pesado, muestra un mensaje claro en vez de fallar en silencio.”

¿Por qué se siente lenta tu app cuando tiene muchas fotos?

Porque cada persona que la ve descarga el original en tamaño completo cada vez, no una copia reducida — en su celular, con sus datos móviles, cada vez que alguien abre el registro. Digamos que alguien sube una foto nítida de 8 MB y funciona bien sola. Multiplica eso por una galería de veinte fotos y tu app, antes rápida, se siente como caminar en el lodo.

La solución tiene un nombre que vale la pena conocer, porque tu builder lo va a reconocer: un thumbnail, o versión redimensionada. La idea es que conservas el original pero también generas una copia pequeña, apta para web, y muestras esa copia pequeña en listas y vistas previas. La versión completa solo carga cuando alguien realmente quiere verla en grande.

“Cuando se suba una imagen, genera también una versión redimensionada más pequeña para vistas previas y listas. Muestra la versión pequeña por defecto y carga la imagen completa solo cuando alguien haga clic para verla.”

No necesitas entender cómo se hace. Necesitas saber que existe, para poder pedirlo antes de que tu app se sienta lenta y no después.

Algunas decisiones más silenciosas que vale la pena tomar

Estas tres decisiones no van a romper tu app si te las saltas, pero salen más baratas ahora que si las corriges después: quién puede ver el archivo, qué pasa con él cuando se borra el registro, y si la carga funciona en un celular.

• ¿Quién puede ver el archivo? Una foto de perfil está bien que la vea cualquiera. Una identificación escaneada o un contrato firmado no. Si el archivo es privado, dile a tu builder que el enlace debe requerir inicio de sesión, no ser una URL pública que cualquiera pueda abrir. Este es el punto en el que más insistiría para cualquier cosa sensible.
• ¿Qué pasa cuando se borra el registro? Si alguien borra un gasto, ¿debería limpiarse también la foto del recibo? De lo contrario vas acumulando poco a poco archivos huérfanos que estás pagando por almacenar y de los que te olvidaste.
• ¿Funciona en un celular? La mayoría de las cargas ocurren en celulares, y los celulares ofrecen “tomar una foto ahora mismo” además de “elegir de la galería”. Prueba ambas en un celular real, no solo en tu laptop, donde solo arrastras un archivo.

Pruébala como lo haría un desconocido

Pruébala tratando deliberadamente de romperla como lo hará por accidente un usuario real — una foto normal, un archivo demasiado grande, el tipo de archivo equivocado, una carga en vivo desde la cámara del celular, y un borrado — antes de darla por terminada:

• Sube una foto normal de celular. ¿Aparece, y la vista previa es rápida?
• Sube algo enorme. ¿La app te detiene con un mensaje claro, o simplemente se queda trabada?
• Sube el tipo equivocado — un PDF donde se espera una foto. ¿Explica la regla?
• Abre la app en tu celular y sube directamente desde la cámara.
• Borra un registro y revisa si su archivo se maneja como decidiste que se manejara.

Si las cinco se comportan bien, ya superaste las aristas que atrapan a la mayoría de la gente.

Las cargas son una de esas funciones donde la brecha entre “funciona en la demo” y “funciona para un desconocido en un tren con una foto de gato de 12 MB” es exactamente el conjunto de decisiones de arriba. Ninguna es difícil. Simplemente son fáciles de saltarse — y mucho más fácil pedirlas ahora que repararlas después.

Si has estado posponiendo agregar cargas porque se sentía como un gran salto técnico, no lo es. Abre tu builder, pide almacenamiento de imágenes con un límite de tamaño y un thumbnail, y mira qué te da. Después ve a intentar romperlo en tu celular — esa es la prueba de verdad, y toma cinco minutos.