Most people think that building a

workflow platform is about the visual

editor. Drag, drop, and connect some

nodes. But that's the easy part. The

hard part, making those workflows

actually execute. In this tutorial

we're building Nodebase, a workflow

automation platform like N8N or Zapier.

In part one, we built the editor, the

canvas, authentication, and payments. In

part two, we're building everything

else. The execution engine, the

triggers, the integrations, credential

encryption, execution history, and

deployment. This is where we finish and

ship the entire platform. You will learn

how to pass variables between nodes

build a templating system for data

transformation, and implement real-time

updates so you can see workflows

executing live. We're building trigger

nodes, Google forms, stripe web hooks

the full AI integration layer with open

AI, Anthropic and Gemini, Discord and

Slack notes, encrypted credential

management, execution history with full

error tracking, additional out providers

like Google and GitHub, and finally

deployment. By the end of this tutorial

Nodebase will be a production ready

product. And now without further ado

let's finish this project. Before we

dive in, using the link on the screen

you can get 3 months of Sentry Team

completely for free. We'll be using

their AI monitoring to track all our LLM

calls throughout this build. If that

sounds useful for your project, feel

free to grab the deal. And now, let's

build. In this chapter, we're going to

focus on executing our nodes. In the

previous few chapters, we focused on

building the UI for each node and for

the editor itself, but we never actually

executed or used any data from those

nodes. So that's what we are going to be

focusing on today. Let's go ahead and

first improve the props for our HTTP

request node so it's easier to work with

its data. So inside of features

executions components HTTP request open

both dialogue and node.tsx

and let's go ahead and see the problem.

So the problem is that we are passing

these default form values in three

separate props instead of just one. So

let's go ahead and fix this. The first

thing I want to do is modify HTTP

request node data and make it so that I

remove this last part. So we actually

never even used this. I just added it

here for flexibility.

Once we remove this, our HTTP request

node data matches exactly what our form

provides. An input for the endpoint, a

select drop-down for the method, and an

optional body. Now that we've fixed

that, let's also fix something in handle

submit here. No point in handling these

like that. We can just spread values.

It's much simpler.

Now let's go ahead and rename this form

type that we are exporting from here. So

we have to go inside of the dialogue

here and we have to find the form type.

And now I want to rename this to HTTP

request form values like this.

Once we do that, let's go back inside of

node and let's import it here. And now

just make sure that you use it here in

the values.

Now let's go ahead and let's modify our

props for the dialogue component. So go

ahead and remove these three and instead

add default values optional partial of

HTTP request form values.

Let's go ahead and make sure we use them

here as well.

Let's go ahead and modify the default

values here

to be this.

Let's just see default values is

uh let me just see the problem here.

Let's go ahead and give this an empty

object as the default. This way we don't

have to do the question mark thing.

Basically, we're just doing some

fallback here for a better user

experience. And we have to do exactly

the same for the form reset. So, let's

do it here as well. Perfect. And for the

dependency array, we can now just use

the default values.

Once we've done that, we can go back

inside of node and we can now simplify

this a lot. So we can now just pass

default values node data. As simple as

that.

That's the first task finished. Let's go

ahead and mark it as finished. There we

go. So the second thing we have to do is

we actually have to display the execute

button. So if you take a look at any of

your workflows, there is currently no

way of executing them, right? For

example, I have this super simple manual

trigger and then I have an HTTP request

get post, whatever, it does not matter.

Uh but how do I even execute this?

Right? Even if I save it, nothing really

happens. So the first thing we actually

have to do is we have to show the

execute button. But we should only show

that if we have a manual trigger.

Luckily for us, we can do that quite

easily. So let's go ahead inside of

source. Let's go inside of features

editor components. And in here I want to

add a new component called execute

workflow button.tsx.

I'm going to go ahead and import

button

from components UI button. I'm going to

import flask

icon from lucid react. And then I will

very simply export con execute workflow

button

like this. I'm going to create the props

here to be a very simple workflow ID

with capital ID.

Let's go ahead and extract it here. And

then I'm very simply just going to

render set button with a text execute

workflow. And with the icon we imported

from above, let's give the icon itself a

class name of size four. Let's give the

button size of large. Let's give it an

on click of an empty arrow function and

disabled to be explicitly false so we

remember to change it later to something

dynamic.

Now that we have this, we can go ahead

inside of editor.tsx.

And in order to render this dynamically

we first have to create a constant has

manual trigger. And let's do use memo

here so it doesn't rerender too often.

So, make sure to import this from React.

Let's go ahead and fill the dependency

array with nodes because that's what

we're going to be using here.

So, let's do return nodes dot sum node

node.type

matches and let's use our enum from our

Prisma schema node type which we can

import from at generated Prisma dot

manual trigger.

So just make sure you've imported the

node type.

Let me just show you from generated

Prisma. And now that you have the has

manual trigger, you can go ahead and dup

uh duplicate this panel

and use the has manual trigger boolean

to render in a position of bottom center

our new

execute workflow button and pass in the

workflow ID prop. You should have the

workflow ID here. So this should work.

Let's fix this by using center. There we

go. And now you will see that every time

that I have a manual trigger, I also

have the execute workflow button. If I

delete it, it gets deleted as well.

Since I didn't click the save button

even if I refresh, it's still here. And

the execute workflow button is here.

Perfect. So that's another thing that we

can check off. Let's go ahead and just

do that. And now we actually have to

create the execute inest function

because right now clicking on the

execute workflow does not do anything.

Let's start with first defining the

background job. So we're going to go

ahead and revisit our source features.

My apologies source inest functions.

And let's go ahead and remove all of

this here because we're no longer going

to need it. So all of this generate AI

sentry all of it and we can remove every

single thing within the actual step even

the return. Now let's go ahead and

rename this from execute to execute

workflow. Let's go ahead and change the

ID here to be execute-workflow.

And for the event let's follow follow

the structure workflows/execute.workflow

workflow

like this. For now, this doesn't have to

do anything. We can just do await steps

sleep. Let's call this test and 5

seconds.

Perfect. Now that we have the execute

workflow, we have to also revisit our

app folder API in justest route.ts.

Let's import execute workflow here. Copy

it and simply paste it here.

Perfect. That should resolve the error

that just appeared.

Now let's go ahead and revisit our TRPC

procedures, more specifically the

procedures for the workflows. So instead

of the workflows server routers.ts

let's go ahead all the way to the top

here and create execute. It's going to

be a protected procedure.

It's going to have a simple input

which will simply receive an ID which is

a type of string and it's going to be a

mutation.

The mutation itself will have an

asynchronous function. So let's go ahead

and prepare it like that. And let's also

prepare the input and the context.

And now what we can actually do here is

super simple. We don't have to use the

input or the context. We can just go

ahead and uh first fetch the workflow by

using await prisma dotworkflow.findique

or throw. And I know I just said we

won't use the input. My apologies. I

just got an idea that we actually do

have to fetch the workflow. So let's do

it while we are here. ID will be input

do ID and user ID will be context out

user ID.

Perfect. And let's return the workflow.

And now in between those two, we're

actually going to await inest. So, make

sure you import inest from ingest client

dot send

id and let's go ahead and quickly remind

ourselves the ID is actually the event.

So, let's copy that and paste it here.

And I think we have to define the data.

Uh I maybe I'm forgetting something.

Just a second. Let me uh remind myself

of how I'm executing.

So it is injust send and this should be

name. There we go. Yes, that makes more

sense like the event name. Uh and then

we don't even need the data. So just a s

super simple execute procedure which

just calls a background job. We actually

did this already when we explained

background jobs. Now let's go ahead

inside of features workflows hooks use

workflows

and let's find let's copy use update

workflow. Let's paste it. Let's rename

this to how uh hook to execute a

workflow.

Use execute workflow.

You don't need the query client. So you

can remove it. You don't need any

invalidation.

This will be executed and this will be

failed to execute.

And this will use workflows.execute.

Make sure to modify this. So on success

has the data and data name because in

our routers for the workflows, we return

the fetched workflow. So if you don't

return the fetched workflow, you will

see that this will fail because it won't

have any data. So make sure you return

the workflow from our new execute

procedure here. Perfect. We now have use

execute workflow. Now let's go ahead

inside of our execute workflow button

which we started developing here. Let's

define the hook const execute workflow.

Use execute workflow. You can import it

from features workflow hooks.

Let's do con handle execute or handle

submit however you want to call this.

And let's just do execute workflow

dotmutate

and pass in the ID workflow ID.

Let's go ahead and modify the on click

to call handle execute and modify the

disabled to be execute workflow is

pending.

There we go. Before you start this, make

sure that you have both inest and nextjs

running. So I am doing this by using npm

rundev all because I've set up mroxs but

in your case you can either use I think

we also defined some package json

scripts here. Let me just quickly see

yes uh perhaps you can use inestdev or

if you didn't set that up you can always

just use in cli with nbx like this. All

of them will work. Perfect. So just make

sure you have all of them running here.

I will now refresh my nextjs. I will

refresh my injest development server and

let's go ahead and check it out. So I

have no runs running and when I click

execute workflow I get a success message

and I have something running and it's

just a sleep test for 5 seconds.

Perfect. Which means that we now

officially have something happening when

we click on the execute button. Perfect.

But right now what we should be focusing

on is this function.

So it needs to somehow fetch the

workflow that's been executed. It needs

to fetch all of its nodes. It needs to

sort them topologically and then it

needs to run a specific type of request

depending on the type of the node. So

those are our next goals.

Let's start by first checking if we have

enough information to even fetch

something. So inside of execute workflow

go ahead and do const workflow id

event data doworkflow id and if we have

workflow ID missing throw new

whoops let me fix this throw new non

retryable error make sure to import this

from inest so when you throw this error

inest will not retry this is because

there is nothing to try if workflow ID

is missing. So just workflow ID is

missing. As simple as that. We can't

proceed further. We have no idea what to

execute in this case. Let's not waste

any resources here. So if you go ahead

and try now this should fail. If I click

execute workflow here, there we go.

Immediately it fails. And you can see

there is just a single attempt and no

retry workflow is missing. So if you

didn't use non-retriable error, if you

just threw a normal error, you will see

that it's a different behavior. So let

me go ahead and click this. You can see

it's running, it's failing, and it will

now continue to attempt to do this for

the next three times for no reason at

all. Right? We know if it's missing

once, it's going to be missing for the

next three attempts as well. Perfect.

Now that we have that, what we are

supposed to do is we can finally get rid

of this and we can instead do const not

node and let's go ahead and do await

step.r run prepare workflow and let's

open an asynchronous function here.

First things first, let's fetch a

workflow with await prisma workflow.

Uh, of course, let's import prisma from

lib database. Prisma.workflow workflow

find unique where ID is workflow ID

and let's also

add includes

nodes true connections true

and if there is no workflow let's throw

new non retriable error workflow not

found so that's why I didn't use find

unique or throw because this will just

restart the query. Uh now you could

decide for yourself if find unique I

mean yes technically this could fail if

maybe the database is unreachable.

So maybe we shouldn't exactly throw uh

unreachable. Yeah, maybe we can do find

unique or throw here and then it will

just you know if the database is missing

I mean if the database connection is bad

it can it will just retry. Maybe that's

actually a good thing. Yeah, let's keep

it like that. And now let's just do

return workflow

nodes. As simple as that. Like we just

want the nodes and let's go ahead and

return nodes.

Perfect. So a super simple uh execution

here. Now let's just modify our execute

here to actually pass that. So data

workflow ID will be input do ID. Make

sure you don't misspell workflow ID.

It's used like this.

Let's go ahead and try it now.

So I'm going to uh let me just try and

refresh here.

And now I will just click execute

workflow and let's see what's going on.

So prepare workflow finalization. Let's

try and open this. Can I close the

sidebar? I can. Perfect. And here we go.

We should have two nodes. First one is

the HTTP request and the second one is

the manual trigger. Perfect. Amazing.

That seems to be working just fine. Uh

what we should do now is we should

somehow sort these nodes. Why do I say

we have to sort these nodes? Well, look

at it. Okay, this is super simple

right? We can just sort by date of

creation in a linear example. But what

if we branch out? What if we do this and

this? Right?

So that's why we need to use topological

sort. So it can handle this type of

branching.

For now, please keep it simple like

this. So you can have similar results as

me right?

Let's go ahead and work on the

topological sort. Now, so uh in order to

do that, we need to have one helper

package installed called topo sort.

There's a bunch of these packages which

help for this, but I found this one to

be the simplest to use.

And once you have that installed, let's

go ahead and go inside of the inest

folder and create the utils.ts.

Let's import sort from topos sort.

Uh looks like we also need the types for

it. So let's go ahead and just install

the types.

mpm install save to development

types topo sort and let's wait a second

perfect let's export const topological

sort

let's go ahead and accept first

parameter nodes to be a type of node

from generated Prisma and the second one

connections

connection from generated Prisma and an

array and it will return node like this

array of nodes. So first things first if

no connections return node as is meaning

they are all independent.

So let's just return my apologies. Let's

check if connections.length is equal to

zero return nodes. So what is this

example here? Well if this didn't exist

can I remove a connection? I can. to

this right these two are not connected.

So if we try executing them well

obviously you can decide for yourself

what should happen should anything even

happen in this case maybe not maybe you

should just throw an error right but

we're just handling that case for now

right if no connections let's just

return back the nodes there's nothing we

can do right we have no idea what is the

actual connection between these nodes

otherwise let's go ahead and create the

edges array for topo sort const edges

is going to return a matrix. So string

string like this connections do map

and then get the individual connection

and return an array like this

and in here in the first one use from

node ID and the second one to node ID.

Now let's go ahead and let's add nodes

with no connections as self edges to

ensure they're included.

So con connected node ids will be new

set with a type of string.

And let's do a simple for loop here for

connection of connections.

Connected node ids dot add connection

from node ID

and then another one to node ID.

Now let's go ahead and do a simple for

loop over our nodes. for node of nodes

if not connected node ids has a node id

let's go ahead and push it to our edges

array edges push and open an array

inside

pass in node do ID and node do ID inside

so this are connections as self edges

and now let's go ahead and finally

perform form the topological sort.

Let sorted node ids return a string.

Let's go ahead and click try. Sorted

node ids are going to be topo sort pass

in the edges.

Let's go ahead and remove duplicates

from self edges. So that's this part

here.

We're going to do that by simply

returning a set sorted node ids

new set sorted node ids. Otherwise

let's go ahead and catch an error. If

error instance of error

and if error dot messageinccludes

cyclic.

Uh, make sure you don't misspell this

like me. Cy click. So if this happens

it means that this

type of node array that we received and

their connections are cyclic. Meaning we

cannot create a linear sort from them.

So because of that we need to throw new

error here. Workflow

contains a cycle

as in something is wrong. This is not

linear. We can't actually do this.

Otherwise, just throw that error back.

And now finally, let's go ahead and map

sorted ids

back to node objects.

So, const node map new map nodes map use

a shortand constant n and return an

array nid

and n itself. And finally return sorted

node ids dot map get the ID and return

node map.get

ID

use uh an exclamation mark here for a

non null assertion fix

and then do dot filter boolean

like this. If you have biome turned on

this will most likely give you a

warning. Uh this is fine. We're not

going to have too many of these cases

but in this one, uh it just helps

simplify the code. So now our nodes and

their edges should be sorted, right? The

only exceptions are if we do a cycle

which shouldn't be able to happen

because we should never be able to do

this and then this, right? You can see

how our UX does not allow us to do this.

That's because on the triggers, we

removed the edge here. So that cannot

happen. But still, even if someone's

somehow someone breaks that, we are

going to take care of it here by

throwing an error. So I think this is

okay now. Uh let's go ahead and try it

now inside of routers. I think that uh I

mean I'm not sure if this is a good

example. Maybe I'm not understanding

this correctly. But you can see that the

first node that was returned here was

actually HTTP request and then manual

trigger

when it's actually the opposite, right?

It should first be manual trigger and

then it should be HTTP request. But then

again, perhaps it just depends on how we

read this array. I'm not even sure. Um

let's just try it so we can actually see

inside of functions. Now

well, let's rename this entire constant

to sorted nodes like that. And let's

return sorted nodes here.

And now instead of returning workflow

nodes, we can do return topological sort

which you can import from dot /utils

pass in nodes as the first argument and

pass in connections as the second

argument.

There we go. So now we have that. Uh

let's go ahead and run this so we can

see if there are any differences. Now

just make sure you have a connection and

click execute workflow. And let's go

ahead and see. Perfect. No errors. And I

can already see the first node is manual

trigger and the second node is HTTP

request. Amazing amazing job. Uh

obviously we don't have enough nodes

right now to you know try

uh and create some complex scenarios but

you can try like something like this. I

mean, it will be very hard to debug if

it's actually okay or not because even

if I try and do this, it's just going to

look the same. It's going to be manual

trigger and after that everything will

be HTTP request. So, we don't really

know what was the order here really. So

let me go ahead and look here. Yeah. So

as I expected, manual trigger and then

just a bunch of HTTP requests. But at

least we can count the number of HTTP

requests. So one

two, three. I think I counted three. 1 2

3. Meaning all of them are now

considered in a linear sense. So we can

now go ahead and map over those sorted

nodes and we can execute each of them.

Perfect. So even though we kind of

branched out, we uh made sure to have

all three in our new array. Perfect. So

at least that works. And now that we

have topologically sorted our nodes

what we have to do is we have to execute

each node depending on their type. So

we're going to wrap this chapter up by

kind of preparing that registry of

executors that each node will have for

itself. Basically the way to execute in

its background job.

So before we return sorted nodes, let's

go ahead and initialize the context with

any initial data

from the trigger. Now this doesn't make

too much sense, right? Because I'm about

to do let context

to be event

dot data dot initial data or an empty

array uh an empty object because we

never actually pass this. Now right you

can see where we call it we execute it

right here await inest.end.

So what should we really pass in the

initial data here? Well in this specific

example where we have a manual execution

absolutely nothing. That's why this is

optional. But to give you a better idea

of when this will be populated with

something imagine a web hook trigger or

a Google form submission. Those are the

types where we are going to also execute

this job like this. But since it will be

within a web hook, we're going to have

some payload there. And then we will be

able to do initial values and just pass

in uh or initial data, however I named

it, right? We're just going to do

payload

data, right? Something. And then we will

be able to run our executors with that

initial data. I'm kind of trying to

explain how this will be used in the

future. Uh if it's confusing you, don't

worry. It will make more sense once we

actually implement uh Google form

submission or something like that. So

now let's execute each node here

for con node of sorted nodes.

Let's go ahead and first get the

executor. So for each node we need to

get its executor. get executor a

function which does not exist yet and

pass in node.type type as node type here

from generated Prisma.

And now we have to develop the executor

registry. So I'm going to develop that

inside of features executions.

Let me create a new folder called lib.

And in here executor registry.ds.

Executor-registry.ds

looks fine.

And let's go ahead and export const

executor registry

like this. It's going to be an object.

And let's give it a specific type here.

Record. The first argument will be node

type. And for now, let's just make the

second one unknown. Import this from

generated Prisma. And now you will have

to use node type and then put for

example manual trigger. And then this

will be the executor. Then node type dot

initial and that will have its own. And

then node type dot uh http request and

that will have its own. So that is the

point right. We are now going to go

through each of our nodes and depending

on their type. Uh so we just did export

const executor registry. Let's now do

export const get executor

type node type

unknown

const executor

is equal to executor registry

type

if there is no exeutor found in that

object above throw new error and let's

be specific so open back takes no

executor found for node type

and let's just pass in the type

and return the executor.

There we go. And now we can use the get

executor here

from features executions lib executor

registry. Uh not too sure if that's like

the best place to put it but kind of

makes sense, right? executions executor

registry I guess I don't know and now

that we have here uh the executor let's

go ahead and let's do context

await executor

open an object here and pass in data to

be node data as record and string

unknown

pass in node id to be node dot ID

context, and step.

But now we have a problem. So this

executor is a type of unknown because

obviously that's what I've typed here.

So let's go ahead and give it a proper

type instead. So let's stay inside of

features executions here and let's go

ahead and add types.ts

here.

Let's go ahead and import

get step tools from ingest and ingest

itself.

And we can limit this to be types. Let's

export type workflow context to be a

simple empty object. So string unknown.

Then let's export type step tools to be

get step tools inest any.

Let's export interface node executor

params

to use a generic t data which is a type

of record string unknown because it can

truly be anything that we are going to

pass in these nodes right their data

will be able to be anything okay fifth

try on the unknown and I still don't

know how to spell it unknown there we go

so give it a type of data t data which

is just anything right for example in

HTTP request node this will be uh an

object with endpoint body and method uh

then in stripe it's going to be well

stripe is a trigger so it's a bad

example but in open AI node it's going

to be system prompt and user prompt and

model in anthropic it's going to be

similar right uh in I don't know any

other node that you create it will be

its own type so basically the data

which is this dynamic thing represents

whatever we have in this dialogue here

which can be anything depending on the

node that's why it makes no sense to do

any strict definitions of it

then let's do node ID so we know exactly

which node we are working with here

context workflow context which again can

be anything because the context will

simply expand as each node progresses

because we will be able to use the

context of the previous node into the

next node. So again, we can't really

define that. We have no idea what nodes

will return. What will this HTTP request

return? We don't know. Maybe it will be

a JSON. Maybe it will be a string. Maybe

it will point to an API. Maybe it will

be an error. We don't know. That's why

it's uh defined as this.

And let's do step step tools

later. We are also going to have publish

here, but I'm going to comment this out

and just do to-do add real time later

because we don't have that now. And

finally export

type node executor

t data

equals record

string unknown.

Okay. Unknown

params node executor

params

t data

and return promise

workflow context.

All right, very complicated, but that's

all the types we need. Perfect. We can

now head back inside of the executor

registry here and we can modify this

unknown to be node executor from dot dot

/types

which obviously means that all of these

are now going to fail but let's also

change this unknown to be node executor

and now we have to develop proper

executors here so for now I'm going to

just focus on the manual trigger here

let's go ahead and find where it is. So

it is inside of uh features triggers

manual trigger right here. And this one

will be super simple. So inside of

manual trigger create a new file

executor.ts.

And let's go ahead and import type

node executor from features executions

types

and export const manual trigger executor

give it a type of node executor

and inside of it we just need a empty

object. So this can for example be

uh let's go ahead and call it type

manual trigger data record string

unknown

like this and then just pass in that

here

open an asynchronous function here

like this there we go now the params

which we're going to have are data node

ID context and step. So exactly the ones

which we just defined here data node ID

context and step for the manual trigger

the data will not actually exist. So you

can already remove it. I just wanted to

show you type safety works here. Let me

add to-do publish loading state for

manual trigger because we don't have

real time yet. But to-do that will be

the first thing we're going to do here.

Otherwise, let's just do const result

await step.r run manual trigger and a

very simple asynchronous function

which simply returns the context. So

basically this will be passed through as

in there is nothing to do in here. Just

go to the next node and let's do todo

publish. Whoops.

Success state for manual trigger. So

after we succeed, just go ahead and

proceed.

There we go. And return this. And now we

have our first executor, manual trigger

executor. Let's go ahead and use it

here.

There we go. Uh now obviously I think we

have uh some problems here. We didn't

add initial or HTTP request. Uh, so can

I maybe just do like partial?

I I want to find a way of not having to

add every single one of them here like

node type dot initial and then I have

to, you know, think of something node

type

HTTP request, right? You can just add

all of these right now to get rid of

type errors. And now for each node that

we have, we're going to have to develop

their executor. And this way we kind of

have like a big switch case inside of

our where is our inest folder functions.

So basically each of those topologically

sorted nodes are now going to get their

executor and then we're just going to

execute it. And for each of them we're

going to extend the context even more.

Right? So if the first HTTP request node

returns some JSON, the second HTTP

request node will be able to access that

context and that's what users will be

able to define using these variables. So

the users will be able to use HTTP

request dot users or todos, right?

That's how that's going to work.

Perfect. So now we have this um not sure

if we are like ready to try this. Well

here's what I want you to do. I want you

to copy this executor here. Copy it.

Go inside of executions components HTTP

request and paste the executor here.

Change this from manual trigger data to

HTTP request data. This will be HTTP

request. HTTP request

executor and change these instances to

be for HTTP request and step.r run HTTP

request

and let me just quickly compare this

with my source code.

So

uh we are kind of right. Let's call it

okay. Yes, I think this is okay. We can

now go inside of executor registry and

just change this to be HTTP

request executor and um okay yeah we're

kind of mixing features.

Uh yeah I kind of don't like that we

have the executor registry in the

executions folder and then we have a

specific exeutor in the manual trigger

uh in the features triggers. H it's kind

of spaghetti going everywhere. But let's

leave it like this for now. Just make

sure you can import them. And yes, the

initial will actually never happen. But

we have to add something here just to

satisfy the type errors here.

And now if we actually try I think this

should work just fine. Uh the only thing

we ought to modify is what we return

here. So what we should actually return

is the following.

We should return the workflow ID. We

should return the result as context

because the context will be fully

modified by the end of this for loop.

Even though right now nothing will

really happen because we just return

back the context and go to the next

node. That's the only thing we do right

now.

So let's go ahead and try it now. The

only thing we should see now is I think

one, two, three, four. We should see

four steps now happen when we execute.

So right now we had one step. This one

doesn't count. This is finalization. Now

we should see four steps, one for each

node. So make sure to click save here.

And then let's go ahead and try and

execute. So let me just see. Okay, fully

saved. execute workflow and let's see

prepare manual trigger HTTP request HTTP

request HTTP request perfect amazing

that is exactly what we wanted and if

you remove one and save

now it should have three steps so let's

try this again manual trigger HTTP

request HTTP request so yes not counting

the preparation one just these ones

perfect you can now see that Our

workflow background jobs has exactly the

amount of steps in the exact order as

the their graphical interface here.

And now to end the chapter, let's

actually make an HTTP request node fail

or succeed. So keep it simple for now.

Just do a very simple connection between

a manual trigger and an HTTP request

node. And for the first example, don't

configure it at all. As in this should

say not configured. Don't pass any

endpoint URL. Don't do anything at all.

And let's focus on the HTTP request

executor. So the first thing I want to

do is I want to uh define proper HTTP

request data. So I'm going to go ahead

and define endpoint to be an optional

string. I'm going to define the method

to be an optional string. Body.

And that's it. So basically the exact

thing that's inside of Let me go ahead

and try and find node.tsx

http request node. There we go. This

basically so yeah perhaps the method

should be this.

Perfect. So we are kind of passing now

to the back end what are the possible

options for this HTTP request. And now

that we have that, we can actually bring

back data from here

because once we have the data, uh we can

actually do something with it. For

example, before we do the result, let's

go ahead and check if there is no data

dot. As you can see, we now have

completion here. If data endpoint is

missing to do, let's do publish error

state for HTTP request. But what we can

do is throw new non retriable error

here. HTTP request node no endpoint

configured.

So just throw that error. And I think

that already if you try this now this

should fail. So just make sure to save

this super simple example. Make sure

this is not configured. And once it is

saved let's go ahead and execute it. And

now we should see this fail. Okay, it's

running. And there we go. So what

happened? Let's see. HTTP request node.

No end point configured. So exactly what

we expected. The only thing that's

missing is visual feedback which we are

going to be working on later.

Now how could we uh do a request? Well

we could do a request by using await

step.fetch and using data endpoint here.

That is one way of doing it. And then we

could get const result like this.

Let me go ahead and do this and just

return result. You can actually remove

this. There we go. That's one way of

doing it. So if I go ahead and try try

and change this to httpsc

codewithandonia.com Google or something.

Maybe this is a bad example. Maybe this

will fail now because this will return

text instead of JSON. But let's just see

if, we, will, at least, see, step.fetch., Here

it is. Step.fetch is now happening. So

you can of course use uh inest builtin

uh step.fetch. And you can see the

output here body right. So, you can use

that. Uh, but I kind of found it easier

to use uh a bit more I'm not sure what

should I use to describe it. Not exactly

advanced because here's the thing.

Step.fetch is a wrapper around normal

fetch which we all know and love. But we

also know there are certain limitations

with it, right? It's quite hard. I mean

hard. it takes a lot of code to do a

super simple post request with it. So

for that reason, I recommend that you

actually do npm install ky

which is like a lightweight alternative

to ax. So let's import ky from ky

obviously. So if you prefer axius, you

can do this with axius. If you prefer, I

don't know

step.fetch, you can just use a

step.fetch, right? So this is what we're

going to do now. I'm going to go ahead

and do result. And instead of stepfetch

this will be step.run

http request. And this is why I also

prefer using my own kind of fetch

execution so that I can have a step.r

run independently like this.

And inside of this, I'm going to go

ahead and do const method to be data do

method or I will fall back to get

method.

Maybe I can even stop doing this all the

time. It's getting a little bit annoying

and I can just throw an error if method

is not defined because it it is getting

a little bit annoying right now. And

then what I'm going to do, let me just

define const endpoint to be data.point

end point like this because at this

point I think I can uh can I yeah I'm

just going to do this this will also

throw you a warning if you're using

biome or any llinters but just leave it

like this for now so we're doing a non

null assertion here because we know that

at this point data don't endpoint will

exist

and now I will define options to be

method like this options will be a type

of KY options.

Uh KY options where can I import that?

Okay, so KY

import type options as KY options.

Perfect.

And now that we have this, let's see if

we should also attach the body property.

So if open an array post put patch

includes

method

if we have data.body

options.body

is going to be our data.body.

The reason I'm doing this inside of an

if clause is because uh we are going to

first uh uh it's a bit hard to explain

but the way we will be able to write

this is also using variables.

So if instead of post method here you do

this HTTP response data id you have to

parse that here. We are not going to be

doing that now simply because it's

unnecessarily complicated. But let's

just leave it like this for now.

Um

yeah, let's let's just do this. Okay

simple as that. And then let's do con

response here. Await ky endpoint and

options.

And let's go ahead and do const response

data to be await response.json JSON

catch

response dot text.

And finally

let's go ahead and let's return

spread the context and do HTTP response

here. status response status status text

response status text

data

response data

and um

well I think this might be enough for

now and this will actually fail if you

try to fetch something that's not

returning JSON so instead what you can

do is you can check content uh Okay

const content type here is equal to

response headers.get

content type and then in here check if

content type question mark includes

application forward slashjson

then do await response.json

otherwise do await response.ext text.

Perfect. So now we can use the response

data as the actual data here.

All right. And I think

that should work just fine.

So let's try it out now. So I'm going to

go ahead and just make sure this is a

get request pointing to my website here.

I will click save and then I'm going to

execute the workflow. And basically I'm

not expecting much to change except in

the finalization step in the result I am

expecting this right the body the

headers I'm expecting to see that in the

finalization step here. So let me click

execute workflow

and let's see did I develop this

correctly or not. Perhaps I made some

mistake in the KY implementation.

Uh there we go. finalization now has the

result from the previous HTTP request

node which has the data for my I mean

this is useless in a sense that we are

not fetching any API we are just

fetching

HTML so let me try and just find you a

nicer example to make this make more

sense

so there is this public API that you can

use json placeholder typiccode.comtodos

forward slash one. So let's just use get

save here.

And after you've saved up here, let's go

ahead and execute workflow. And now we

should have a nicer response here.

It should be in a form of JSON in the

finalization. Here we go. The HTTP

response now has data. And in here we

just have some mock to-do completed

false ID one title something user ID

something we have status we have status

text basically exactly what happened

here but here's the thing if you I'm not

sure how this will now behave but if you

try and map like two HTTP requests now

and let's go ahead and just copy this.

Oh wow I I think I just did the circular

thing. Let's remove that. Okay, that

would definitely fail. So, go ahead and

put number two here. Get request. Save.

Click save here. And now, technically

we should have two objects with the name

of HTTP response. So, that could

technically fail. I think that this

might actually cause an error. I'm very

interested to see what will happen

because okay, it completed. So two HTTP

requests happened. You can see one with

an ID of two, one with an ID of one. So

what I think Oh, it just over over.

Yeah, we just get the HTTP response of

the second one. So it overrides the

first one. That's not good. We should

think of a solution to allow the final

step to have the data from multiple HTTP

requests. We can do that quite easily

but by maybe introducing a third field

here called variable name and then you

will have the exact variable name that

will be used here in the result and then

the user will be responsible for making

sure that they don't override

themselves. Uh but I think that's why I

wanted you to just use this super simple

example so you don't run into th those

kinds of issues. So you can see that

there is still some work to do here but

I think you kind of get the idea now

right each of our nodes now has a

topological order uh and it has its own

way of executing so in in this specific

HTTP request it's quite simple right but

when later when we create open AI

instead of doing this we're going to

check do we have a user prompt if we

don't throw an error user prompt is

required And instead of doing uh a fetch

request, we're just going to be doing an

open AI request and returning back

something.

So that will be uh the way we're going

to move forward. So let me go ahead and

check. We created the execute inest

functions. We did the topological sort

and we created the executor registry. Uh

amazing. Uh and yeah inside of our

executor registry we have one which just

kind of passes through this is the one

inside of triggers manual trigger

executor. So yes this executor doesn't

do absolutely anything besides have its

loading state and its success state

which is purely used for user

satisfaction. So they can see that

something is happening right? Even

though this will immediately show

loading and then immediately show

success like there is absolutely nothing

happening here we just kind of make sure

that the context gets passed further. So

we can also even remove node ID. I think

I think we don't even need node actually

we will need node ID later for the

loading and success states. But I think

that this is enough for this chapter. In

the next chapter we are going to solve

two problems. We're going to solve the

problem of our HTTP request nodes

overriding themselves and we're going to

start to do this. So instead of doing it

like this, we will be able to do I don't

know uh previous node dot id right you

will basically be able to use the

context of your previous nodes. So think

of it like this let me show you instead

of inest development server. So this

http response now returns user ID 1 or

ID2 or title or something. What if you

wanted to use that? So you would do HTTP

response dot user ID, right? That's kind

of the goal that you are able to use the

data from one node into another node.

That's what we're going to be focusing

into the next chapter. So for now, I

think this is enough for us to get

introduced into this execution thingy.

So 18 node execution.

Let's go ahead and commit all of these

files here. So I have 15. You might have

16 again if you have that MROS log file

here. Otherwise, this should be it.

Uh staged all changes. Before I commit

I'm just going to go ahead and click on

main here. Create a new branch. 18 node

execution.

There we go. So now I'm in this new

branch. I have staged my changes. 18

node execution. I will click commit and

then I will click publish branch.

Now that this branch has been published

I'm just going to go ahead and open the

pull request.

So I'm going to click compare and pull

request and create pull request 18 node

execution. And now let's go ahead and

review our changes.

And here we have the summary by code

rabbit. New features. We added an

execute workflow button in the editor

when a manual trigger node is present.

We introduced workflow execution from

the app via a new action and hook. We

enabled the HTTP request nodes to

perform real requests and return

response data. And we of course refactor

the workflow runs now follow dependency

order meaning the topological sort with

improved orchestration and a unified

context result enhancing reliability and

clarity of outcomes. as always file by

file walk through here. But here is the

sequence diagram that uh interests us

the most. So let's go ahead and try and

follow it. So when the user clicks on

execute workflow, we call the TRPC

mutation with a workflow ID param.

We then call uh workflows. Okay, so this

is the actual TRPC uh execution. And the

only thing this does is it sends the

event workflows execute workflow.

Immediately we return back the workflow

with a success message to the user. Uh

okay. And what actually happens here is

the background job. So uh we uh let's

see we trigger the function with the

event. We load the workflow its nodes

and its connections. We return that data

and we map it to the topological sort

function and then topological sort uh

gives us sorted nodes and we can then do

the for loop for each of that node and

we can find the appropriate executor for

that node and execute it and return the

updated context along. Great. So that's

exactly what we are doing. We do have

some comments here. So let's go ahead.

First one is in the HTTP request

dialogue here. So I changed from three

individual props to just one. And in

here it says destructure and depend on

specific form methods instead of the

full form object. Uh okay I will look

into that.

Now in here it is telling me to do

appropriate error handling for KY

package. We will work on that in the

next chapter where we improve the entire

HTTP request executor itself.

Same here. So yes, we completely forgot

to pass the option headers which will

lead to uh some servers to reject the

request again. This will be in the next

chapter where we improve the HTTP

request exeutor allgether.

In here uh it is telling me to improve

the way I handle errors in case I cannot

find an exeutor for a certain node. Uh

yes, so I could look into doing this. I

think it's fine as it is, but yeah, it

wouldn't hurt to have even more strict

checks here. I will look into that as

well. Uh same thing for this. So I think

the error message is cyclic, but in here

it's telling me is cycle. So I will just

look at the source code of toposort or

documentation and see which one of those

it is. And in here, yes. So I told you

that we can use the nonnull assertion

here with the exclamation point. So in

here it suggests not doing that and

instead just quickly checking if a node

is missing and throw an error. Perhaps

that is safer. Yes, we could do that. Uh

okay, amazing suggestions from code

rabbit. I will take a look at them and

for the next chapter maybe prepare a few

that I think are important so we can

proceed. But for now, let's go ahead and

merge this pull request. Amazing job.

This was a complicated chapter. Let's go

back inside of the main branch and let's

make sure to click on synchronize

changes and okay. And let's go ahead

inside of our source control. Open the

graph. And in here we should now see 18

node execution. Amazing. That means

everything here is merged, which I think

means we are ready to go ahead and wrap

this chapter up. So, we pushed to

GitHub, created a new branch, created a

new PR, and reviewed. Amazing, amazing

job, and see you in the next chapter.

In this chapter, we're going to continue

our work on executing nodes by fixing

some issues we discovered in the

previous chapter.

Let's start by fixing the code rabbit

reported issue about our missing content

type header. and let's discuss the

cyclic error message that we decided to

look for whenever uh topos sort is

happening. So I'm going to go ahead and

open the previous pull request right

here. And this is the first suggestion

and it is completely valid. We have

forgot to add headers to our uh postput

patch request. So let's go ahead and do

that to ensure that our HTTP request

node can properly uh make those

requests. So what we have to do is we

have to find executor.ts

inside of features executions components

HTTP request folder. So let me show you

how that looks right here. Features

executions components HTTP request

executor.ts.

And in here when we decide that this

will be a postput or patch request

besides filling the body we also have to

do options. headers and let's do this

properly. options headers and we have to

add content dash type and in the type

will be the exact this one that we are

querying for later. There we go. This

will ensure that our postput or patch

request doesn't get rejected because

headers are an important part of an HTTP

request. Of course, great. So, that's

one thing resolved from our previous

pull request here. There are some other

things here such as validate node types

and data at runtime. Now, depending on

your personal preference, you can of

course do this. This is a good advice

but let me show you exactly where this

is happening. So this is happening

inside of our source folder inside of

ingest functions.ds.

So basically what it's telling us to do

is the following. You can see that when

we pass this node.ype

by default it doesn't have a proper node

type. So we have to cast it as such

right? Or maybe we don't even. Uh yeah

you can see that uh okay, it looks like

it's working, but still cold rabbit is

telling us to check at runtime if it's

actually a part of node type using this

and then throw an error if it's not.

Here's why we don't have to do that. So

first things first, I had no idea that

we don't have to cast it as node type.

So I'll have to retrace my steps to like

fully confirm that. But just for now, I

don't want to change my the code I've

written because I don't want you to have

any errors, right? So if you have this

leave it just in case. Uh and instead

if you go inside of get executor here

you can see what happens. So if that

type, which is a node type, does not

match to whatever we define in our

executor registry, we're going to throw

an error. So you don't really have to

worry about node type not being

compatible. So that's why I chose not to

do this suggestion right here. But of

course depending on your preference, you

might think this is a great runtime

validation. So you might do it. Same

goes from data which is later uh

retrieved from the executor constant.

For now I'm going to leave this as is.

And now let's go ahead and discuss the

other problem that we have and that is

key collision. So what is key collision?

In our previous example, we had this

type of

schema, right? Very simple. When I click

execute, I'm going to get this and then

I'm going to get that in my results. So

if I go ahead and visit my let me go

ahead and just find my injust server

here

8288. So I suggest you go here too.

Uh having some trouble clicking on it.

82

88. Here we go. Completed. And if you go

inside of finalization here, you will

see that the result simply says HTTP

response with data of ID 1 inside.

Uh that's pretty straightforward, right?

Because we have an HTTP request which

requests to-dos by an ID of one. If I

change this to to do two and if I click

save here and then if I click execute

workflow again I'm going to have another

request here finished and this time this

request's finalization

will be different

it will include the ID of two perfect

but what if I do this? What if I add

another HTTP request right after this

one? And if I change this

let's make this to be to-do one. Click

save. And change this to be todos two.

And click save. Save the entire

workflow. And then click execute again.

So what's going to happen now? So I will

have, as you can see, two HTTP requests

fired. But in the finalization block

you will see that I only have one HTTP

response

only. ID2, which means that this one was

completely overridden. You can see that

and prove that by going inside of these

individual ones. You can see that the

first HTTP request topologically called

the to-do with ID of one, but the second

one called with to-do two. But both of

them have the se same value here http

response which means that in the

finalization block only the last one

gets written.

That's because we have a key collision.

So now let's go ahead and fix that. Uh

and yes there is this thing right here.

So cyclic error message. So code rabbit

told us to double check if that's the

correct one. So instead of my utils in

the source inest folder. Yes, this is

correct. I went into the source code and

I can confirm that this topos sort

library here throws an error message

which includes the word cyclic not

cycle. So this is correct. Just wanted

to resolve that because I think I

promised that it will resolve it. And

now we have to fix this bug that we

have. Right. Basically it's not allowing

us to chain our HTTP requests. In order

to do that, we're going to have to

introduce a new field to UI. So each of

our nodes besides having a method

endpoint URL, right? Those specific

things for it itself, it's also going to

need to have a variable name. And I

suggest we add that as the first field

in every node that we have because it's

going to be a very important one and

it's always going to be required. So

let's start from the UI side and work

our way into the executor and finally

assigning it to the context.

The first component I want to go in is

node.tsx.

So let's find it together. So we refresh

our knowledge. Uh it is inside of source

features executions components http

request node.tsx.

So besides having an endpoint, method

and body, we are also now going to have

variable name

like this. The reason we are making this

optional is not because it's optional.

It's because it will not be added at

some point, right? So we cannot always

uh rely that this will exist. It will be

required for executing the node but it

will not be required as the initial node

if that makes sense. Right? So user will

have to add this later.

Uh and once we have this variable name

uh what we can do with it is well we

don't have to worry about it too much

because you can see it's automatically

going to be spread here. It will

automatically be passed here in the

default values because we refactored our

code previously. But maybe we can

improve the description so the user can

visually see for example right here in

this HTTP request node. Perhaps we can

add some kind of variable name here.

That's like one idea I have. I'm not

sure. Maybe later. Let's Let's leave it

like this for now and then we'll see.

Now that we have the variable name, we

can go ahead and safely go inside of

dialogue.tsx.

And now we have to modify our form

schema. So our form schema now needs a

new field called variable name.

Let me fix it. Variable name is going to

be a type of string. Now, we can just

leave it to be any type of string, but

it needs to be a type of string that

will be compatible with a JavaScript

object, right? So, it should not be able

to be something like this. I think I

think this might not be valid or maybe

it is because whitespace is valid. But

basically we want to make sure that

whatever uses writes inside uh will not

throw any runtime errors when assigned

to the key value of an object. So

because of that we're going to add some

J uh some reg x to validate that. So

zstring like this after string let's go

ahead and make it required.

Let's give it a message variable name is

required.

And then let's add a reg x. So I'm just

going to copy the reg x so you don't

have to see me type it here. And let's

go ahead and make sure that we have an

error message

if it's not applied.

Variable name must start with a letter

or underscore and contain only letters

numbers, and underscores.

like this. So, this isn't an unknown

regax. It's you can find it quite easily

on Google. Basically, it does exactly

what the message says. It allows capital

and non- capital letters as well as

numbers from 0 to 9 with the exception

of a dollar sign because that's also uh

valid to be inside of a JSON object.

So I think this is good enough. You can

of course you know for yourself research

if you have a better reg x but I think

this will work just as well. Now let's

go ahead and let's add it here in the

default values here. Variable name will

be default values dot variable name or

an empty string.

Same thing in the form reset default

values variable name or an empty string.

And now what we have to do is we have to

add a form field for it. So let me try

and find the simplest one. I think

that's this one, the endpoint URL. I'm

just going to copy it because it's very

simple. And I'm going to add it above

the first form field because we said we

want this to be the first one. I'm going

to change the name to be variable name.

And I'm going to change this to be

variable name.

And the placeholder can be whatever we

want. For example, my API call.

Basically allowing the user to know

hey, you can name this whatever you

want. And in the form description

um, let's go ahead and describe

something like this.

Use this name to reference the result in

other nodes. Then I'm using this to

create a space. And then I open an

object so that I can do double curly

brackets because that's how we're going

to do templating. For example, my API

call HTTP response data and the

placeholder here is the same. So if user

names this test later in other nodes

they will be able to do test.httpreson

data. Perfect. So now once we do that

if you go ahead and open an HTTP

request, you should see a variable name.

And I just got a really cool idea. If we

change the variable name, maybe we could

also change the description to make it

even clearer to your users what this

will be used for. Let's see if I can do

it very quickly. So just as I did this

let me go ahead and do const watch

variable name form watch variable name

like this. And then in here in the form

description, let's see if I change this

to back ticks. Whoops. Change this to

back ticks.

And if I specifically do this

watch variable name

and maybe make this

fall back to my AI call

so it looks better.

There we go. Exactly what the variable

name is. That's what the user will see.

So it will be easier for them to

understand how they're going to use this

later in other nodes, right? So test or

if nothing is written, it's just going

to use the placeholder one. I think it's

cool. And if I save, it should give me

an error because variable name is

required. So let's go ahead and call

this uh my API call one like this. And

let's click save. And let's do this one

uh my API call 2. And let's click save.

There we go. So now we have different

variable names for two identical uh

nodes with of course different endpoint

URLs. So what we have to do now is we

have to use that variable name inside of

the actual executor.

So uh first things first

well at first things first and well last

things last we have to go to the

executor. So features executions

components http request executor.ts DS.

And now let's get inside of the HTTP

request data and let's go ahead and

let's add the variable name.

Again, it's going to be an optional

string.

And what we're going to do is well, you

can define how strict you want to do be

with this. I would personally be as

strict as if we were missing an

endpoint. Right? If there is no variable

name, it's a nonretable error. Right? So

let's remove this to-do right here.

Actually no. Yes, we also have to

publish the error state for this. So

nonriable error variable name not

configured

like this.

And now let's go all the way down to the

return method and we have to slightly

modify it. So let's go ahead and do

const response payload.

And let's go ahead and copy the HTTP

response from here. So basically our old

payload exactly as it is. And now we're

just going to slightly modify this by

spreading the context and instead of

storing this under HTTP response, let's

store it under data variable name and

the response payload inside.

There we go. So let's see. Uh a computer

property name must be a type of string

number, symbol or any uh data dot

variable name.

I was expecting this to take care of

that. Maybe I should also check for

string. Let me just just for my

curiosity if I do if data dovariable

name right here. Does that fix the

issue? That seems to fix the issue.

Okay.

Hm. Let me just pause the video just a

little bit and see how what is the best

way to handle this

here. Here's a potential solution that

we can do. We could just we can do both

actually. Let's do if data variable name

like this

and then return like that. And we can

also do another return here which can be

served as a fallback to direct HTTP

response for backwards

compatibility.

And let's just go ahead and do what we

used to do. So context

and then append the response payload

like this.

And let's just try it out for now. So I

think this should work now. So let's see

everything we changed in executor.dts is

we checked if we don't have the variable

name and we throw an error because it's

now required and we changed another

check here if we have it simply because

this type error is being a little uh

it's not it's giving us a hard time

basically. So I made sure to wrap that

inside of another if clause here so I

can safely return that with that

variable name. But if somehow all of

this, you know, validation fails or

something, let's just fall back to what

we have right now, even though it

doesn't work as well as we wanted to.

But I think that now this should work.

Okay. Um, I think I should be able to

save this because we can extend

individual node data without extending

the schema. That's another cool thing

about React Flow and the fact that we

store this in a JSON object. So I think

that now the situation should be

different. Let's click execute workflow

and let's follow it again. So it is

running and there we go. You can see

that now we have a my API call one with

its own HTTP response and then oh we

have another my API call one but here it

is thankfully my API call 2. Perfect.

It's just that this one uh was there

first. So I thought something had

happened. And here is the final result.

The result object now has my API call

one with HTTP response and data of ID 1.

And down here my API call 2 with HTTP

response data and ID of two. And this

way we resolved our problem of key

collision. So we have added the variable

name to the UI and we added the variable

name inside of the context. I'm not too

happy about this part right here that I

have to check and this fallback because

this fallback really doesn't make any

sense because it's never going to get to

that. Right? If we somehow remove the

variable name

it will just throw an error and honestly

since we are still in development phase

we don't really need to offer any

fallback. But this currently is a

solution to not have that type error

here. For the next chapter, I might

research a bit more into it and how I

can give you a prettier solution so that

we can simply validate our variable name

here. Perhaps I also have to add and if

type of let's see and if type of data

variable name is equal to string. Maybe

that's what I had to do. And then if I

remove this.

Yeah. No. Okay. Maybe I'm missing

something very obvious. So I will make

sure to take a deeper look into this in

the next chapter and tell you if there

is a prettier solution to this. But as

you can see, as I just tested, we

officially fixed our overwriting

problem. So let's go ahead and quickly

go over these three files that we have

modified. So I think we actually started

with the executor, right? And the only

thing we did here first was we added

options.headers. Make sure you have

that. Make sure you didn't misspell any

uh key and value there. Then we went

into node.tsx

where we very simply extended with a new

variable name. And I don't think we

modified anything else. If you want to

you can add it into your description so

that users so that users can visually

see uh what variable that is. You can

add it right like before the get method

whatever you prefer.

And then we went into the dialogue. We

added a variable name with some reg x

which basically allows uh a toz letters

lowerase and uppercase dollar sign and

numeric variables. Perfect. And we added

that new form field and a cool little

watch util that will directly show the

user how they can use that in other

nodes. Perfect. So, what I want to do

now is open a pull request and merge

those changes. Let's go ahead and open a

new branch. Let's call it 19 node

variables.

Let's go ahead and click on stage all

changes.

19 node variables.

Let's go ahead and click commit. And

let's click publish branch. Now, let's

go ahead and open a pull request.

And since this was a fairly simple pull

request, I don't think we have to go

through the entire uh review simply

because it's just three files. Some

quick fixes I want to resolve before

moving on to other chapters. I'm going

to immediately merge this pull request

and let's focus on uh adding more

interesting nodes finally. So, we pushed

to GitHub. We created a new branch, a

new PR, and we reviewed locally right

here all the files. Of course, you can

go through Code Rabbit's review for this

one. I just think it's a very short pull

request. So, now let's go ahead and

change this branch back to main. And

let's go ahead and click on synchronize

changes right here. And let's click

okay. And after that, as always, I like

to confirm by going inside of my source

control tab, clicking inside of graph

and I want to make sure that 19 is the

newest thing I just merged, and it's

just those three files. Amazing. That

means everything is right. And see you

in the next chapter.

In this chapter, we're going to continue

working on node execution by

implementing templating language. This

will be a particularly powerful feature

of our project and I'm so happy that we

are finally in this chapter because I

think it's very very interesting how we

are going to achieve this. So the first

thing we have to do is we have to

refactor one implementation from the

previous chapter. In the previous

chapter we added variable name which

basically fixes the key collision issue

which we discovered two chapters before

this. So let's go ahead and quickly fix

that before we discuss exactly how we're

going to implement this.

So we're going to go ahead inside of

source features executions components

HTTP request executor.ds.

So what problem do we have? Even though

we have an if check for the data

variable name missing and we throw an

error. Still, if I remove this if clause

right here, we get an error. And because

of that, we have this weird solution

where we've wrapped this instead of an

if clause and then we fall back to this

one. Since we made a decision that

variable name will be required, we can

safely remove this fallback. Now, and in

order to fix this, we can very simply

define inside of HTTP request data which

ones are actually expected to be

required. Keyword expected. So, let's

remove the question mark for variable

name and let's also remove it for

endpoint. This way, these two are

expected to always be required. And we

can also do the same for the method

actually.

But even though even though we expect

them to be required

the only way we currently validate that

is on the front end using react hook

form which is fine but not good enough.

We need to be secure. That's why we are

doing these things right here. We throw

error if any of our required fields are

missing. So let's go ahead and just do

the same thing for the method here. And

very simply method

not configured.

As simple as that. Uh if you want to

you can continue adding like these type

of errors simply so it's easier to find

in the logs. Great. So now we do make

these required in the types but we also

do runtime validation just in case they

are not passed because users can easily

bypass this. So we want to make sure

that these are actually passed so that

we can properly do uh the request. And

now once you've done this you can

actually remove the question mark here

because this will now always be

required.

And let's see the method. Same thing you

don't have to fall back to get because

method will now always be required.

Perfect. So that's how we resolved that

first issue. Our code is much cleaner

looking now. So let me quickly mark that

as completed.

So what is template syntax? How are we

going to implement that? And why do we

even need that? Well, take a look at

this scenario that I've prepared right

here. So very similar to our previous

project. I have one HTTP request with a

variable name my API call 1 with a get

method and a simple API placeholder

calling to-dos with an ID of one. And I

have slightly modified the second one.

So this one is called my API call 2

which instead of calling to-dos calls

users. So let me rename this. This will

be my users.

Let's call it user

and this will be my to-do.

Perfect. So make sure you click the big

save button and go ahead and execute

your workflow. Just make sure you have

both inest and next.js running and let's

take a look at what happens. So, I'm

going to expand this as far as possible.

Let's go inside of finalization. In the

result, we now have to-do object with

HTTP response data. And you can see it

has properties of the to-do, but we also

have a user object with all of the fake

mock user information. So, great, we can

successfully fetch one hard-coded to-do

and one hard-coded user. But what if I

specifically wanted to do this? What if

I first wanted to fetch the to-do and

then I wanted to use the to-do user ID

in the next node. So what if in here I

wanted to do this? I wanted to pass. So

this would be to-do

http response data dot user ID. Quite

long. We could maybe shorten that but

this is how it is accessible for now I

believe. Let me just confirm to do HTTP

response data user ID with capital ID.

There we go. So if I click save here and

if I just try running this it's going to

fail I believe. Let's see. There we go.

You can see that the second HTTP request

is failing with 404 not found. So I'm

going to cancel it now so we don't waste

any time. So now we're going to imple uh

fix that by implementing the template

syntax. For that we're going to be using

handlebars. So let's go ahead and

install handlebars.

So I'm going to go ahead and open a new

tab. MPM install handlebars. And then

I'm going to show you the exact version

that I'm using.

Handlebars 4.7.8.

And let me just quickly try importing

that. So import handlebars

from handlebars. And looks like type

safety is here as well. Perfect.

So now that we have handlebars, let's go

ahead and let's try and fix this. So

what I'm going to do is I'm going to go

to this endpoint right here and I'm

going to call handlebars.compile.

I'm going to pass in data.endpoint

endpoint

and I'm going to pass it context like

this. So what's going to happen now is

handlebars.compile will read

data.endpoint

which is going to look like something

right blah blah blah let me try and mock

this and then it's going to have uh

to-do http response dot data do user id

right so handlebars.compile compile will

read this and then it will use the

context to populate that. So what is the

context? Each of our executor has the

context. The context is the context is

basically the previous node data. The

context always gets updated which with

each sequencing node. So the first HTTP

request that's done if we tried for

example if you tried to do this for this

one right for the first one it will it's

always going to fail right because there

is no context behind the first one but

the second one will have context it will

have to-do context because we named this

variable to-do so I think just by doing

this this should already work and let me

just try and do console log

endpoint point and let me try and do

endpoint.

I'm using capital letters so it's easier

to find it. And if we've done this

correctly, we should see the endpoint

logged out. Well, if it works, I mean

we we will actually be able to inspect

the URL itself. Right? Basically, what I

expect to happen now, make sure you save

that file. I think I've done it

correctly. Maybe I'm missing something

but I think it should work. Is there we

go. If I use to-do http response.data

data

in here in the users. This should

compile to users one because the todo

one has a user ID of one. So let me go

ahead and click save here one more time.

Let's go ahead and click execute

workflow

and let's see if anything will change

now or maybe we'll need to fix

something. And given that it completed

I think we just fixed this. Let's

quickly take a look. So this is the

first HTTP request and it's stored into

a to-do variable HTTP response data with

user ID of one. And then in the second

one, let's go ahead and scroll down. We

now have a user. And you can see how we

have the context of the previous HTTP

response which allowed us to populate

the user ID. And I think this works as

well. Let's just confirm by finding the

ID here. And it is one amazing. Uh can I

directly see the URL somewhere? Let me

go ahead and try here maybe. There we

go. Endpoint JSON placeholder typing

code to-dos one. And you can see this is

the one users one. So it's successfully

compiled to exactly what we expected.

Amazing. Amazing job. It really is that

simple to do that. Now the only problem

is you currently can't do that with JSON

objects, right? And I mean right now you

don't really need to do it. We use the

super simple example, but what if you

change this from get to post? Well, now

things get a bit more complicated

right? Because sure this is as simple as

before, but what if you wanted to use

the JSON variable object? Well, for that

we need to do some slight modifications

here. We need to register a helper to

stringify objects. So, I'm going to do

handlebars

dotregister helper.

Let's go ahead and add JSON

grab the context

and immediately return JSON.stringify

context

null and two. As simple as that. There

we go. Now, once you've registered that

we can go ahead and go inside of our

HTTP request step here. Go inside of

post, put, and patch. And now for the

data body, what we can do is we can

first try and do the following. So

let's do const resolved to be handlebars

dot compile

data. pass in the context like that and

then let's do JSON.parse

resolved.

So this will basically protect us from

any invalid JSON being passed. That's

why we are doing that. And then instead

of optionsbody directly being that we

can just do this.

Great. Uh so yes, let's also do while we

do postput patch uh I also think hm

uh I wanted to add the body to be

required but I'm not sure if body is

yeah I don't think it's a good idea to

make body required.

Maybe we should just treat it like an

empty object

if it's not passed at all. I'm not sure.

Uh let me just quickly test is

JSON.parse

let me zoom in here. Can I do JSON parse

on an empty string? I cannot. Okay. So

yeah, maybe we should fall back

data.body to like an empty

object.

H actually it depends if handlebars can

compile an empty string. You know what?

Let's just try it. So I stop uh guessing

things. I'm just going to check what is

the proper endpoint URL to test this on.

Let's check quickly. Uh I think we can

just do to-dos

like that. Change the method to post and

just pass something like this. I don't

think indentation matters that much, but

what does matter is that you don't have

like an trailing comma at the end. So

only use commas if there's a new line

after. And make sure that your key

values are encapsulated within a string.

Otherwise, that's not valid JSON.

So we have fu, we have bar, and user ID.

I think JSON does allow numbers. So this

should work. Basically, this should now

create a to-do, I think. So, let's go

ahead and call this created dash to-do

like so. Uh, oh, great. Our validation

works. Created to-do.

Perfect. Let's click save here. And now

we should have one get request and then

one post request. Right now, not using

any variables at all. So, let's just

execute workflow. Let's see. Does that

work? Uh, looks like it's working. There

we go. Created to-do has an HTTP

response with a body of bar ID 2011

title of FU. Amazing.

And now let's go ahead and let's try

reusing something here.

So, okay, I can use this. Uh, how about

we try user ID dash

and then let's use to-do. HTTP response.

ID. So, in the title of the newly

created to-do, we're going to use the

variable that we pre previously used

here to fetch the user. So, doesn't make

much sense. We should technically use it

for this, but I think it will like be

more visible if we do this.

So, let me go ahead and I'm just going

to zoom out a bit so I can click save.

We should probably improve that. Let me

go ahead and save the project overall.

You always have to save it. and then

click execute workflow. And let's see if

that will maybe be more visible.

Created to-do. There we go. Title user

ID-1.

So it is officially working. We can

successfully template both in the

endpoint object and in the data.body

object. Now let me just check what

happens if I pass an empty request body

and if I click save. So I'm just trying

to see what bugs can we encounter here.

Now this is completely fine to fail but

I just want to see why it fails. Okay, I

see. Because of unexpected end of JSON

input. I see. Um I'm not sure if we

should handle this or should the user

handle this? So should the user know

that the request body always needs to be

something even just an empty JSON

object? because I think that now when

you save this and execute it, it's still

going to fail, but it should fail for a

different reason.

Uh yeah, okay, it didn't fail. It

managed to create it. So yeah, uh you

can make a decision. Do you want your

users to know that they should always

add something to the request body when

they select a post method even if it's

just an empty object or will you detect

when body is empty and then maybe change

it to this?

Perhaps if you do this

then you kind of save your users the

hassle.

Let's see if I remove this now and click

save here. Click save here.

And if I execute it, yeah, I think it

will like save your users some headache.

Let's see. Yeah, now it works. It works

exactly the same as before. Perfect. But

still we haven't tested one more thing

and that is the variables, right? So

what if I wanted to let's me uh can I

see some better example this one? What

if I wanted to add the entire data

object?

Like I literally wanted to create

another to-do with identical HTTP

response here. Now, right now, what we

can do is

let's see what actually would be the

proper way of doing it. I'm not even

sure myself. So

I think that what we should be able to

do now is pass JSON

to do HTTP response

data.

I think this should work now. I'm not

100% sure. Let's see. We registered the

JSON helper. So basically whatever

you've wrote here, you you can name this

anything you want. It's a name of the

helper. So it needs so it's a reserved

keyword here. So if I name this JSON 2

I would also have to register JSON 2 in

the helper. That's why we called it JSON

here. And basically it should be able to

just transpile that entire I mean

compile that entire object and just

create two identical to-dos. So the flow

is now fetch the to-do under ID1 and

then create a new to-do with the JSON

entire JSON object that we fetched from

the previous node.

That is a pretty reasonable request

actually. Let's go ahead and see if that

works or do we have to do something

else? It looks like it has failed. Let's

see why. Mhm. expected property name or

that in JSON at position 4.

All right, I think that we are making

some mistake here. I'm just not entirely

sure how. Do we maybe need to wrap this

inside of curly brackets like this?

Maybe. I'm not sure.

Let me try and add some simple

indentation. And let me click save

because I'm I'm trying to think how does

this compiling happen? Does it happen

like parsing

uh looks like not again syntax error.

Okay. The way I would debug this now is

of course by logging, right? I want to

see what exactly is going on here. So

let me go ahead and console log result

body

and, this, way, at least, I, will, be, able, to

see what's happening because that's

always kind of the problematic part and

I will remove curly brackets. I want to

see it in a string object, right? I want

to see what's going wrong. So I'm going

to remove curly brackets again and I'm

going to remove all whites space too. So

I only have this. Let me click save

here. Save up there.

And let me click execute workflow.

Again, I am expecting this to fail.

Perfect. We can actually cancel all of

the running ones because we know they're

not going to succeed. So we don't waste

any time. And now I'm going to go here

and I'm going to take a look at them

now.

Oh, that's interesting. Body.

Mhm. So, it managed to do it, but it's

completely incorrectly

parsing this.

That is interesting. H

I would assume

that we fixed that

right here.

I'm going to have to pause the video

just a little bit and research and I

will do my best to tell you exactly how

I debug this. Uh, of course you can do

it yourself. You can pause the screen

too if you like a challenge. Basically

the issue that's happening right now is

we do manage to get the exact body from

the variable. But you can see that the

quotes are broken, right? These quotes

should be actual quotes. So, I'm going

to go go ahead and try and resolve this.

All right,, I, think, I, might, have, a

solution. Uh, unfortunately, not a cool

solution. I mean, not a cool way of

discovering it. I just asked Chad GPD.

So, yeah, not exactly too cool. But

let's go ahead and modify this a little

bit. I never like this direct returns.

So, I'm going to open it like this. And

then I'm going to do uh let's go ahead

and con stringify

to be JSON stringify pass in the context

null and two and then I'm going to

return new handlebars

save string

and I'm going to pass in stringified

inside

actually let me call this const save

string like this and finally return safe

string

I always found these to be more

readable. And let's call this JSON

string. If I JSON string, there we go.

JSON string and save string. And finally

return safe string. So I described the

problem to claude and it uh told me to

try this. So I'm going to go ahead and

execute this again with no code changes.

I mean with no changes. And looks like

that actually fixed it. Amazing. That's

really cool. So let's see.

uh created to-do has completed of false

ID of 2011 title this one user ID this

one and our previously fetched to-do is

identical except ID which makes sense we

cannot force the ID I think this is a

public API right so that makes sense

that the ID wasn't honored that's

perfectly fine amazing I think that we

successfully complete ated uh templating

right now and it wasn't even that

complicated right we had a little hiccup

here but thanks to claude code it was

very easily fixed this is the type of

thing that I really like having the help

of chat GPT and claude uh because you

know it's really really the same as

googling around I could have just read

the documentation obviously but it

literally took like 5 seconds with

claude excellent now that we have this

you for yourself can decide you know how

deep do you want to go in this because

technically you could allow your users

to do the same for variable main right

you could change this to be to-do and

then use

uh what would it be to-do dot HTTP

response data user id right or like user

this change this to get and this will be

users and then the exact same card code

as up here, right?

If you want to allow your users to have

dynamic variable names

but yeah, you can see that then this

directly conflicts our regex rules. But

obviously you could modify that if you

really really wanted to, right? You

would just have to make a more loose

reg. And then before you assign the data

variable name, you would kind of create

some compile variable name handlebars

compile. You would pass in data variable

name and you would pass in the context

and then the compile variable name would

be used here. That's if you want to do

that. I personally will make the

variables as safe as possible. Again

this is also if you want to fall back to

an empty object or not.

Uh, great. So, we are halfway. I mean

more than halfway. Just like one more

thing left for us to be able to go to

other nodes. The reason I'm not building

any other nodes now is because I want to

make this HTTP request an example where

we have everything. And then when we

need to create new nodes, I can just

refer to HTTP request node where

everything works. Everything is

finished. So I don't have many bugs nor

any other things. So that's why it's

taking me so long to complete this node

is because I want to make sure it

literally has everything and because

it's a simple example, but again complex

enough that it allows us to do

templating and all those other things.

And I think this templating thing is

actually the most crucial part of a

useful workflow project, right? Because

if this wasn't possible, it really

wouldn't be that cool. I think you will

agree with me on that. And I believe

that is all we wanted to do. We now

allow dynamic body and we allow dynamic

endpoint. We can do individual strings

or we can do JSON uh objects. I will, of

course, test this a few more times just

in case I've missed out something big

and maybe you've noticed it and you're

wondering if I'm going to fix it. I

promise I will test this out until the

next chapter. So, in the next chapter

if I notice something, I will uh show

you how to fix it, if I find it. But I

think it's working pretty well. I think

it might be perfect as it is. Awesome.

Let's go ahead and push this to GitHub.

And let's go ahead and just quickly hear

what uh code rabbit thinks about this

because I am quite interested. So I'm

going to be 20 uh node templating I

believe is the branch name. I'm going to

go ahead and just stage all of these

files. Not too many changes. 20 node

templating. I'm going to commit and I'm

going to publish the branch.

Once the branch has been published

let's go ahead and open a pull request

here.

And let's wait for the review.

And here we have the summary by code

rabbit. New features. We added template

support for HTTP request endpoints and

request body content, enabling dynamic

value substitution. Improvements. We

enhanced HTTP request validation with

more descriptive error messages. We

improved response handling consistency

for HTTP request execution.

In here we have a sequence diagram. But

I think it is pretty clear how it works.

So we execute HTTP request with context.

The context is basically what is

assigned from the previous node. That's

why I explained that for the first HTTP

request there will be no context but for

the second one there will be context

which is the result of the previous node

stored in the variable that we defined

and basically we then use that context

to compile the end point endpoint

template or to compile the body. So, one

of those or both and then we send the

HTTP request with those newly generated

body and endpoint variables and we

return some response and then that

response again gets attached to the

context. So if we had a third node

right, if I go ahead and add a third

HTTP request, whoops, and connect it

right here, then this one would have

access to both the response of created

to-do variable and of the initial to-do

and it could do anything in once with

that.

Awesome. So let's go ahead and take a

look at the comments here. So the

comments are mostly to safely handle the

JSON parsing and to throw new errors if

JSON serialization

fails. So yes, we could do that inside

of the register helper. Instead of just

doing it like this, we wrap it instead

of try and catch. So we control exactly

what error is being thrown. I mean it

will still behave exactly the same right

now. It would just be a little bit out

out of our control where the error is

being thrown. Same thing goes for

compiling the endpoint. Right? Actually

this is something different. So in here

once we template the endpoint it

suggests actually checking if that

endpoint still is a valid endpoint after

we compiled it through handlebars

because yes probably some very smart

user could maybe abuse the handlebars

compile method if they know how it works

and if they watch this video and they

know that we use it. So yes, this is

some penetration protection that you

could be aware of, right? Basically

after you verify your after you compile

your endpoint with the variable, you

should still check does it exist? Is it

a type of string? And is it still an

endpoint you can call? So very good

catch by code rabbit here. But I am

satisfied with this as is for tutorial

purposes. So, I will merge this

tutorial. My apologies. I will merge

this branch. I'm going to go back to the

main branch and I will hit synchronize

changes. Once I hit synchronize changes

I always like to open my source control

click on the graph, and just cons

convince myself that it has been merged

right here. Amazing. I believe that

marks the end of this chapter. And in

the next chapter, we're going to be

doing the last thing in regards to this

HTTP request node, which will be real

time feedback. And once we do that, we

will be able to reuse that code and

create a bunch of other nodes like Open

AI request, Antropic, Gemini request

and then some submissions, I mean some

triggers like web hook trigger, Google

form trigger, stripe trigger and

similar. And very soon you will realize

there is no limit to how many nodes we

can create. It will all depend on the

ones that you want. Amazing amazing job.

And see you in the next chapter.

In this chapter, we're going to make our

nodes real time. Basically, what that

means is that we're going to emit a

proper status for each of our nodes so

that the end user sees exactly what's

happening with the workflow. Those will

include loading error and success

states. We're going to achieve this by

using inest realtime package. I would

highly suggest that you find the inest

realtime documentation page. The reason

for that is real time at the time of me

making this tutorial is currently in

developer preview. So what does that

mean? It basically means that the

feature is widely available for all

indust accounts but depending on the

user feedback some APIs and SDKs might

change in the future. So that is why I

suggest that you also visit this website

simply so you see which version you will

be working with uh and so you see if any

instructions here have changed since me

making this tutorial. But as always, I

will show you exactly the version I am

working with. So let's go ahead and do

npm install in justest real time. I'm

going to go here the same place I

installed handlebars

and let's add at ingest slashre time. I

am immediately going to go inside of my

package JSON so that those of you who

want to follow the exact same thing will

be able to do so. As you can see, I'm

using a version 0.4.4.

Just as a reminder, let me show you the

rest of my versions. My inest is 3.44.1.

My inest CLI is 1.12.1.

We are yet to see if these will work

compatibly. Sometimes a newer version of

Realtime can cause some problems and

vice versa. So, you have to match the

versions. But we're going to go by

through this step by step and we are

going to make sure to fix any instances

like that if they even happen. So just

make sure you have installed in just

real time. Now what we're going to do is

we are going to go back inside of our

source

and let's set of our uh inest folder

client.ds.

And now what we have to do here is

besides defining the ID which is

nodebase let's also add a middleware and

this middleware will be an array and it

will accept a real time middleware like

this. You can import realtime middleware

from our newly added package. Just make

sure to go forward/m middleware in the

import right here.

Perfect.

Now that we have added that, let's go

ahead and let's define our first

channel. So inside of the ingest folder

I'm going to create a new folder called

channels. And inside of here, I'm going