Runtime Architecture & Deployment

[00:00:00]
>> Steve Kinney: A lot of the times when I talk about this with people, we think that there's like two choices. There's at least three, but I'm going to argue that there are like dimensionality to the choices as well, right, which is, it's usually like, oh, do you have like, it was originally a monolith or a micro or set of micro front-ends, but I'm like that's not really just the only two things and then we have monorepos which kind of like live somewhere in the middle, but really there's a whole bunch of ways to think about it, right?

[00:00:32]
And so a front-end monolith is one application built as a single unit. If you have a whole bunch of repos, but they all get built into one app that gets deployed at once, it's kind of still a monolith, right? A micro front-end is many, you know, independently deliverable front-end slices composed into one user experience. So if one team can like deploy just the, you know, the dashboard while another team is working on just, you know, the navigation piece or some, and they can all deploy individually of each other, we can argue that's more of a micro front-end, right?

[00:01:10]
Regardless if they're all in one repo or they're in many repos, that doesn't necessarily mean whether or not that's a micro front-end or a monolith. The next one is the one we kind of think about a little bit more, which is the topology of the repositories, right? Do we have one repo that has many applications, but maybe those could be deployed separately, versus do we have many repos, right? How they are like assembled at runtime, where the code lives, aren't necessarily a one-to-one match, right?

[00:01:46]
You could have some flavor of each as well. And, you know, again, this goes to everyone, every team having their own repo means each team can control the peculiarities of that repo. And finally, we've got the deployment topology, which is you could have many repos. You can have everything completely separate, but you might still end up in a world where there is one deploy, right, where it's like, we'll see this pattern later, which is everyone's got their own repo or their own section or whatever, and when you go to deploy, you go to the like main app and you bump the version of your thing, that commit goes through, and then the app is deployed, right?

[00:02:31]
Is that a monolith? Is it a micro front-end? I don't know, right? And so there's like how it gets experienced when it gets loaded in the browser, right? Is it all getting shipped as one bundle? How do deploys work? What's the layout of the repo? Like there's dimensionality to this like, are they micro front-ends? Isn't a monolith, right? You could probably either pick and choose like a bunch of monolith-like things and some processes that get you all the autonomy.

[00:02:59]
You could probably also feel like you have micro front-ends and then actually have all the bad parts of everything, right? And so part of what we're going to do today is exploring all of these, right? Because like, you know, in that post I said before, like the idea of like build-time micro front-ends, which we will look at because there are reasons for doing it. You get all of the like, you get the, if the whole thing is like, well we want to be able to like be autonomous in our deploys, you've lost that, right?

[00:03:27]
And so if you've taken on the complexity for that goal, you should reevaluate whether that complexity was worth it. Now, it also means that everything gets deployed at once. You could be like that's good, you know, and so like what the priorities are and where the pain is should dictate this more than like, I read a blog post that the new hotness is Turborepo and I should be using that. That is a terrible way to make decisions.

[00:03:57]
Ask me how I know, but, you know, so our job today is to kind of look at all of the different approaches and then kind of weigh the different trade-offs and kind of build our own lightsaber of how do we solve our problems. Mark, are you going to discuss your thoughts on AI and how that interplays with architecting? And so the first time we did this workshop, it was done a lot more testing heavy, but there was stuff about like, you know, linting rules and guard rails, right?

[00:04:25]
Where you had to play a very, and it's again, it's about trade-offs, so I think it fits into this intro, like you had to play a very nuanced game. Who has either A been or B worked with the person who gets really excited to install a bunch of draconian ESLint rules? I've both been the person and I've both been the doer and the receiver of this one. You know, and like, you'd be like, cool, we would like some code consistency, but like whoever installed the rule that like you can't have parentheses around your arrow function arguments if there's one argument, and now the build breaks, right, this is pre-Prettier, everyone, so like I'm old, like that becomes slightly untenable.

[00:05:15]
However, I have found in the last, mm, I don't know, year, sometimes having draconian guard rails for my soulless little coding buddy is incredibly important, right? And like how do you kind of keep everything focused because it will go off and do some wild stuff if you do not have like a system for keeping it in line. So yes, absolutely, and, you know, I think definitely, you know, when it comes down to, you know, writing the code and maintaining the codebase, like, you know, considering that you will do a lot of that with AI is definitely a thing.

[00:05:57]
The other thing is there is a lot, it's, I think it's a tricky time right now before the robot overlords fully take over, which is fix the ESLint failures, very good at that. Architect me a system, not very good at that, but there's a class of things that you never remember how to do because you do them once when you set up a repo, right? How do you configure like a GitHub workflow that has been running your previous project for 10 years, right?

[00:06:30]
There are some niceties of like, just configure Turborepo for me. This is like what I want. I don't remember the syntax where the little caret means something versus the star, and I was going to sit there and copy and paste it from Stack Overflow anyway. So why don't you just do that for me? There are some niceties of like knowing that you can think on that higher level of abstraction of like what are the large trade-offs in the system I'm designing, and as we go and like we look at the configuration for Turborepo or, you know, module federation or what have you, knowing that you probably don't need to like absolutely memorize everything all the time because some of that like very like boilerplate, unglamorous stuff will be handled for you.