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
Identificador único do tipo de node (ex:
"input", "transform", "custom-api-call"). Usado para referenciar o node ao criar workflows.Nome legível do node exibido na interface do usuário (ex:
"User Input", "Transform Data").Descrição detalhada do que o node faz e quando deve ser usado.
Versão do node seguindo semantic versioning (semver), ex:
"1.0.0".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.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
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: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: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
ONodeFieldSchemaDto é 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 regexnumber: Números com validações de min/max e suporte a inteirosboolean: Valores booleanosany: Qualquer tipo (sem validação específica)object: Objetos com propriedades definidas e suporte a propriedades adicionaisarray: Arrays com schema de itens e validações de tamanhoenum: Valores enumerados (lista de valores permitidos)
Propriedades Comuns
Tipo do campo:
"string", "number", "boolean", "any", "object", "array" ou "enum".Descrição do propósito do campo.
Se o campo é obrigatório (padrão:
false).Valor padrão do campo se não fornecido.
Validações por Tipo
String
Comprimento mínimo (inclusivo).
Comprimento máximo (inclusivo).
Padrão regex para validação.
Number
Valor mínimo (inclusivo).
Valor máximo (inclusivo).
Se o número deve ser inteiro (sem decimais).
Object
Definição de propriedades do objeto (recursivo, cada propriedade é um
NodeFieldSchemaDto).Se propriedades adicionais (não definidas em
properties) são permitidas.Array
Schema dos itens do array (recursivo).
Número mínimo de itens (inclusivo).
Número máximo de itens (inclusivo).
Enum
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:- Filtragem de built-in nodes: Remove nodes built-in desabilitados na configuração do tenant
- Traduções: Aplica traduções baseadas no idioma configurado do tenant
- 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
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
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
- SDK TypeScript Oficial - Documentação completa do SDK
- Guia de Custom Nodes - Aprenda a criar nodes customizados
- Conceitos: Nodes - Entenda o conceito de nodes
- Referência OpenAPI - Especificação completa da API

