Skip to main content
O Node Registry é um endpoint da API pública que fornece um schema completo e estruturado de todos os nodes disponíveis (built-in e customizados) para um tenant. Ele é fundamental para a construção de editores de workflows no frontend, fornecendo todas as informações necessárias para renderizar, validar e configurar nodes dinamicamente.

Propósito

O Node Registry serve como uma fonte única de verdade sobre os nodes disponíveis, fornecendo:
  • Catálogo completo: Lista todos os nodes built-in e customizados disponíveis para o tenant
  • Schemas detalhados: Define estruturas de entrada, saída e configuração de cada node
  • Metadados: Informações sobre versão, descrição, capacidades e tipo de cada node
  • Validação: Especificações que permitem validação em tempo real no editor

Endpoint

Autenticação

Requer autenticação via chave de API (pública ou secreta):

Resposta

Estrutura do Schema

Cada node no registry contém as seguintes propriedades:

Propriedades Principais

string
required
Identificador único do tipo de node (ex: "input", "transform", "custom-api-call"). Usado para referenciar o node ao criar workflows.
string
required
Nome legível do node exibido na interface do usuário (ex: "User Input", "Transform Data").
string
Descrição detalhada do que o node faz e quando deve ser usado.
string
required
Versão do node seguindo semantic versioning (semver), ex: "1.0.0".
boolean
required
Indica se é um node built-in (true) ou customizado (false). Nodes built-in são fornecidos pela plataforma, enquanto customizados são criados pelo tenant.
boolean
required
Indica se o node pode pausar a execução do workflow (ex: aguardando input do usuário). Nodes com canPause: true permitem workflows interativos.

Schemas de Dados

object
required
Schema que define os campos de entrada esperados pelo node. Cada chave é o nome do campo e o valor é um NodeFieldSchemaDto com especificação completa de tipo, validação e descrição.Exemplo:
object
required
Schema que define os campos de saída produzidos pelo node. Estrutura similar ao inputSchema, mas descreve o que o node retorna após a execução.Exemplo:
object
Schema que define as configurações do node (settings que o usuário pode ajustar ao adicionar o node ao workflow). Inclui validações, valores padrão e tipos completos.Exemplo:

NodeFieldSchemaDto

O NodeFieldSchemaDto é a estrutura base usada em inputSchema, outputSchema e configSchema. Ele suporta tipos complexos e validações avançadas:

Tipos Suportados

  • string: Texto com validações de comprimento e padrões regex
  • number: Números com validações de min/max e suporte a inteiros
  • boolean: Valores booleanos
  • any: Qualquer tipo (sem validação específica)
  • object: Objetos com propriedades definidas e suporte a propriedades adicionais
  • array: Arrays com schema de itens e validações de tamanho
  • enum: Valores enumerados (lista de valores permitidos)

Propriedades Comuns

string
required
Tipo do campo: "string", "number", "boolean", "any", "object", "array" ou "enum".
string
Descrição do propósito do campo.
boolean
Se o campo é obrigatório (padrão: false).
any
Valor padrão do campo se não fornecido.

Validações por Tipo

String

number
Comprimento mínimo (inclusivo).
number
Comprimento máximo (inclusivo).
string
Padrão regex para validação.

Number

number
Valor mínimo (inclusivo).
number
Valor máximo (inclusivo).
boolean
Se o número deve ser inteiro (sem decimais).

Object

object
Definição de propriedades do objeto (recursivo, cada propriedade é um NodeFieldSchemaDto).
boolean
Se propriedades adicionais (não definidas em properties) são permitidas.

Array

NodeFieldSchemaDto
Schema dos itens do array (recursivo).
number
Número mínimo de itens (inclusivo).
number
Número máximo de itens (inclusivo).

Enum

array
Lista de valores permitidos: ["value1", "value2", ...].

Padrões e Protocolo

Multi-Tenancy

O Node Registry é isolado por tenant. Cada requisição retorna apenas os nodes disponíveis para o tenant autenticado:
  • Nodes built-in: Fornecidos pela plataforma, podem ser desabilitados por tenant via configuração
  • Nodes customizados: Criados pelo tenant e visíveis apenas para ele
  • Traduções: Aplicadas automaticamente baseadas na configuração de i18n do tenant

Versionamento

  • Nodes seguem semantic versioning (semver)
  • Versões são imutáveis: uma vez criado, um node mantém sua versão
  • Novas versões devem ser criadas como novos nodes ou através de atualizações controladas

Filtragem e Personalização

O registry aplica automaticamente:
  1. Filtragem de built-in nodes: Remove nodes built-in desabilitados na configuração do tenant
  2. Traduções: Aplica traduções baseadas no idioma configurado do tenant
  3. Ativação: Inclui apenas nodes customizados ativos (isActive: true)

Ordenação

A ordem dos nodes na resposta não é garantida. O frontend deve ordenar conforme necessário (ex: por tipo, nome, ou categoria).

Uso no Frontend

O Node Registry é projetado para ser consumido por editores de workflows no frontend. Recomendamos usar o SDK oficial do Triglit para facilitar a integração.

Instalação do SDK

Aqui está um exemplo de como utilizá-lo:

Exemplo: Construindo um Editor de Workflows

Integração com React SDK

O React SDK do Triglit já utiliza o Node Registry internamente:

Casos de Uso

1. Construção Dinâmica de UI

O registry permite construir interfaces de edição de workflows sem hardcoding de nodes:
  • Renderizar paleta de nodes baseada no registry
  • Gerar formulários de configuração automaticamente
  • Validar inputs em tempo real usando os schemas

2. Documentação Automática

Os schemas podem ser usados para gerar documentação automática:
  • Listar todos os nodes disponíveis
  • Mostrar exemplos de configuração
  • Explicar inputs e outputs esperados

3. Validação de Workflows

Antes de salvar um workflow, valide se:
  • Todos os nodes usados existem no registry
  • Configurações estão de acordo com os schemas
  • Conexões entre nodes são válidas (outputs compatíveis com inputs)

4. Extensibilidade

O registry facilita a extensão da plataforma:
  • Novos nodes built-in aparecem automaticamente
  • Nodes customizados são imediatamente disponíveis
  • Sem necessidade de atualizar o frontend para novos nodes

Boas Práticas

Cache

O registry pode mudar quando nodes customizados são criados, atualizados ou desativados. Implemente cache com invalidação apropriada.
Recomendações:
  • Cache o registry por alguns minutos (ex: 5-10 minutos)
  • Invalide o cache quando o usuário criar/editar nodes customizados
  • Considere usar ETags ou versionamento para detectar mudanças

Tratamento de Erros

Performance

  • Busque o registry uma vez ao carregar o editor
  • Considere paginação se o número de nodes for muito grande (futuro)
  • Use lazy loading para nodes customizados se necessário

Exemplo Completo

Referências

Use o Node Registry para construir editores de workflows dinâmicos e extensíveis, sem depender de hardcoding de nodes específicos.