En seyfert el enfoque de sharding (fragmentación para los amigos) es dar todo el beneficio del escalado manteniendo la misma estructura en tu proyecto.
¿Por qué hacer sharding?
Los runtimes de JavaScript son de un solo hilo, lo que significa que sin sharding, todo el procesamiento ocurriría en un único hilo. Esto crea un límite de procesamiento donde toda la carga se evalúa junta. Seyfert maneja el sharding internamente en la instancia del Client para ayudar a distribuir esta carga a través de múltiples procesos o hilos (aunque sigue siendo una técnica imperfecta).
Manejando los shards
La base de los Worker es permitir ejecutar código en paralelo en diferentes partes de la CPU, ya sea en hilos o procesos diferentes. En términos de Discord, esto significa la capacidad de conectar varios shards repartiendo la carga en cada Worker. Para Seyfert esto es tan simple como cambiar la propiedad mode en el WorkerManager para decidir el modo de ejecución entre threads para hacer spawn de clientes en los hilos del procesador o cluster para hacer spawn de los clientes en procesos diferentes del runtime.
¿Demasiado simple? Seyfert se encarga de toda la lógica por lo que tu proyecto no debería cambiar mucho solo por pasarte a un WorkerSharding.
Cache
A diferencia de las bibliotecas tradicionales de Discord, Seyfert ofrece una gestión de caché unificada a través de todos los shards. El caché puede centralizarse en el proceso principal (el ejecutor de WorkerManager), asegurando un acceso consistente a los datos en toda tu aplicación.
Para implementar el caché centralizado, usa el WorkerAdapter:
Si por alguna razón (no encontré ninguna para el ejemplo), deseas que un worker específico ejecute una acción que otro recibió, puedes simplemente pedírselo.
The console module provides a simple debugging console that is similar to the
JavaScript console mechanism provided by web browsers.
The module exports two specific components:
A Console class with methods such as console.log(), console.error() and console.warn() that can be used to write to any Node.js stream.
A global console instance configured to write to process.stdout and
process.stderr. The global console can be used without importing the node:console module.
Warning: The global console object's methods are neither consistently
synchronous like the browser APIs they resemble, nor are they consistently
asynchronous like all other Node.js streams. See the note on process I/O for
more information.
Example using the global console:
console.log('hello world');
// Prints: hello world, to stdout
console.log('hello %s', 'world');
// Prints: hello world, to stdout
console.error(newError('Whoops, something bad happened'));
// Prints error message and stack trace to stderr:
// Error: Whoops, something bad happened
// at [eval]:5:15
// at Script.runInThisContext (node:vm:132:18)
// at Object.runInThisContext (node:vm:309:38)
// at node:internal/process/execution:77:19
// at [eval]-wrapper:6:22
// at evalScript (node:internal/process/execution:76:60)
// at node:internal/main/eval_string:23:3
constname='Will Robinson';
console.warn(`Danger ${name}! Danger!`);
// Prints: Danger Will Robinson! Danger!, to stderr
Example using the Console class:
constout=getStreamSomehow();
consterr=getStreamSomehow();
constmyConsole=newconsole.Console(out, err);
myConsole.log('hello world');
// Prints: hello world, to out
myConsole.log('hello %s', 'world');
// Prints: hello world, to out
myConsole.error(newError('Whoops, something bad happened'));
// Prints: [Error: Whoops, something bad happened], to err
Prints to stdout with newline. Multiple arguments can be passed, with the
first used as the primary message and all additional used as substitution
values similar to printf(3)
(the arguments are all passed to util.format()).