Eventos vs exports: cuándo usar cada uno
FiveM ofrece dos mecanismos principales para la comunicación entre recursos: eventos y exports. Los eventos son asíncronos y de tipo "dispara y olvida", ideales para notificaciones, logging y para disparar efectos colaterales entre recursos. Los exports, en cambio, son llamadas de función síncronas que devuelven un valor al momento, perfectas para recuperar datos y funciones de utilidad. Elegir el mecanismo correcto para cada caso de uso es fundamental para escribir código de FiveM limpio y mantenible.
Eventos de servidor y cliente
Los eventos en FiveM fluyen en direcciones concretas. TriggerServerEvent envía datos del cliente al servidor, donde pueden gestionarse de forma segura. TriggerClientEvent envía datos del servidor a uno o a todos los clientes usando un identificador de source o -1 para broadcast. Los eventos locales disparados con TriggerEvent se quedan dentro del mismo contexto de ejecución. Registra siempre los eventos de red con RegisterNetEvent antes de añadir handlers y recuerda que cualquier evento registrado en el cliente puede ser disparado por cheaters con injectors.
Asegurar tus eventos
Los handlers de eventos en servidor deberían validar siempre los datos entrantes. Comprueba que el jugador source existe, verifica que los tipos de datos coinciden con lo esperado y aplica rate limiting para evitar spam. Nunca pases información sensible como IDs de base de datos a través de eventos de cliente sin verificar. Un patrón habitual es usar callbacks de servidor donde el cliente pide datos, el servidor valida la petición y obtiene la información, y después dispara un evento de respuesta de vuelta a ese cliente concreto.
Trabajar con exports
Los exports permiten a un recurso exponer funciones que otros pueden llamar directamente. Defines los exports en tu fxmanifest.lua y los implementas en tus archivos de script. Cuando otro recurso llama a exports['your-resource']:YourFunction(args), se ejecuta de forma síncrona y devuelve el resultado. Esto es especialmente útil para bridges de framework, librerías compartidas de utilidades y acceder a datos desde scripts de teléfono, sistemas de inventario o gestores de trabajos sin acoplar los recursos estrechamente por eventos.
Callbacks y patrones async
Muchos frameworks de FiveM implementan sistemas de callback que combinan eventos con gestión de respuesta. QBCore usa QBCore.Functions.CreateCallback en el servidor y QBCore.Functions.TriggerCallback en el cliente. ESX tiene un patrón similar con ESX.RegisterServerCallback. Estos callbacks dejan al cliente pedir datos al servidor y recibirlos en una función de callback, salvando la distancia entre eventos asíncronos y un código que se siente síncrono. Entender estos patrones es esencial cuando trabajas con consultas a base de datos o comprobaciones de inventario que requieren autoridad del servidor.
Buenas prácticas para la comunicación entre recursos
Mantén los nombres de eventos con namespace para evitar colisiones, con un patrón tipo resourceName:eventAction. Documenta tus exports con claridad para que otros desarrolladores puedan integrarse con tu recurso. Evita dependencias circulares donde dos recursos se exportan funciones entre sí, porque puede causar problemas de orden de carga. Al diseñar APIs para tus scripts, prefiere exports para acceso simple a datos y eventos para workflows complejos que impliquen varios pasos o efectos en distintas partes del servidor.