Transcript
00:00:00Olá, muito obrigado por se juntar a nós hoje.
00:00:02Eu sou o Praneet, da equipe de workflow aqui na Vercel.
00:00:05Oi, eu sou o Nate, também da equipe de workflow.
00:00:08Nate, você e eu estamos na equipe de workflow desde o início,
00:00:12e de todas as coisas que lançamos nos últimos seis meses,
00:00:15acho que hooks e webhooks são um dos meus recursos favoritos,
00:00:18e é exatamente sobre isso que você veio falar hoje.
00:00:21Hooks e webhooks também são o meu recurso favorito.
00:00:23Eles são incrivelmente poderosos, e mostrarei algumas demos para explicar o porquê.
00:00:28A primeira demo é algo com o qual provavelmente todos estamos familiarizados, Magic Links.
00:00:33Magic Link é um formulário de login. Você digita seu e-mail, recebe um e-mail na sua caixa de entrada,
00:00:40e quando clica nesse link, você é logado no serviço.
00:00:44Sim, e se bem me lembro, com a Vercel, na verdade antes mesmo de se chamar Vercel,
00:00:48quando ainda se chamava Zeit, os Magic Links eram a única forma de autenticação,
00:00:52e nós mesmos construímos todo esse sistema na época.
00:00:56Isso mesmo, e eu ainda tenho estresse pós-traumático.
00:01:01Porque sem o workflow, implementar um sistema assim é muito mais complicado do que parece à primeira vista.
00:01:08A lógica acaba ficando espalhada por vários arquivos.
00:01:12Você precisa envolver um banco de dados para rastrear seu estado, e a bagunça acontece rápido.
00:01:19Sim, eu já estava pensando em como estruturaria isso e qual banco de dados usaria,
00:01:24porque parece um problema comum, já construí coisas assim antes.
00:01:28Então, sim, adoraria ver como ficou.
00:01:30Sim, então apenas para demonstrar do que estou falando, os pontos problemáticos mencionados,
00:01:38comecei implementando uma versão "tradicional" de um login por Magic Link, sem workflow.
00:01:43E há três endpoints envolvidos.
00:01:47O primeiro é quando o formulário de login é enviado,
00:01:50e ele precisa gerar uma sessão e armazená-la em um banco de dados, como o Redis.
00:01:57Você precisa implementar um TTL, não pode deixar os dados parados para sempre, precisa expirá-los.
00:02:06E depois enviar o e-mail; isso pode falhar, e então seu login não funciona, o que é uma experiência frustrante.
00:02:14Certo, e aí você precisa voltar e ter uma tarefa cron ou um estagiário limpando seu banco de dados.
00:02:19Eu talvez fosse o estagiário na época.
00:02:22Mas então há um segundo endpoint, que é o que acontece quando o usuário clica no link no e-mail.
00:02:28E este precisa basicamente consultar o banco de dados, restaurar o estado que foi construído no primeiro endpoint.
00:02:36E já estamos chegando a um código tipo espaguete.
00:02:38Quando eu estava tentando imaginar como isso seria, esse código parece tão familiar e é como eu o estruturaria também.
00:02:48Vemos que isso fica complicado rapidamente, mesmo sendo algo muito simples, um conceito muito simples.
00:02:54Então vamos dar uma olhada em como você implementaria esse recurso no Workflow.
00:02:59A implementação do magic link usando o SDK de Workflow se parece com isto.
00:03:05Vemos que temos nossa função, ela tem nossa diretiva useWorkflow, o que significa que esta é nossa função de Workflow.
00:03:11E a primeiríssima coisa que fazemos é chamar a função createWebhook, que vem do pacote Workflow.
00:03:18E também estamos usando a opção respondWithManual neste caso, o que significa que nossa função de Workflow
00:03:36será responsável por escrever ou enviar a resposta para a requisição HTTP que aciona este Webhook.
00:03:40Isso é para que você possa fazer um redirecionamento ou algo assim depois que eles fizerem o login?
00:03:51Sim, se houver alguma informação em nossa função de Workflow que precisemos para saber que tipo de resposta enviar.
00:03:57Semelhante ao primeiro endpoint, enviamos o e-mail de login. Esta é uma função useStep.
00:04:03Portanto, se algo assim falhar, o SDK de Workflow tem retentativas automáticas.
00:04:10O aspecto da durabilidade já está proporcionando algum benefício sobre a abordagem tradicional aqui.
00:04:21Então, sendLoginEmails é um passo, e se esse e-mail falhar, você tenta novamente o envio do e-mail
00:04:26com a mesma URL que você já criou para o Webhook.
00:04:30E se olharmos aqui, este é um padrão muito interessante.
00:04:35Estamos usando promise race com um sleep de cinco minutos.
00:04:40Isso é possível porque este objeto Webhook implementa uma promise.
00:04:50Então, para aguardar a requisição deste Webhook, você apenas usa await Webhook.
00:04:58Ou, neste caso, você está fazendo isso com a race. E isso é legal porque eu meio que esperava
00:05:02que esse recurso de Webhook tivesse um timeout ou algum tipo de opção como outro argumento.
00:05:06Mas eu quase gosto que seja muito mais limpo agora, que para fazer um timeout, você apenas o modela
00:05:12como uma corrida entre o Webhook e um sleep.
00:05:16Sinto que posso fazer muito mais com isso. Eu poderia talvez colocar dois Webhooks diferentes para correr um contra o outro.
00:05:21Não há muito o que se possa fazer quando se tem apenas alguns argumentos em uma função.
00:05:23Essa é a melhor parte.
00:05:28E assim, você pode ver que o Workflow responde à solicitação pública redirecionando para a página de login bem-sucedido.
00:05:33E então recupera informações sobre o seu usuário para retornar ao cliente que iniciou a página de login.
00:05:41E esse é o nosso Workflow inteiro. Nossa implementação de MagicLink tem 50 linhas de código.
00:05:44Isso é incrível de ver. Podemos ver isso em ação?
00:05:50Então, aqui está a nossa demo do MagicLink. Vou apenas inserir meu e-mail.
00:05:51E nosso Workflow foi iniciado ali e enviou o e-mail. E há um webhook apenas esperando.
00:05:59E, na verdade, nosso Workflow está suspenso agora. Portanto, há zero processamento sendo consumido enquanto espera o humano clicar no link no e-mail.
00:06:07Ah, e como isso aparece na Vercel? Consigo ver uma execução que esteja pendente?
00:06:12Essa é a melhor parte.
00:06:17E assim você pode ver que o Workflow responde à requisição pública redirecionando para a página de sucesso do login.
00:06:24E então recupera informações sobre seu usuário para retornar ao cliente que iniciou a página de login.
00:06:31E esse é todo o nosso Workflow. Nossa implementação de MagicLink tem 50 linhas de código.
00:06:41Isso é incrível de ver. Podemos ver isso em ação?
00:06:47Então, aqui está nossa demo do MagicLink. Vou apenas inserir meu e-mail.
00:06:52E nosso Workflow foi iniciado ali e enviou o e-mail. E há um webhook apenas esperando.
00:06:57E, na verdade, nosso Workflow está suspenso agora. Portanto, há zero consumo de processamento
00:07:02enquanto se espera que o humano clique no link no e-mail.
00:07:08Ah, e como isso aparece na Vercel? Posso ver uma execução que está pendente?
00:07:13Ok, então recebemos o e-mail. E antes de clicar nele, vamos dar uma olhada na observabilidade.
00:07:17Eu sei que estou pulando as coisas, mas adoro que estejamos olhando para isso.
00:07:25Tudo bem, podemos ver que nossa execução está aqui e começou há 40 segundos.
00:07:39Se dermos uma olhada, temos nossos recursos padrão de observabilidade que o Workflow oferece.
00:07:46Podemos ver as entradas da nossa execução de Workflow. Você pode ver meu endereço de e-mail que digitei no formulário.
00:07:50E, curiosamente, podemos ver que nosso hook está aqui apenas esperando.
00:07:59E você disse que não há processamento rodando agora. Esta é a observabilidade,
00:08:01mas não há nada realmente sentado esperando eu clicar naquele hook.
00:08:05Isso mesmo. O hook está esperando, e o sleep está dormindo, e ambas as coisas não envolvem processamento.
00:08:08Mas podemos ver que nosso hook, e se você se lembra, ambos estão correndo em um promise.race.
00:08:11Então, um deles precisa terminar primeiro para o Workflow continuar.
00:08:17Então, se eu clicar naquele link... ok, vemos que fui redirecionado para a página de sucesso do login,
00:08:27que era um dos passos na nossa lógica de Workflow.
00:08:34E se eu voltar para o formulário de login...
00:08:41Certo, e lá no dashboard, isso deve estar concluído também.
00:08:59Isso mesmo. Nosso Workflow foi concluído.
00:09:07E você pode ver que o cronômetro para assim que o hook ganha.
00:09:10Sim, fomos capazes de implementar o magic link com cerca de 50 linhas de código.
00:09:16Certo, certo. O recurso de criar webhooks é um pouco mais de alto nível nesse sentido, pois fornece um URL de webhook único e gerado aleatoriamente.
00:09:23Isso mapeia de volta para uma execução específica de Workflow.
00:09:31No caso da nossa rota de webhook do GitHub ou Slack, isso pode ser mapeado para qualquer número de execuções de Workflow.
00:09:36Certo. Você tem que pré-configurar algo, mas você tem múltiplos pull requests, e todos eles vão para o mesmo endpoint.
00:09:49Então, para implementar isso com o SDK de Workflow, vamos descer um nível e usar a primitiva "hook" de nível mais baixo.
00:09:54E eu tenho apenas uma demonstração para mostrar isso a você.
00:10:04Vamos dar uma olhada.
00:10:07Ok. Então, este é o bot "storytime".
00:10:14porque me dá uma forma totalmente diferente de pensar em webhooks.
00:10:20É apenas esta URL efêmera que posso criar e suspender nela.
00:10:28Na verdade, isso é uma boa deixa porque eu penso em como construímos muitos desses agentes na Vercel.
00:10:31Construímos vários agentes de Slack e agentes de GitHub, e muitas vezes assinamos webhooks do GitHub ou Slack, certo?
00:10:32Toda vez que há um novo comentário em um PR e queremos iniciar um agente da Vercel,
00:10:35queremos fazer isso com base em um evento que o GitHub envia esses webhooks, certo?
00:10:40Podemos usar webhooks de Workflow para realmente assinar eventos do GitHub, por exemplo?
00:10:47Ok, para algo como um webhook enviado pelo Slack ou GitHub,
00:10:52normalmente você tem que ir ao dashboard manualmente e configurar uma URL de callback estática.
00:11:05Certo. Você não pode criar isso de forma única, não posso dar uma URL única da mesma forma que posso com um e-mail aqui.
00:11:09Certo, certo. Então o recurso de criar webhook é um pouco mais de alto nível nesse sentido,
00:11:13pois fornece uma URL de webhook única gerada aleatoriamente que mapeia de volta para uma execução específica de Workflow.
00:11:17No caso da nossa rota de webhook do GitHub ou Slack, isso pode mapear para qualquer número de execuções de Workflow.
00:11:20Certo. Você tem que pré-configurar algo, mas você tem múltiplos pull requests, e todos eles vão para o mesmo endpoint.
00:11:26Então, para implementar isso com o SDK de Workflow, vamos descer um nível, vamos usar a primitiva hook de nível mais baixo.
00:11:28E eu tenho apenas uma demo para te mostrar isso.
00:11:35Vamos dar uma olhada.
00:11:38Ok. Então este é o bot storytime.
00:11:44Esta é a primeiríssima aplicação que escrevi com o SDK de Workflow há pouco mais de um ano.
00:11:50E como funciona é que você apenas digita o comando /storytime e vamos ver este tópico ser criado.
00:11:53Cada tópico é representado por uma execução individual de Workflow.
00:12:04E assim, quando expandimos o tópico, vemos que um LLM começou esta história para nós,
00:12:23e você ou eu ou quem quer que esteja neste canal pode continuar a história.
00:12:27E o LLM nos ajudará a levá-la à sua conclusão final.
00:12:34Ok. Então Luna tem uma semente mágica e o que acontece a seguir? Ela planta a semente.
00:12:40Ok. E vemos alguma atividade acontecendo aqui.
00:12:55O que acontece depois? Algo mágico.
00:13:04Nossa história está terminada e temos uma história final e haverá uma pequena imagem gerada também.
00:13:10Mas vamos pular isso, voltar para aquilo.
00:13:14Estou muito curioso agora porque notei que esperava uma requisição de webhook,
00:13:28mas houve na verdade duas, pelo menos duas requisições ali porque você teve duas mensagens.
00:13:35Então estou muito curioso para ver como isso é no código.
00:13:44Ok. Então esta é a função de Workflow para o nosso bot storytime.
00:13:58Podemos ver que ela recebe o channel ID, que é o canal do bot storytime.
00:14:04Ela tem algumas opções de configuração que você pode passar.
00:14:17Mas, curiosamente, podemos ver que há este array de mensagens que, se você estiver familiarizado com o AISDK,
00:14:29este é o formato de dados em que você armazena sua conversa de IA.
00:14:37E em uma aplicação típica de bot de Slack como a que criamos aqui, você normalmente armazenaria isso
00:14:50em um banco de dados e, em cada iteração ou cada evento de webhook, cada mensagem digitada no tópico,
00:14:59você restauraria seu estado, você buscaria a conversa em um banco de dados.
00:15:07E não é isso que está acontecendo aqui. Isso é apenas um array na sua função.
00:15:13Sim. Na verdade, está tudo bem porque eu ri mais cedo pois vi a introdução e você tinha esse comentário que dizia,
00:15:20"Olha mãe, sem filas ou KB."
00:15:28E não há importação aqui para um banco de dados. Você está apenas importando o Workflow.
00:15:35E voltando à coisa da última mensagem, isso quase passa despercebido, mas você realmente tem uma variável
00:15:44chamada final story que presumivelmente, ao longo do tempo, vamos dar push de mensagens neste array,
00:15:50e a história final vai aparecer como uma string aqui, mas não há um banco de dados para onde isso tenha que ir.
00:15:55Então é quase como se let fosse o seu banco de dados aqui.
00:16:06Mas elas sempre foram boas para demonstrações e eu não tinha conseguido encontrar uma boa maneira de usá-las.
00:16:11Aqui, me parece que você tem apenas um loop.
00:16:17Mas, em vez de iterar sobre um conjunto fixo de itens ou um timestamp, por usar for-await no hook, o loop mapeia exatamente.
00:16:25E o que é diferente do exemplo de web hook que vimos com o magic link é que, neste caso, estamos fornecendo um token,
00:16:33que é uma string que inclui informações de identificação que são exclusivas para esta execução de Workflow.
00:16:42O TS é o ID do tópico. Então esta string é o token que identifica exclusivamente esta execução de Workflow.
00:16:46Então, quando olharmos para o código da rota do web hook, veremos que o payload do evento que o Slack envia
00:16:50contém todas as informações que precisamos para recriar deterministicamente este identificador.
00:17:01E essa é a mágica de como o web hook mapeia de volta para uma execução individual de Workflow.
00:17:05Sim, fiquei curioso quando vi web hook porque você está criando novas URLs para o exemplo do magic,
00:17:12mas como já construímos esses bots de Slack antes, você não pode simplesmente dar uma nova URL em cada tópico.
00:17:22Então, a forma de entender como você está fazendo aqui é que você tem uma API já conectada ao Slack,
00:17:33mas toda vez que recebe uma mensagem, você basicamente calcula o mesmo token no lado da retomada.
00:17:42Assim, seu Workflow pode basicamente esperar por este token e você pode construir o mesmo token
00:17:43a partir de um payload de mensagem para retomar esta execução de Workflow.
00:17:48Exatamente. Sim. O bot do Slack foi configurado uma vez manualmente no dashboard do Slack,
00:17:57e você precisa definir estaticamente uma URL de callback de webhook.
00:18:03É por isso que a primitiva hook de nível mais baixo funciona melhor neste caso, pois podemos recriar o token dinamicamente.
00:18:08Então, apenas para olhar rapidamente, esta é a rota do webhook, e não tem muita coisa acontecendo aqui, na verdade.
00:18:12A principal coisa é como recriamos o token a partir dos dados passados pelo Slack.
00:18:16E então chamamos a função resume e isso retoma a execução do Workflow correspondente.
00:18:23Então eu imagino, isso é muito legal. E acho que com webhooks, o que você está fazendo é meio que a mesma coisa.
00:18:32O webhook é basicamente apenas fazer um token aleatório e então você tem um endpoint HTTP que resolve o mesmo token?
00:18:39Sim, bem, a diferença com o recurso de webhook é que você não precisa definir essa rota de API no seu código.
00:18:49O SDK de Workflow na verdade implementa uma rota padrão para o recurso de webhook para você.
00:18:52Mas sim, fora isso, é um token gerado aleatoriamente e exclusivo para uma execução específica de Workflow.
00:18:56Mas neste caso, temos nosso hook com o token e, voltando a algo que você mencionou agora há pouco,
00:18:58este hook pode receber dados várias vezes.
00:19:05Isso é diferente do exemplo do Magic Link, que só precisava ser acionado uma vez.
00:19:10Neste caso, queremos que o hook dispare para cada mensagem única que alguém digita no tópico do Slack.
00:19:14Para fazer isso, você usa a sintaxe for await no JavaScript, que é comum com iteradores assíncronos.
00:19:16Mas, neste caso, estamos recebendo múltiplos payloads de eventos do webhook do Slack usando nosso hook.
00:19:25Isso é tão legal. Nunca encontrei um ótimo caso de uso para... eu amo iteradores assíncronos e generators
00:19:34e até fiz uma palestra sobre isso há muito tempo. Mas eles sempre foram bons para demos
00:19:40e não consegui encontrar uma boa forma de usá-los. Aqui parece que você tem apenas um loop.
00:19:42Mas em vez de fazer o loop em um conjunto fixo de itens ou em um timestamp, porque você está usando for await
00:19:43e fazendo no hook, aqui está um loop que mapeia exatamente.
00:19:54Tudo dentro do loop mapeia para uma mensagem do usuário.
00:19:55E essa é uma boa maneira de pensar nisso: cada nova mensagem do usuário causará outra iteração desse loop
00:20:02e ele apenas enfileira e continua. A parte bonita disso é que, para cada iteração deste loop,
00:20:05enquanto esperamos o usuário digitar a próxima mensagem, não há absolutamente nenhum processamento sendo consumido.
00:20:06O workflow fica completamente suspenso e a próxima mensagem no tópico pode chegar em minutos, dias ou nunca,
00:20:17e está tudo bem. Então provavelmente há tópicos do Slack naquele mesmo canal onde eu poderia voltar agora
00:20:32e ainda há uma execução sentada esperando por algumas semanas se ninguém respondeu. Isso é muito legal.
00:20:41Então você pode distribuir um pacote NPM.
00:20:51O Sandbox basicamente distribui um pacote NPM que tem a diretiva "use Step" dentro desta função.
00:20:56Assim, ao importá-lo e usá-lo em um workflow, o Sandbox vira um Step automaticamente sem você precisar escrever nada.
00:21:00Isso é tão legal. E então vejo que você está fazendo mais promise.alls para paralelizar mais etapas no meio.
00:21:09Então, na verdade, esta operação é um Step.
00:21:12Assim você pode distribuir um pacote NPM.
00:21:15O Sandbox basicamente distribui um pacote NPM que tem a diretiva "use Step" dentro desta função.
00:21:21Assim, quando você o importa e usa em um workflow, ele torna o Sandbox um Step automaticamente, sem você escrever código.
00:21:29Isso não significa que você não possa usar o Sandbox para criar fora de um workflow.
00:21:32O que acontece quando você chama isso sem um workflow?
00:21:35Se você perceber, a diretiva é apenas uma string e, se você fosse executar isso sem o compilador de workflow,
00:21:47aquela string não faz nada. Então, simplesmente funciona.
00:21:49Adicionar "use Step" em seus pacotes NPM funciona bem sem o SDK de workflow.
00:21:55E uma vez que você usa essa função dentro do SDK de workflow, você ganha os benefícios de durabilidade nativamente.
00:22:03Ok, então o Sandbox apenas faz algumas coisas típicas.
00:22:07Ele instala o FFmpeg porque não está disponível por padrão.
00:22:11Ele baixa a URL de um arquivo que nós especificarmos.
00:22:14E cada uma dessas execuções também são apenas Steps agora?
00:22:17Sim, elas executam um comando individual no Sandbox e são Steps. Poderemos vê-los na observabilidade.
00:22:29E então voltamos a chamar o create-webhook, que você deve lembrar da demo do Magic Link.
00:22:36Mas neste caso, vamos passar essa URL de webhook para o nosso script Bash que rodaremos no Sandbox.
00:22:43O que está acontecendo aqui é que vamos rodar o FFmpeg e converter o arquivo para o formato solicitado na interface.
00:22:53E quando terminar, o script Bash fará um cURL contra a nossa URL de retorno do webhook.
00:22:59E quando essa requisição cURL acontece, a lógica do nosso workflow é retomada.
00:23:04Entendi. Isso é legal. Eu já estava olhando um pouco à frente e notei que há um "AND" nesta execução.
00:23:11Então você está escrevendo o script e rodando em segundo plano porque um Step de FFmpeg assim pode demorar muito mais.
00:23:17Você não quer um Step que fique parado apenas esperando por isso.
00:23:20Exato. Então esta linha bem aqui inicia nosso script de conversão FFmpeg em segundo plano.
00:23:28E então nossa função de workflow suspende e esperamos que o webhook seja retomado.
00:23:34E vejo o "promise race" novamente com um sleep de uma hora. Esse padrão é muito legal.
00:23:40Sim, e desta vez, o nosso processo de conversão FFmpeg pode demorar bastante.
00:23:46Pode ser um arquivo de mídia muito grande. Então estamos especificando um timeout de uma hora neste caso.
00:23:51E tudo bem. No workflow, você pode dormir por um tempo essencialmente indefinido.
00:23:56E, novamente, há zero computação rodando enquanto esperamos que este webhook seja retomado.
00:24:01E podemos ver isso? Podemos ver isso rodando? Temos uma demo?
00:24:04Temos sim.
00:24:05É um exemplo um pouco bobo.
00:24:07Sim, eu reconheci o exemplo do "Big Buck Bunny" imediatamente. É do Blender.
00:24:12Sim, lembro de ver esses vídeos quando estava aprendendo Blender há muito tempo.
00:24:16Nossa, que inveja.
00:24:19Então, colamos a URL do arquivo de mídia. Neste caso, vamos apenas extrair a camada de áudio.
00:24:26Assim que clicamos no botão, o workflow é iniciado e poderemos ir para a nossa observabilidade.
00:24:33Ah, lá está. Sim, podemos ver a criação do nosso sandbox.
00:24:37E isso retorna nossa instância do sandbox. Muito maneiro.
00:24:42E isso é porque nos sandboxes, tudo no workflow precisa ser serializável.
00:24:46Mas como você disse, sandboxes implementam serialização. Então eles também são serializáveis e aparecem no workflow.
00:24:53Isso mesmo. O pacote NPM do Vercel Sandbox tem uma classe sandbox e essa classe implementa as funções de serialização do workflow.
00:25:03E assim, simplesmente funciona na nossa observabilidade.
00:25:06Qualquer pacote pode fazer isso, certo? Não apenas o sandbox. Qualquer classe que queira funcionar no workflow pode usar os mesmos símbolos e diretivas.
00:25:17Exatamente. Podemos ver que nosso hook acabou sendo chamado de volta em 20 segundos desta vez.
00:25:25Uma conversão um pouco mais rápida por ser um arquivo pequeno, mas poderia ter sido qualquer intervalo de tempo.
00:25:31Vemos que após o sandbox ser criado e inicializado, o hook foi criado e passado para o sandbox para iniciar o comando FFmpeg.
00:25:43E quando terminou, recebemos um payload do nosso sandbox.
00:25:48E este é o curl que aconteceu no script bash antes. Ele executa o comando e usa o curl no sandbox para completar o webhook.
00:25:57Certo. Nosso sandbox terminou o trabalho que estava fazendo, então está devolvendo o controle para o nosso workflow.
00:26:04A forma como penso nisso agora é: com steps no workflow, você roda um step, ele executa o código em segundo plano e continua o workflow.
00:26:13Mas hook e webhook parecem ser de um nível mais baixo. Eu posso criar um token ou uma URL e esperar por qualquer coisa.
00:26:21Pode ser um magic link humano, um e-mail, um sandbox ou qualquer tipo de computação que precise acontecer.
00:26:27E meu workflow simplesmente pausa com todo o seu estado até que o evento ocorra. Parece mais fundamental que o próprio step.
00:26:34Sim. Eu vejo o webhook e o hook como uma forma de passar payloads externos para dentro do seu workflow.
00:26:42Eu penso que o step é como um workflow pode suspender, esperar uma computação terminar e então retomar.
00:26:50Mas hook e webhook parecem ser de nível ainda mais baixo porque você gera um token ou URL que pode enviar, neste caso ao sandbox, mas poderia ser para qualquer lugar.
00:27:01Poderia ser um humano, um e-mail ou até outro workflow, por exemplo.
00:27:05E sempre que isso completa, seu workflow pai basicamente acorda e retoma exatamente de onde parou.
00:27:12Então é de certa forma mais baixo nível que o step. É um jeito de suspender seu workflow para qualquer ação externa.
00:27:19Sim. Gosto de pensar no hook como um modo de suspender o workflow e esperar um payload externo ser devolvido ao workflow, o que é muito poderoso.
00:27:31Isso é muito legal. Sei que nosso tempo acabou por hoje, mas essas demos validaram de novo por que o hook é minha função favorita no workflow.
00:27:42Incrível. Fico feliz que tenha gostado.
Community Posts
No posts yet. Be the first to write about this video!
Write about this video