Explain developer architecture with Loom

Hey, this is Clinton. I'm a developer here at Loom on the dev X team. And I'm gonna use this opportunity to show you how I use Loom to explain how architecture works.

So we have a new way of deploying here at Loom deploying our application. It's called shuttle. And I wanna show you a little bit about how it's main deploy function works.

So over here in our, we've got this thing called an interaction flow, which is able to respond to events and walk us through the entire deployment process.

If you've been using shuttle, right? You've probably seen that you can say shuttle deploy and it pops up this mole here to ask you which one you want.

Well, we can enter this. You can see here. There's a way that we enter it via the command slash shuttle and then the sub command deploy.

But that's not the only way you can do it. You can also get to it like clicking here and clicking, deploy latest.

And that works as well. With this interaction flow, we have multiple entry points, so we can look at we can enter it through slash shuttle with the sub command deploy or through what's called a shortcut, which is what we just saw there.

Both of those are going to find out who the user is, and then start this whole interaction flow that we have this part right here.

I'm not gonna walk through every line of it, but there's some parts that I really want you to see. This is the most important part of it, where we start a flow, you see a state and set state looks a lot like something you might see and react.

And it's very similar. It allows us to keep a state throughout this flow. And so when that this initial data goes in there, it's in our state, we'll be able to see it everywhere else from then on.

And then as we go through here, we'll be able to update that. So here we update it with something called a view ID, which we're gonna need to update.

The view that we're looking at later in a different part of our flow. So one of the events that we're gonna respond to is something called a select action where we can and select this repo.

Let's see how that works. So when I want to deploy particular repo, I can click here and you see that little spinner it's actually contacting code right here.

We'll see that in action. When we click shuttle shuttle, right now, we don't have an automatic deploy schedule for it.

So if we try and deploy, it's only gonna deploy it staging. It's able to find that out by coming in here to this action, right?

That responds as we select in getting the workflow status for whether we have an automatic deploy workflow for this or not.

If we do great if it's disabled, then we are gonna update it to let us know it's disabled. What happens when we click deploy?

Well, that's yet another action, right? You could see here deploy modal. And again, we get certain information from the state that we already had.

Like who's the user, what's their GitHub token to be authorized, right? We can get what repo is, and then come in here.

And not only trigger that deploy, but clear these, let us know <affirmative>, you know, whether it, what kind of deploy it was.

And then finally post here in the chat. So if I click shuttle, right, and suddenly we've got this here, staging only deployed trigger for Loom HQ shuttle.

So that's how this flow works. And every part of shuttle works the way where we have these flows that go through step by step and let us control mods and have these rich experiences.

I hope that helps you understand shuttle a little bit better.