O js-sdk (o RollfuseClient no centro da família sdk-js/sdk-browser/sdk-react) avalia flags localmente contra uma Configuration que busca uma vez e mantém quente com polling em segundo plano. Assim como o go-sdk do lado Go, a avaliação nunca faz uma chamada de rede: o caminho da requisição lê uma Configuration em cache, e os dois SDKs são verificados contra os mesmos vetores de bucketing dourados, então um subject cai no mesmo bucket não importa qual dos dois avaliou.
Instalando e montando um client
npm install @rollfuse/sdk-js
import { RollfuseClient } from "@rollfuse/sdk-js";
const client = new RollfuseClient({
credential: process.env.ROLLFUSE_CREDENTIAL!, // set before running
baseUrl: process.env.ROLLFUSE_BASE_URL!, // e.g. https://api.rollfuse.com
});
await client.start();
O construtor nunca busca nada sozinho: start() é quem começa o polling em GET /v1/config e retorna uma Promise que resolve assim que a primeira Configuration chega. Um serviço que prefere não bloquear a inicialização nessa chamada pode chamar start() sem esperar, deixando a opção de fallback do evaluate() sustentar as avaliações até a primeira busca terminar.
Avaliando uma flag
const result = client.evaluate(subjectKey, "checkout-redesign", {
attributes: { plan: "growth" },
fallback: false,
});
if (result.value === true) {
// serve o novo checkout
}
evaluate() é síncrono e determinístico: mesmo subject, mesma flag, mesma versão de Configuration, mesmo resultado, sempre, sem nenhuma requisição em voo enquanto seu código espera. Se a Configuration ainda não carregou, ou a plataforma ficou brevemente inacessível e uma busca falhou, evaluate() retorna o fallback que você passou em vez de lançar um erro, então uma avaliação de flag nunca é o motivo de uma requisição falhar.
O que acontece se o backend fica inacessível
O js-sdk continua servindo a última Configuration buscada com sucesso se uma atualização em segundo plano falha. Ele não limpa o cache num poll que falhou, e não tenta de novo de forma agressiva a ponto de adicionar carga durante um incidente. evaluate() continua disponível com o que tinha por último, que é exatamente o desacoplamento de disponibilidade da plataforma que todo o desenho de avaliação local existe pra garantir: uma indisponibilidade do rollfuse degrada pra "as flags param de mudar", não pra "as flags param de avaliar".
Reportando exposição
Toda avaliação com match de regra é enfileirada e reportada em POST /v1/exposure-events de forma assíncrona, agrupada por tamanho ou por um intervalo de flush, o que vier primeiro. Isso nunca adiciona latência ao evaluate(). Chame client.close() no shutdown (ou antes de uma função serverless terminar a invocação) pra dar flush no que ainda estiver na fila.
Veja o repositório js-sdk pros bindings do sdk-browser e sdk-react, e o examples-node-opentelemetry pra um serviço executável.