Apps web y dashboards: lo que Briks crea hoy

#Los tres tipos

#Empieza una app o un dashboard

#Lo que puede hacer una app hoy

Una app se planifica y se construye como una página web, con las mismas preguntas antes de construir, paradas de aprobación y tableros de estilo. Cuando tu descripción pide que algo se guarde, también incluye:

• Su propia base de datos. Creada para ti, en la UE, la primera vez que la construcción guarda algo: reservas, productos, eventos, consultas o publicaciones.
• Formularios que guardan. El formulario estándar guarda cada envío en Settings, Forms y te lo envía por correo una vez que el sitio está en producción. Un formulario también puede guardar cada envío como un registro, donde puedes encontrarlo, editarlo y cambiar sus datos más adelante. Pídelo en tu descripción.
• Páginas creadas a partir de registros. Una página de lista y una página para cada registro, de modo que cada evento o producto es una página real que los buscadores pueden encontrar. Cuando los registros cambian, el sitio publicado se actualiza en unos minutos.
• Búsqueda en lo que guarda, cuando se lo pides.
• Cuentas y pagos, cuando los pides: registro e inicio de sesión para sus propios usuarios, pagos únicos y suscripciones a través de tu propio procesador, y envíos o stock creados con tu propia cuenta de pago. Consulta Inicio de sesión y pagos.
• Un servicio tuyo, con tu propia clave, como una lista de correo, un CRM o una hoja de cálculo. Pídelo como un cambio una vez publicado el sitio: Briks pide primero la clave, con un campo que la guarda directamente en Secrets, y el código de servidor del propio sitio llama al servicio con ella. Las páginas en el navegador de un visitante nunca llaman a otra dirección. Consulta Preguntas antes de construir.

Antes de publicar un sitio con este tipo de código funcional, Briks lee el código en busca de descuidos de seguridad: claves escritas en archivos, guardado sin límite, registros de miembros leídos sin que nadie haya iniciado sesión y consultas a la base de datos construidas a partir de texto.

#Qué es un dashboard

Un dashboard se crea como pantallas en las que la gente trabaja a diario, no como una página que se recorre con scroll. Espera:

• Un marco con navegación a un lado, como una barra de iconos delgada, o en la parte superior, más una barra superior.
• Un encabezado en cada pantalla con su título, una línea sobre ella y sus acciones principales.
• De tres a cinco cifras clave, gráficos con unidades y etiquetas, y tablas con búsqueda, filtros, orden y páginas.
• Detalles de registros, formularios y pantallas de ajustes donde tu descripción los necesite.
• En un teléfono, la navegación lateral se convierte en un menú y las cifras se apilan de dos en dos, y luego de una en una.

No hay hero, ni titular de marketing, ni animación al desplazarse, y no se crean imágenes. Un dashboard también omite las preguntas previas a la construcción y las paradas de aprobación: se crea directamente a partir de tu descripción.

De dónde salen sus números

Un dashboard guarda sus registros en la base de datos del proyecto, con una tabla para cada tipo de registro que muestran sus pantallas. La primera versión las llena con registros de ejemplo verosímiles que concuerdan entre sí; los productos, precios y personas que nombra tu descripción se convierten en registros, y a cualquier otra persona se le inventa un nombre. Sus tablas, gráficos y cifras clave leen esos registros, cada total se calcula a partir de las filas, y los formularios que añaden o modifican un registro lo guardan. Sus páginas de inicio de sesión funcionan: mientras es una vista previa, cualquiera con su dirección puede abrirlo, y una vez que lo publicas en producción solo las cuentas Staff y Admin con sesión iniciada ven sus datos. Regístrate en él con el correo que usas en el estudio para ser su Admin.

Para dar forma a sus registros, indica en la descripción qué se guarda, qué contiene cada registro y quién lo actualiza. Los registros se editan en la pestaña Database, y las pantallas los siguen.

#Tus registros en la pestaña Database

Cuando un proyecto tiene base de datos, su pestaña Database tiene cinco vistas: Data, Accounts, Orders, Subscriptions y Settings. Los Owners y Admins ven la pestaña también antes, con Create database.

• Data enumera cada colección con cuántos registros contiene. Owners, Admins y Editors pueden abrir, editar y eliminar registros. “Los cambios llegan al sitio publicado en pocos minutos.”
• Accounts muestra las personas que crearon una cuenta en el sitio, donde asignas a cada una el rol Member, Staff o Admin. Orders muestra lo que el sitio vendió a través de tu propio procesador de pagos, y Subscriptions los miembros que pagan planes que se renuevan. Accounts y Orders muestran No accounts yet o No orders yet hasta que llega el primero.
• Settings incluye las descargas (hasta 50.000 registros por colección, como hoja de cálculo o como JSON), los puntos de restauración y la copia nocturna. Las descargas y las copias nocturnas vienen con un plan de pago.

Database cubre los registros al completo, y Backups cubre las copias y la restauración.

#Tareas programadas y webhooks

Dos secciones de Settings del proyecto, en el grupo Developer, permiten que una app actúe según un horario o avise a otro software de lo que ha pasado.

• Las Scheduled tasks llaman a una dirección según un horario que tú eliges, como Every day at 09:00 o Mondays at 09:00: una de las direcciones propias de tu app que empiezan por /api/, u otra distinta. Tu app necesita primero esa dirección, así que pídela como un cambio. Consulta Tareas programadas.
• Los Webhooks envían un mensaje a otra dirección cuando ocurre algo: Published, Form received o Record changed. Consulta Webhooks.

#Qué aún no está disponible

• Planes que se renuevan a través de PayPal, Mollie, Razorpay, Creem o Dodo Payments: estos solo aceptan pagos únicos por ahora. Las suscripciones van a través de Stripe, Paddle, Polar o Lemon Squeezy.
• Exportar las entradas de formularios desde Forms. Los registros de la base de datos se pueden descargar en un plan de pago.
• Correo desde tu propio dominio. El correo del sitio se envía desde la dirección propia de tu proyecto en emails.briks.live.
• Una API pública, un servidor MCP o una línea de comandos para el propio Briks.

Aun así, puedes llegar a otro software de tres maneras: los webhooks envían eventos hacia fuera, las tareas programadas llaman a una dirección según un calendario, y un cambio puede conectar un servicio que use tu propia clave, como se explica más arriba.

#Tres ejemplos resueltos