Configuración

Esta página trata todas las opciones de runlight() y routes(), incluidos los almacenes y los sitios.

import { runlight } from "@runlight/sdk";

export const rl = runlight({ store, site, /* ...options */ });
export const routes = rl.routes({ /* ...route options */ });

Esta página usa los nombres de la biblioteca de TypeScript. Todos los demás lenguajes aceptan las mismas opciones, escritas como ese lenguaje escribe los nombres, como muestra su página, de PHP a Rust.

Almacenes

Runlight guarda todo en unas pocas tablas con el prefijo rl_, que se crean la primera vez que se usan y se actualizan in situ. Cada almacén acepta una opción prefix para usar en lugar de rl_, como wp_rl_, para que dos aplicaciones que comparten una base de datos tengan cada una sus propias tablas. Admite hasta 32 letras, dígitos y guiones bajos y no empieza por un dígito, y tables() de un almacén lista sus tablas por nombre, para una aplicación que quiera quitar Runlight.

SQLite

import { sqlite } from "@runlight/sdk/sqlite";

sqlite({ path: "./data/runlight.db" });

SQLite necesita better-sqlite3 y es adecuado para un solo servidor, donde el archivo puede estar junto a la base de datos de tu aplicación. En un hosting serverless sin disco persistente, usa Postgres. Un archivo que crea Runlight solo lo pueden leer y escribir su propietario y su grupo (0660), así que una tarea programada que se ejecute como otro usuario del mismo grupo también puede usarlo.

Postgres

import { postgres } from "@runlight/sdk/postgres";

postgres({ url: process.env.DATABASE_URL });

Postgres necesita pg. Pasa url, o pasa pool para compartir un pool que tu aplicación ya tenga (Runlight nunca cierra un pool que no creó). Un pool necesita al menos 2 conexiones. Cuando Runlight crea el pool, max fija sus conexiones y por defecto es 10, una petición espera como mucho 10 segundos a que quede una libre (un hit del tracker lo intenta dos veces más antes de descartarse), y statementTimeout detiene cualquier consulta tras ese número de milisegundos, 120000 por defecto (0 lo desactiva). Si varios procesos arrancan a la vez, las tablas se siguen creando una sola vez. Un proceso espera como mucho 30 segundos a otro que esté creando o actualizando las tablas, y después una petición responde 503 con el código tables_busy, y un hit del tracker espera como mucho 10 segundos y después se descarta.

MySQL y MariaDB

import { mysql } from "@runlight/sdk/mysql";

mysql({ url: process.env.DATABASE_URL });

Este almacén necesita mysql2 y funciona con MySQL 8.0.20 o posterior y MariaDB 11.4 o posterior. Pasa una URL mysql:// o mariadb:// como url, o pasa pool para compartir un pool de mysql2/promise que tu aplicación ya tenga (Runlight nunca cierra un pool que no creó). Un pool necesita al menos 2 conexiones. Cuando Runlight crea el pool, max fija sus conexiones y por defecto es 10, una petición espera como mucho 10 segundos a que quede una libre (un hit del tracker lo intenta dos veces más antes de descartarse), y statementTimeout detiene cualquier consulta tras ese número de milisegundos, 120000 por defecto (0 lo desactiva). En MySQL ese límite cubre las lecturas, y en MariaDB cubre todas las sentencias. Si varios procesos arrancan a la vez, las tablas se siguen creando una sola vez. Un proceso espera como mucho 30 segundos a otro que esté creando o actualizando las tablas, y después una petición responde 503 con el código tables_busy, y un hit del tracker espera como mucho 10 segundos y después se descarta.

Las tablas usan utf8mb4 con la intercalación utf8mb4_0900_bin. El texto se compara y se ordena por punto de código, conservando mayúsculas y espacios finales, así que cada informe se lee igual que en SQLite o Postgres.

libSQL y Turso

import { libsql } from "@runlight/sdk/libsql";
import { createClient } from "@libsql/client"; // or "@libsql/client/web" on the edge

libsql({ client: createClient({ url: process.env.TURSO_URL, authToken: process.env.TURSO_TOKEN }) });

Este almacén necesita @libsql/client. Turso por HTTP funciona en cualquier lugar donde funcione fetch, incluidos Vercel Edge y Deno Deploy, y una URL file: apunta a un archivo SQLite local.

Cloudflare D1

import { d1 } from "@runlight/sdk/d1";

d1({ database: env.DB });

Pasa el binding de D1 desde el entorno de tu Worker. D1 no tiene transacciones interactivas, así que una importación de enlaces escribe cada enlace por separado; si una falla a medias, al ejecutar de nuevo la importación se omiten los enlaces ya escritos.

Bun

import { bunSqlite } from "@runlight/sdk/bun";

bunSqlite({ path: "./data/runlight.db" });

Este almacén usa el SQLite integrado de Bun, para aplicaciones en Bun, donde better-sqlite3 no se carga.

Opciones de runlight()

Sitios

Una visita desde un nombre de host que ningún sitio reclama se ignora, así que una copia de staging de tu sitio no cuenta a menos que añadas su nombre de host.

Límite de peticiones

Cada proceso cuenta las peticiones al tracker por dirección de visitante durante un minuto y descarta en silencio las demás, para que un script no pueda inundar un sitio con visitas inventadas. Un visitante real envía unas pocas peticiones por minuto, muy por debajo del valor predeterminado de 120. La cuenta vive en memoria bajo una dirección en forma de hash y se borra cada minuto, así que ninguna dirección se guarda nunca. En hostings que ejecutan muchas copias efímeras de tu aplicación, como Cloudflare Workers, cada copia cuenta por su cuenta, así que allí el límite es más laxo.

Ubicación

El país, la región y la ciudad salen de las cabeceras de tu hosting en Vercel, Cloudflare y Netlify, sin configurar nada. En otros lugares, pasa geo, una función que convierte una dirección IP en una ubicación. Este ejemplo usa un archivo MMDB.

runlight({
  store,
  geo: async (ip) => {
    const found = reader.get(ip); // your MMDB reader
    return found ? { country: found.country?.iso_code, city: found.city?.names?.en } : null;
  },
});

La dirección se descarta después de la búsqueda, así que solo se guarda el lugar.

Opciones de routes()

Las opciones accountOf y tokenMade conectan las rutas con las cuentas propias del servidor independiente y son internas de él.

Sin token, el panel y la API responden 503 hasta que definas uno, salvo que NODE_ENV sea development. Recoger visitas, el script, los enlaces cortos, los enlaces para compartir y los enlaces para darse de baja nunca necesitan el token.

Cuentas

Activa las cuentas para que varias personas puedan iniciar sesión en el panel, cada una con su propio correo, contraseña y rol, igual que en el servidor independiente.

export const { GET, POST, PUT, PATCH, DELETE } = rl.routes({ accounts: true });

El panel pide entonces a todos que inicien sesión en /runlight/login. Para crear la primera cuenta, abre /runlight/setup y escribe tu RUNLIGHT_TOKEN junto con tu correo y tu contraseña, de modo que solo pueda hacerlo quien gestiona la aplicación. Esa cuenta es el propietario. En desarrollo sin token, o con token: null, que lo deja todo abierto, la primera cuenta no necesita token, así que créala antes de que nadie más pueda llegar a la página.

El propietario y los administradores invitan a más personas en Ajustes, Personas, como administrador, miembro o lector, y la invitación sale por correo cuando hay un servicio de correo configurado. Cualquiera puede activar el inicio de sesión en dos pasos en Cuenta. El token sigue funcionando como bearer token para los scripts.

Las sesiones se firman con RUNLIGHT_SECRET, o con el token cuando no está definido, así que mantenlo igual entre reinicios y despliegues. Las contraseñas se guardan como hash con scrypt cuando el runtime lo tiene, como Node, Bun y Deno, y con PBKDF2 en runtimes edge como Cloudflare Workers.

Si alguien olvida su contraseña, el propietario o un administrador puede quitarlo e invitarlo de nuevo. Si el propietario olvida la suya, dale a la cuenta una nueva desde un script que use tu Runlight.

import { Accounts } from "@runlight/sdk";
import { rl } from "./lib/runlight";

const accounts = new Accounts(rl.store, process.env.RUNLIGHT_SECRET ?? process.env.RUNLIGHT_TOKEN!);
const user = await accounts.setPassword("you@example.com", "a new long password", Date.now());
await accounts.disableTwoFactor(user.id);

Variables de entorno