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

type
string
required
Identificador único do tipo de node (ex: "input", "transform", "custom-api-call"). Usado para referenciar o node ao criar workflows.
name
string
required
Nome legível do node exibido na interface do usuário (ex: "User Input", "Transform Data").
description
string
Descrição detalhada do que o node faz e quando deve ser usado.
version
string
required
Versão do node seguindo semantic versioning (semver), ex: "1.0.0".
isBuiltIn
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.
canPause
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

inputSchema
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:
outputSchema
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:
configSchema
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

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

Validações por Tipo

String

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

Number

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

Object

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

Array

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

Enum

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.