Temporizadores Free vs Premium (técnico)
Information
Esta página detalla las diferencias técnicas entre los temporizadores
“Free” y “Premium” en gettickr.app, más allá de las funciones visibles
(guardado, control remoto, etc.). Explica cómo funcionan la persistencia, la
sincronización y las URLs de visualización según el tipo de cuenta.
Visión general
- Free (sin cuenta):
- Temporizadores anónimos, no guardados en servidor
- La configuración se codifica en la URL del editor
- Cada modificación genera una nueva URL
- Sin persistencia ni control remoto
- Premium (con cuenta):
- Temporizadores guardados en Realtime Database (Firebase)
- URL de visualización (renderer) estable que no cambia
- Control remoto y actualizaciones instantáneas
- Gestión de temporizadores desde un panel (dashboard)
Diferencias clave de arquitectura
| Aspecto | Free | Premium |
|---|---|---|
| Persistencia | Ninguna (solo cliente) | Guardado en servidor (Realtime Database) |
| Autenticación | No | Firebase Auth |
| URL de visualización | Cambia tras cada modificación | Estable y permanente |
| Sincronización | Basada en URL estática (config codificada) | Timestamps de servidor + actualizaciones push en tiempo real |
| Control remoto | No | Sí (inicio/pausa/reset, ajustes de duración/objetivo) |
| Seguridad | Básica (no hay estado sensible en servidor) | Reglas Firebase (Single Writer: solo propietario escribe) |
| SEO/Integración | Buena (embed simple) | Excelente (URL estable, integración persistente en CMS/OBS) |
Persistencia y estado del temporizador
- Free:
- El estado (duración/objetivo, diseño) vive en el editor y en la URL.
- Tras una modificación, la URL cambia; hay que actualizar las integraciones (OBS, sitio).
- No existe “state” en servidor; no hay lectura/escritura segura.
- Premium:
- El estado del temporizador se guarda en Firebase Realtime Database
(
timers/{uuid}). - El renderer lee las actualizaciones en tiempo real.
- El propietario del temporizador es el único autorizado a escribir (Single Writer Pattern).
- El estado del temporizador se guarda en Firebase Realtime Database
(
Information
El renderer (visualización) es siempre de solo lectura. Nunca modifica
el estado del temporizador; solo muestra y sigue las actualizaciones.
Sincronización y cálculo del tiempo
Para evitar deriva temporal (drift), la plataforma aplica principios estrictos:
- Cálculo basado en timestamps (nunca mediante decrementos ingenuos del tipo
timeLeft = timeLeft - 1000) - Actualización del renderer cada 100 ms (~10 FPS) para un render fluido
- Premium: uso de timestamps de servidor Firebase en eventos críticos (p. ej., inicio/pausa de un countdown)
Lógica recomendada (conceptual) para un CountTo:
- Tomar “ahora” (Date.now)
- Calcular la diferencia con la fecha objetivo (UTC ISO 8601)
- Convertir a Duration (días/horas/minutos/segundos) para el display
- Evitar cualquier lógica incremental del tiempo restante
Countdown vs CountTo
- Countdown (duración):
- Puede iniciar, pausar, reanudar, reiniciar
- La duración puede ajustarse en caliente (Premium: vía control remoto)
- CountTo (fecha):
- Siempre en ejecución hasta alcanzar la fecha objetivo
- No hay estados “start/pause”; solo puede cambiarse el objetivo (fecha/hora)
- Guardar objetivo en UTC ISO 8601; mostrar localmente según idioma/zona
Tip
Para CountTo, usa fechas en UTC (2025-12-31T22:59:59.000Z) y deja que
la visualización se adapte a la configuración local del usuario.
URLs: comportamiento e implicaciones
- Free:
- La URL codifica la configuración; un cambio ⇒ nueva URL
- Implicación: hay que actualizar los embeds (OBS, sitio) tras editar
- Premium:
- La URL del renderer no cambia
- Las modificaciones (duración/diseño/objetivo) se reflejan automáticamente
| Acción | Free | Premium |
|---|---|---|
| Cambiar duración/diseño | Requiere nueva URL | No cambia la URL |
| Actualizar embed OBS/sitio | Sustituir el enlace | No hay que hacer nada (actualización auto) |
| Usar en otro dispositivo | Re-editar vía URL | Cargar el temporizador desde el dashboard |
Seguridad y reglas de acceso (Premium)
- Single Writer Pattern: solo el propietario puede escribir el estado (
state) - El renderer y las rutas de visualización son solo lectura
- Reglas Firebase: validación del propietario requerida para las escrituras
Warning
No intentes escribir desde un renderer o rutas de visualización;
estos endpoints deben permanecer “read-only”.
Integración en streaming y sitios
- OBS/Streamlabs/XSplit: integrar vía Browser Source con la URL del renderer
- Sitios web:
- iFrame estándar
- CMS (WordPress, Shopify, Wix/Squarespace)
- HTML personalizado
- Premium: ideal para integraciones duraderas (una URL única, actualizaciones transparentes)
¿Cuándo elegir Free vs Premium (técnico)?
Elige Free cuando:
- Necesitas algo puntual, prueba rápida, prototipo
- No requieres persistencia ni control remoto
Elige Premium cuando:
- Necesitas una URL estable y actualizaciones en directo
- Control remoto (inicio/pausa/reset, ajustes) es importante
- Usas temporizadores de forma recurrente (streaming habitual, páginas de eventos)
- Requieres seguridad y control de acceso (propietario único)
Buenas prácticas
- Evitar lógica incremental para el tiempo restante
- Guardar fechas CountTo en UTC ISO 8601
- Mantener el editor abierto para el control remoto (o usar persistencia Premium)
- Nombrar claramente los temporizadores (p. ej., “Pausa Stream 10min”) para el dashboard
- Probar legibilidad y encuadre en OBS antes del live
Limitaciones y advertencias
- Free: sin persistencia, y las URLs cambian tras cada modificación
- Premium: eliminar un temporizador es definitivo; la URL deja de funcionar al instante
- CountTo: no se puede “iniciar” o “pausar” (stateless por diseño)
Próximos pasos
- Estado del temporizador y sincronización — Perspectiva detallada sobre persistencia y actualizaciones en tiempo real
- Guardar y gestionar — Construye una biblioteca de temporizadores (Premium)
- Control remoto — Pilota los temporizadores en directo (Premium)
- Free vs. Premium (visión general) — Comparativa funcional de cara al usuario