Si manejás en Argentina, sabés el problema: para saber si un auto tiene multas hay que entrar a un sistema distinto por cada provincia y cada municipio, cada uno con su captcha y sus horarios de caída. Un mismo auto puede deber en tres lados a la vez, y es facilísimo mirar uno solo y quedarse tranquilo de más.
Hicimos una app que resuelve eso en una sola búsqueda. Se instala en el celular en unos segundos, es gratis, no pide un solo permiso y no está en ninguna tienda.
Este post es las dos mitades: qué hace, por si te sirve usarla, y cómo la construimos sin pasar por Google Play ni la App Store, por si te sirve copiar el enfoque.
Qué hace, concretamente
Multita busca por patente, DNI o CUIT y consulta 32 jurisdicciones argentinas de una vez, entre provinciales y municipales. Devuelve cada acta con su estado y su monto en pesos.
El detalle que importa: no te muestra un número guardado. Cuando buscás, entra a los sistemas oficiales en ese momento y convierte cada acta a pesos con el valor vigente de su jurisdicción.
Eso no es un capricho de arquitectura. En Argentina las multas no están escritas en pesos, están escritas en Unidades Fijas, y cada jurisdicción actualiza la suya cuando quiere. En septiembre pasó dos veces en dos días: Provincia de Buenos Aires movió la suya un 0,44% el día 1, y la Ciudad la movió un 23,5% el día 2. El mismo auto, con actas de los dos lados, tiene dos aumentos distintos la misma semana. Un valor cacheado ahí no es un dato viejo: es un número inventado.
Cómo se instala, sin tienda
Android (Chrome): entrás a multita.com.ar y aparece el aviso de instalar. Si no aparece, menú de tres puntos, "Instalar aplicación".
iPhone (Safari): botón de compartir, "Agregar a inicio". Tiene que ser Safari, que es el único navegador del iPhone que lo permite.
Queda con ícono propio, abre en su ventana sin barra de direcciones y arranca directo en la pantalla de consulta. Si mantenés apretado el ícono, tenés tres atajos: consultar, generar un descargo y novedades.
Nada de esto descarga cuarenta megas ni pide acceso a tus contactos.
Por qué no la publicamos en una tienda (todavía)
Las ventajas son reales y vale enumerarlas sin romanticismo:
- Cero permisos. No los necesita, así que no los pide. Eso solo ya cambia la conversión: nadie abandona en una pantalla de permisos que no existe.
- Cero espacio. Pesa lo que pesa una página.
- Cero actualizaciones. Siempre abre la última versión. No existe el usuario trabado tres releases atrás.
- Una sola base de código y un solo deploy. No hay build de Android, ni de iOS, ni esperar una review por arreglar una coma.
Y lo que se pierde, que también es real: no aparecés en el buscador de la tienda, que para mucha gente sigue siendo donde se buscan las apps, y no tenés la ficha con reseñas que da confianza. Por eso estamos armando igual la versión de Play. Pero no era un prerrequisito para tener la app funcionando, y esa es la parte que se suele asumir mal.
La parte difícil: el cache que puede mentirte
Acá viene lo técnico, y es lo único de todo esto que fue realmente delicado.
Una PWA necesita un service worker, que es un proxy que vos escribís entre la app y la red. Es lo que la hace instalable y lo que la hace abrir sin señal. También es lo que puede mentirle a tu propia aplicación.
En nuestro caso hay una complicación poco común: una consulta es un job largo y durable. Tarda minutos, se registra en la base, el browser la va poll-eando y un cron cierra los jobs que quedaron sin nadie mirando. Toda esa maquinaria existe por un bug caro: cuando el resultado dependía de que el browser polleara hasta el final, cerrar la pestaña equivalía a perder la consulta.
Ahora ponele un cache adelante. Dos reglas que no se negocian:
La ruta del poll no se cachea. Nunca.
if (url.pathname.startsWith('/api/')) return; // a la red, siempre
Si el service worker contesta una sola vez desde el cache, le miente al poll sobre el estado de un job: el browser cree que la consulta sigue corriendo cuando terminó, o al revés. Sería reintroducir, desde la capa que agregamos para mejorar la experiencia, exactamente el bug que toda la maquinaria de jobs existe para evitar.
Las pantallas con token en la URL tampoco.
La pantalla de una consulta en curso lleva en la URL un token que es la llave del resultado. Cachearla dejaría esa llave escrita en el disco del teléfono, sobreviviendo a la pestaña, a cambio de nada: sin red esa pantalla no sirve igual, porque su contenido viene de la API que por la regla anterior no está cacheada. Todo el riesgo, cero beneficio.
Hay una tercera que no es de seguridad sino de buenos modales: el sitio tiene más de 900 páginas, así que el cache de páginas tiene un techo de 40. Sin eso, alguien que navega una tarde se lleva medio sitio al disco sin haberlo pedido, gastando sus datos.
Sin señal: qué anda y qué no
Es donde más se promete de más en los posts de PWA, así que va derecho:
- La app abre sin señal, con su propia pantalla en lugar del dinosaurio, y lo que ya visitaste se sigue viendo.
- La consulta no anda sin señal, y es el diseño, no una limitación. No hay copia de tus multas en el teléfono. Se entra a los organismos en el momento. Un resultado guardado sería un número viejo, y ya vimos lo que hace un 23,5% de golpe.
"La app abre offline" y "la app funciona offline" son cosas distintas, y conviene tenerlo claro antes de escribir la primera línea de service worker.
Probala
- Se instala desde multita.com.ar en Android y iPhone. Gratis, sin registro, sin tienda.
- El paso a paso con el detalle de cada teléfono está en cómo instalar la app para consultar multas.
- Si querés integrarlo a lo tuyo, la API devuelve las 32 jurisdicciones en JSON, con cada acta ya convertida a pesos al valor vigente de la suya.
- Y si te quedaste con la duda de los saltos: CABA subió 23,5% de un día para el otro mientras Provincia subía 0,44%.
Si estás por meterle un service worker a algo, la pregunta que más rinde no es qué cachear, sino qué pasa si servís esta respuesta justo cuando cambió. Para la mayoría de las rutas la respuesta es "nada". Para dos o tres, es todo el producto.