Transforms

O NimbusNexus Transforms faz dos pipelines objetos independentes. Um pipeline é uma lista curta de etapas declarativas que descartam uma requisição a menos que ela corresponda, removem ou adicionam campos, remontam o corpo a partir de um template e definem headers. Monte um no console ou pela API REST, teste-o, mantenha as versões dele, execute-o pela API ou referencie-o pelo id a partir do produto que envia.

Não é a página que você procurava? O Transforms não envia nada por conta própria. Para mudar o que um endpoint recebe em cada entrega, veja Transformações no Webhooks e, para mudar o que um bin encaminha, veja Um pipeline antes de cada encaminhamento no Request Bins. Experimente um pipeline sem conta no playground.

Em resumo

Como funciona

1. Monte um pipeline: adicione etapas no formulário do console, cole-as em JSON ou comece a partir de um template. Um documento que nunca conseguiria rodar é recusado ao ser salvo, com 422 invalid_pipeline, indicando a etapa, o caminho e o motivo.
2. Teste-o. Execute o que está no editor em uma requisição que você colar e veja o corpo e os headers que ele enviaria, a etapa que a descartou ou por que falhou.
3. Salve-o. Salvar conteúdo novo adiciona uma versão, e uma versão nunca muda. O mesmo conteúdo de novo não adiciona nenhuma, e restaurar uma versão antiga é salvar o conteúdo dela de novo.
4. Execute-o, de uma de duas formas:
   • Pela API. Envie uma requisição para POST /v1/pipelines/{id}/run. Ela executa o pipeline sobre o que você envia, responde com o resultado e não guarda nada. Enviar o resultado para algum lugar cabe a você.
   • Por referência. Referencie o pipeline pelo id a partir do Webhooks, que o executa antes de cada entrega, no próprio processo. Cada versão nova chega a ele sem mudar nenhum endpoint.

O início rápido faz os passos 1 a 4 pela API.

O que uma execução responde

Um pipeline não tem loops, relógio nem rede, então o mesmo pipeline sempre faz a mesma coisa com a mesma requisição. Uma execução responde 200 com um de três status, porque em todos os casos o pipeline rodou:

Credenciais

O Transforms não guarda credenciais. A etapa auth de um pipeline diz que um bearer token, autenticação básica ou uma chave de API vai na requisição e indica um slot para essa credencial. Um slot é um id e um rótulo, sem valor: adicione um no console, em Credential slots, ou com POST /v1/slots. O documento traz o id do slot e nada mais, então um pipeline lido de volta nunca mostra uma credencial, e nenhuma rota recebe nem retorna o valor de uma credencial.

Para enviar uma, execute o pipeline por referência a partir do produto que envia. Esse produto associa o slot a um segredo no próprio armazenamento, sob a própria chave, e o envia às próprias URLs. Fora desse produto, o slot não significa nada.

O Test e a API de execução mostram o que a etapa adicionaria, com o valor mascarado: Authorization: Bearer ••••. Eles não conseguem enviar uma credencial, porque o Transforms não tem nenhuma para enviar.

Onde um pipeline roda aparece primeiro. A leitura de um pipeline lista os produtos que o executam por referência e a versão que cada um executa. Salvar uma nova versão com uma etapa auth, ou excluir o pipeline, exige indicar cada um deles em confirm_destinations; caso contrário, a ação é recusada com 409 conflict, destinations_unconfirmed (Quem executa um pipeline).

Planos e limites

As seis etapas, os templates, o Test, a API de execução e a execução por referência estão em todos os planos, inclusive no Free.

As execuções são contadas, não cobradas. GET /v1/usage mostra as do mês. Acima da taxa do plano, que o Test compartilha, ou com execuções ou testes demais do workspace em andamento ao mesmo tempo, uma execução responde 429 rate_limited com o tempo de espera. Uma execução em um produto que referencia o pipeline conta no uso desse produto. Uma versão que um produto fixa é mantida além do número do plano, assim como as cinco versões anteriores que um produto foi visto executando mais recentemente nos últimos 30 dias.

Como obter acesso

Abra o console em https://transforms.nimbusnexus.net e entre com a sua conta NimbusNexus, ou adicione o Transforms em Add a product em qualquer console NimbusNexus. A primeira visita de um proprietário ou admin do workspace adiciona o Transforms ao workspace; a partir daí, os outros membros podem abri-lo.

As chaves não são emitidas pela API de Transforms. Crie uma no seu console da conta, em API keys, com Transforms como produto. Uma chave é um JWT, por isso começa com eyJ. Apresente-a como Authorization: Bearer <key> ou X-API-Key: <key>.

Escolha a permissão dela ao criá-la: Read lê e executa pipelines, e Read & write também pode criar, alterar, testar e excluir pipelines. Quem pode fazer o quê traz a tabela completa, incluindo as funções do workspace.

O que ele não faz

• Ele não envia. Não tem destino, retentativas nem log de entregas. O Webhooks entrega eventos, e o Request Bins encaminha requisições.
• Ele não guarda o que processa. A requisição e a resposta de uma execução desaparecem quando a chamada termina. Só a contagem fica.
• Ele não guarda credenciais. Uma credencial vem do produto que executa o pipeline por referência.
• Ele não executa código. Para lógica que as etapas não conseguem expressar, um endpoint do Webhooks pode executar um script em vez disso, em um plano pago.

Próximos passos

• Início rápido — teste um pipeline, salve-o, execute-o e salve uma nova versão.
• Pipelines — todas as etapas, caminhos, filtros e templates, e os limites de uma execução.
• Referência de Transforms — todas as rotas e campos, funções, limites e erros.
• API de Transforms — todas as operações, com a requisição em curl, TypeScript, Python ou Go.
• Execute-o a partir do Webhooks — associe os slots a segredos e vincule-o a um endpoint.
• Playground — execute um pipeline de exemplo sem conta.