Bonus Episode: A Deep Dive into Sidecar with Greg Skerman

September 2, 2021

Greg Skerman (https://twitter.com/GregSkerman) is the OG Sidecar user, and he stops by to teach Aaron a thing or two.

Learn more →

Transcript

Aaron
00:00:00 – 00:00:23
Okay. So welcome to a bonus episode of the Hammerstone podcast. I will probably title this something like, deep dive on sidecar or something, but Sean and Colleen are not here today. So this is me Aaron, and I am here with my friend Greg, and we're gonna talk about Greg is like the OG sidecar user. I built it, but he probably knows it better.
Aaron
00:00:23 – 00:00:31
So we're gonna do a deep dive into how he's using it and where where he picked it up. So, Greg, do you wanna introduce yourself?
Greg
00:00:32 – 00:00:41
Yeah. Hi, everyone. I'm Greg. I'm the head of software engineering at ISEAC Plant. We're Australia's largest, online construction marketplace.
Greg
00:00:42 – 00:00:53
And I've been playing around with Sidecar for, I think, probably about 4 months now. Yeah. It's been an interesting an interesting time. Sorry. Yeah.
Greg
00:00:53 – 00:00:58
Keen to have a chat about how we're using it, particularly with inertia and server side rendering.
Aaron
00:01:00 – 00:01:18
Yeah. So I don't even remember we talked about this for a second, but I don't remember how we first got connected. I was in a inertia discord for a little bit, back when I was on paternity leave, but I don't think that's where it came like, that's how we got connected. Do you remember? Yeah.
Aaron
00:01:18 – 00:01:18
So
Greg
00:01:19 – 00:01:46
I was, talking to Jonathan, about server side rendering in inertia for a long time. We had a major project to, to to upgrade our main website, And we wanted to use, we wanted to use Inertia because we love it. We think it's fantastic. But the sort of SEO complexities around that meant that we were a bit cautious. And and I've been speaking to Jonathan for for a long time about it.
Greg
00:01:47 – 00:02:12
We actually sponsored, a lot of his SSR work, which was great. But we used Vapour, and I wasn't sure how that was gonna sort of play out. I think one morning he sort of pinged me and said, I'm not sure how this works, but some guy's telling me about this sidecar thing and we think it might actually make this Vaper thing play. And another thing about a month later than that, we actually got it working. I posted something on Twitter.
Greg
00:02:13 – 00:02:21
And, you are I think you reached out and sort of said, how does that work? So I I just jumped on Zoom at that point. And then we went down the rabbit hole.
Aaron
00:02:22 – 00:02:28
Yeah. No kidding. You you you sure did. Okay. So couple of things in there.
Aaron
00:02:29 – 00:02:58
First, I think I should probably tell people what inertia and SSR are because maybe a lot of people don't know. So actually I would like to hear why y'all chose inertia because it sounds like y'all are I don't know much about the company that you work at but it sounds like y'all are like a big established company and I'd be curious to hear why y'all chose inertia, and you know what you were moving from maybe.
Greg
00:02:59 – 00:03:15
Yeah. So, we have a a team that's primarily full stack developers, and most of us have a bit of a back end bias, I guess. So JavaScript's a bit of our second language. So we're pretty good, Laravel developers. We're a full Laravel shop, been using it for years.
Greg
00:03:16 – 00:03:53
But our front end was for a for a long time, basically, just bootstrap and jQuery. It wasn't terribly maintainable. About 2 years ago, we started playing around with React, really liked it. And where we sort of landed with that was React page, components and then using Laravel blade to, effectively translate variables from controllers into props in in in React. And then we sort of discovered that inertia just does that for you, and we rather eliminate.
Aaron
00:03:53 – 00:03:57
You had kind of invented inertia. Yeah.
Greg
00:03:57 – 00:04:28
But I mean, it actually gives you a whole bunch of other benefits too. Like, you you can sort of have single page applications without having to build APIs, without having to deal with React router, without having to have any client side state management. You can effectively just replace blade with react or view or Svelte, and that just becomes your view layer. So for people who have a big back end, focus, that's way more natural. We didn't have to learn anything new.
Greg
00:04:29 – 00:04:43
Mhmm. So, yeah, that's kinda where where we ended up. We we tried it out for a little while on one project. We then had a second project where we were updating something from from an old blade template system. We need to do a full renovation of of the UI.
Greg
00:04:43 – 00:05:02
And we actually found that more or less, we could find and replace return view with return inertia render. So we didn't have to rebuild any of the back end. We just kinda got this API for free, and Yeah. The the developer experience was fantastic. So we just rolled it out everywhere way because we we just found it was incredibly productive for us to use that.
Aaron
00:05:03 – 00:05:25
Yeah. I I've used inertia on a couple of things. Not not very many, but in the past maybe year I've used it on several things. And I'm kind of the same way as it sounds like y'all's team is where I'm I'm I'm a full stack developer, but I much prefer, like, to live on the back end and Yeah. Like view I guess, view 1 or view 2.
Aaron
00:05:25 – 00:06:00
1 of the early view libraries was kind of my jam where it was like if it's not a single page app, you just are kind of sprinkling some stuff in. And then everything moved to, like, full single page apps, and I felt like, oh, gosh. I don't wanna do this whole router thing. And then inertia popped up, and I was like, this is perfect because it like gives you it gives you the power of Laravel and SPAs without like the nightmares of basically reinventing a browser in JavaScript, you know, so you don't have to do all that garbage. So
Greg
00:06:01 – 00:06:20
Yes. Because you're then percent case of of what a single user needs to do. And and for us that was we were basically using it for internal tools. But the odd the odd man out was was our main website because because we have such strong SEO requirements. It's it's one of the the main sources of traffic for us.
Greg
00:06:20 – 00:07:18
And I think Google's gotten a lot better at dealing with JavaScript heavy pages in recent years, but it was still a bit scary to think, you know, we're not actually if we just rolled inertia out without, SSR, we would sort of be relying on, on on Google to to parse all all of our JavaScript and hope for the best, which was something we weren't willing to sort of look at. So, what sort of sucked for us is that we had like 90% of all of our applications were running this fantastic stack that we really loved working in and then our main sort of bread and butter website was, was sort of not that great to get around from from a development point of view. So, yeah. We've been looking at a server side rendering solution for a while. One of my team members actually was wondering whether or not he could do a PR for Inertia to introduce Cygnus our server side rendering, and then Jonathan just sent a message out on Twitter to say, hey.
Greg
00:07:18 – 00:07:38
Look. We're working on this. And and we jumped on that because, for the most part, it meant that we could we could have a uniform stack across all of our all of our projects and and work in a way that we wanted to work in. But there's a whole slew of other benefits from from from usability point of view as well, like pages load a lot faster. Right.
Aaron
00:07:40 – 00:07:48
Yeah. Yeah. So y'all you said y'all were super early on SSR and y'all sponsored a bunch of his initial work.
Greg
00:07:48 – 00:07:48
So it
Aaron
00:07:48 – 00:08:03
sounds like your team and Jonathan were both at the same time like we've got to get SSR working for inertia to be, like, super viable. And so then y'all just kind of started sponsoring him, and y'all were some of the first users of the inertia SSR stuff?
Greg
00:08:04 – 00:08:30
Yeah. So, I was really happy to be able to sponsor, his work. I mean, we we were looking at sort of doing our own pull request or a or a potentially a plug in or something if we couldn't get that off the ground anyway. So so we'd already, somewhat committed to an investment in that space, Figured that it was it it would be better for everyone if if if Jonathan sort of did it and blessed it as the way of having it Exactly. Having it work.
Greg
00:08:30 – 00:08:41
So I was really happy to be able to do that. And I I was sort of bothering him quite frequently because we sort of, we kicked this project off going, we're gonna have SSR. SSR. This is going to get off the ground. Mhmm.
Greg
00:08:42 – 00:09:03
We just let's assume it's gonna be there. And we didn't quite have the the the technology there and the the sort of clock was ticking on this project. So I was I was messaging him quite frequently. And, I think one night just before he went to bed, he sent me a link to a gist with some really rough instructions on how to get it to work. And then I I picked it up, on the train on on on the way into work that morning.
Greg
00:09:03 – 00:09:27
I think by the time I got to the office, I had I had it working with a, with a node server, which was the sort of way that Jonathan was looking at doing it. Mhmm. And then I think by lunchtime, one of the members of my team had plugged it into Sidecar, which we'd never used before then. We'd sort of we'd heard about Sidecar from Jonathan, thought this is cool. Don't quite know how this is gonna work, but let's, let's roll with it and see what happens.
Greg
00:09:27 – 00:09:31
And, yeah, I think we beat you to the punch by about 12 hours, but that was only by virtue of
Aaron
00:09:31 – 00:09:33
timing. Did. I think
Greg
00:09:33 – 00:09:44
that's only by virtue of timing, like, yeah. Because I think, yeah, the next day you had proof of concept up on the, on the, insider's group as well. So
Aaron
00:09:45 – 00:10:19
Yeah. I remember it. So that that is what I that's the first thing that I remember was, like, it I it was during paternity leave, so I was, like, sleeping, you know, every couple of hours for an hour or 2 and then feeding babies and then, like, hanging out in this discord and riding sidecar and doing all this, you know, crazy stuff with all by, you know, quote, unquote free time. And I remember SSR became a thing, and I told Jonathan, like, hey. I think I have a solution for the vapor use case and potentially a lot more.
Aaron
00:10:19 – 00:10:41
And like I got access because I started sponsoring him and then I kind of plugged it into Sidecar And then I remember I think you posted maybe on the GitHub issue about vapor or something and I was like, oh my gosh. He figured it out before me. And so I messaged you, and I was like, hey, man. I just figured it out. It looks like you figured it out, so I'm gonna let you go first.
Aaron
00:10:41 – 00:10:57
You post your thing, and then I'll come in after because you got there before I did. But, yeah, that's that's the first thing I remember was when you like, we it seemed like we figured it out at the same time, but you had done it, like, a day before. And I was like, how who is this guy?
Greg
00:10:58 – 00:11:02
But so I'd love to take credit, but I got some very smart people in my team who
Aaron
00:11:03 – 00:11:06
Yeah. It it sounds it sounds like you have a lot of a lot of smart Yeah.
Greg
00:11:06 – 00:11:12
There's there's some real tricks in the webpack stuff there that I still don't really understand how that works, but there was
Aaron
00:11:12 – 00:11:52
some Nobody understands how webpack works. So backing up just a little bit so everyone else renders so inertia sits in the middle between Laravel and in y'all's case react. Right? And the server side rendering takes the react app and renders it on the server, hence the name, and then sends HTML out which is what you're talking about in Google's case. It's better if they have HTML to crawl versus rendering JavaScript and maybe getting it wrong.
Aaron
00:11:52 – 00:12:34
Right? So the server side rendering part is the part it's a feature of inertia where when the initial request comes in it can take that JavaScript turn it into HTML and send it back out and then from then on out it can do the you know the regular requests but what that needs like, the way the way that Jonathan set it up is it requires a node process. Right? Because it's gotta, you know, render the JavaScript. And so the default way that I think he has set it up is you have to run a node process on your server and that's the part that listens for incoming requests and turns it in HTML and sends it back out.
Aaron
00:12:34 – 00:13:14
And that's great for most people but in the case where you're running on Laravel Vapor or you don't want to keep a node process running you need somewhere else to render that because you don't have access you know to a running node process and so that's where that's where sidecar comes in because sidecar is not a running node process. It's a it's a Lambda that is just like invoked whenever you need it. So that's kinda like for people wondering, like, what what are you guys talking about? That's kind of the whole process. We have to you have to get a a node, like a node process somewhere, and that's the trick.
Greg
00:13:15 – 00:13:39
Yeah. So, we we have, like, an interesting load profile across across most of our systems. So, we tend to get really busy during business hours of 9 to 5, across the country and then fairly quiet at night. So we always had problems. We and we had to have a lot of server capacity because we have these crawl events that come from, from Google and, and and various things.
Greg
00:13:40 – 00:14:01
So we had to have a whole pile of reserve server capacity, which we we used to just sort of brute force by having, you know, 4 servers sitting behind a load balancer. But most of the time, we're getting nearly zero utilisation on them. Mhmm. So we jumped on Vapour really early because it gives us the cost control. So we only pay for what we use, which has been really, really fantastic for us from a, from a cost control point of view.
Greg
00:14:02 – 00:14:32
But then you kind of get locked into the sort of limitations of what Lambda can do. You can't run. So you can't run servers. You can't have things that these long running processes that, you know, you typically can have if you've got a nailed up server. So we we knew that when Jonathan sort of solved the problem with, by by using a separate node process that we could probably, like, spin up like a container somewhere and then run the SSR on that container and reach out to it via HTTP.
Greg
00:14:34 – 00:14:59
But we were sort of that would have worked, and it would have been fine. And and if that was the only solution, we we were completely happy to go down that road. As it turns out, there'd be a lot of challenges there, particularly on the deployment side. Like, how how would you keep how would you deploy something into, into Vapor and then keep a new JavaScript, a new version of your JavaScript bundle running in sync on another server? It would have been Yeah.
Greg
00:14:59 – 00:15:25
It would have been tricky. Sidecar just makes that go away because I sort of deploy my Sidecar, Lambda at the same in the same sort of build pipeline, deployment pipeline that I'm deploying my main main code base. You have that really cool switch where you can deploy it without activating it. So you can wait until everything is ready to go and then turn it on at the last second, which is which is really neat. And, yeah, it just it just works, which is really great for us.
Greg
00:15:25 – 00:15:44
I I think I mentioned to you in a in a conversation a couple of weeks ago that there's probably only 3 people in my team that actually know under the covers what's going on. Mhmm. For everyone else, it just it's just like calling a function, right? It's just like dispatching a command. They don't need to know that there's this rather complex process going on behind the scenes with extra Lambdas and so on.
Greg
00:15:44 – 00:16:02
It's just a really, really great developer experience where I think the, the calling out to a separate server, you wouldn't have been able to establish that kind of illusion where there's not, you know, there's nothing to see here. It's all it's all taken care of for you, which is which has been really great.
Aaron
00:16:03 – 00:16:23
Yeah. Well, I'm well, I'm just I like I said, you're the OG sidecar user. I I may have written it, but I think you know it better. And this is just this is just really exciting for me to hear. So I kinda wanna hear, like so you said you got the node process working on train, and then later that afternoon, you had you'd gotten it running in sidecar.
Aaron
00:16:23 – 00:16:45
So, like, you heard about sidecar from Jonathan who sounds like didn't sell it very well. He's like I don't know what this guy's up to but it might work. So I'd be curious to hear like when you when you saw it and you got it running and got it working, like, what were your kind of first impressions? What did you think was happening? Were you, like was it surprising that it worked or what did you think?
Greg
00:16:46 – 00:17:05
Yeah. So I I had a bit of reading. So so there was a bit of a gap between Jonathan saying this might be a viable solution to your problem and our and then us having access to the SSR branch, of inertia. So I I think I think in the meantime, there was a, an article on on the Laravel News about it. I had done a bit of looking into it.
Greg
00:17:05 – 00:17:26
I thought this is kinda cool. It's it's kind of this missing piece. Right? And I was thinking about using it for some other things because we do things like generate PDFs and generate images and so on, and we we use third party services for that. But, you know, there's plenty of off the shelf sort of Lambda components that you could just use that and then you wouldn't have to integrate with a third party service.
Greg
00:17:26 – 00:18:01
You just call a function and something back. So I was already kinda looking at it, from that sort of point of view as to whether or not it'd be useful, sort of outside of our SSR context. The first time I played with it though was was when we got this, we were starting to stand this SSR thing up and I was really surprised at, like it's just really well thought out initial setup process. I was looking at it thinking there is gonna be a giant headache of, like, of AWS IAM configuration and role management and, and I'm not sure what you're doing. I think you you might be sort of, like, tapping into the stuff that Vapr's
Aaron
00:18:10 – 00:19:05
describing is describing is the AWS, IAM, you know, identity management nightmare that everyone just freaking hates. And I actually did start out piggybacking on top of Vapors, like, execution roles and some of their credentials that were in there. But then I realized you're not gonna be able to deploy it via your local machine or GitHub actions because you're relying on credentials that are living inside of vapor. So like you'll never be able to deploy except from vapor and that doesn't make sense. So the thing that I spent way too long working on, but it sounds like it was a good thing to waste my time on, is this this little command that you're talking about where it like, the only thing that it asks you for and it walks you through how to get there, the only thing it asks you for is, administrator keys.
Aaron
00:19:05 – 00:19:25
So it asks you for admin keys and you give it the admin keys, and then it builds everything that it needs, and then it destroys the admin keys. So it like wipes them away. So I did start out piggybacking off of Vapor and then I moved to the more interactive walkthrough thing. So it sounds like I may have wasted my time in the right spot that was helpful for you.
Greg
00:19:26 – 00:19:33
Yeah. It was really great. I mean, it it also means you don't have to maintain a huge pile of documentation. Your documentation is basically that command. Right?
Greg
00:19:33 – 00:19:45
That you run that command. It'll tell you everything you need to know to get this, like, walking on 2 legs. And then from there, it's, it's it was really straightforward too. Aside from the webpack stuff, which is not your responsibility at all. That's that's
Aaron
00:19:45 – 00:19:47
that's not me. That's Jonathan.
Greg
00:19:50 – 00:20:16
So, yeah. It was it was a really great sort of sort of, set up to get it sort of walking on 2 legs. And then, I think our first sort of cut at our, sidecar Lambda function. So you still write a bit of JavaScript and then you tell like a sidecar class that you create where that file is and what needs to be uploaded as part of the Lambda and so on. It's just a little, tiny little bit of boilerplate you have to put together.
Greg
00:20:16 – 00:20:47
And we were able to take most of Jonathan's initial SSR code, just sort of take it out of the express server and just drop it straight into this Lambda function and deploy it. And it just kinda worked, which was shocking. It just, like, I I was expecting I think I'd, like, earmarked in in our in our backlog, like, 3 days to let's have 3 days to try and figure this out because so much could have gone wrong and it just didn't. We just Yeah. I think a few of us were sort of looking at it, Slack, jawed going, it can't be this easy.
Greg
00:20:47 – 00:20:48
Like Yeah.
Aaron
00:20:48 – 00:20:48
This didn't work. Solved
Greg
00:20:51 – 00:20:55
we kind of solved SSR in, like, a work day.
Aaron
00:20:55 – 00:20:55
Like, it
Greg
00:20:55 – 00:21:19
was it was wild. So, yeah. We, and we haven't really changed it much beyond that. I think we've wrapped, we've wrapped some of our code around how we reach into it up in some nice sort of little driver base manager that we created so that people could have a local development experience where if they wanted to use a local node server, which can be handy if you're trying to debug what's going on. You can sort of have one
Aaron
00:21:19 – 00:21:19
with your log stream.
Greg
00:21:20 – 00:21:44
I personally just run Sidecar from my local environment and just just deploy something and not play around with that. But aside from that, the actual code that's running in production today is not that different to the code we originally wrote, in that first sort of 7 hours of playing with it. So and it's been super reliable. It's never gone down. Before we went live, I threw a massive load test at it.
Greg
00:21:44 – 00:22:10
I think I sent you the graph on it. We were just beating dick out of the thing and we just couldn't get it to break database broke before anything else did. So, it was yeah, it was crazy. It's just super reliable, super simple. Because we we've looked at other I think there's a Sparcy package for using server side, like, creating a server side rendering inside of VH JS in PHP and we played around with that.
Greg
00:22:10 – 00:22:26
And that's really cool, but there's a lot of moving pieces and it doesn't feel, it didn't feel like it was gonna be super stable. But, yeah, this sort of inertia vapor sidecar combination is just yeah. It's just really great.
Aaron
00:22:27 – 00:23:20
Man, that is so cool to hear. So you you did send me some of those you did send me some of those graphs, and I was just like I was like, what the heck am I looking at here? So talk to me about, like, the response times because I think one of the, like, one of people's and rightly so one of their fears is like wait you're asking me so the request comes into vapor which is itself a Lambda and then it's like going through, you know, the PHP controller or whatever, and then you're calling out to another Lambda from within the Lambda, and you're doing your server side rendering over there, and then it's coming back and then going back out to the user. And so I think a fear that people have is like wait how long is it taking to you know basically shell out to another Lambda running node and get my HTML back. So So when you sent me those graphs, I was just, like, blown away.
Aaron
00:23:20 – 00:23:27
So you've been running this in production for a while now. So, like, what's y'all's experience with response times? Yeah. So that was
Greg
00:23:27 – 00:23:31
one of my concerns as well, especially for cold starts.
Aaron
00:23:32 – 00:23:32
Mhmm.
Greg
00:23:33 – 00:24:00
So in Lambda, if you haven't been running a Lambda function for a while, that there's usually a bit of a delay while it wakes up and gets its pants on and starts working. And then it becomes like a warm process that just, that that runs in the background and is pretty pretty responsive. But we have again we're we're trying to do the best thing we can from an SEO point of view. And one of those things is you have to have pages that respond quickly. So we have we have, like, a response budget we have to have to meet.
Greg
00:24:01 – 00:24:23
So that was a bit of a concern as to whether or not SSR in general, sidecar or no notwithstanding, was gonna be a problem. One of the cool things about the way that SSR in Inertia works is you're just passing props around. So you you do all of the heavy lifting in the PHP. You go to your database, which is usually the most expensive part. You pull your data out, and then you're just sending values, across the wire.
Greg
00:24:23 – 00:24:53
So the the the Lambda function that's running, inside car to so the Lambda function that side car is managing for us, that's producing that HTML is just receiving values, just receiving strings, and then building. So it's it's nearly as fast, I think, as running React in a browser is. Mhmm. Which is to say it's very fast. I think our initial experiments, we were looking at about, like, an average of 60 milliseconds.
Greg
00:24:53 – 00:25:10
We upped the amount of memory. I think we run about 4 gigs, on which is actually a lot more memory running on those sidecar lambdas than, running on our vapor lambdas. Right. But there's a correlation in I'm not a 100% sure how this works and I might be speaking at a school here, but when you're You're right.
Aaron
00:25:10 – 00:25:18
And nobody nobody's a 100% sure how it works, so keep going. When when you
Greg
00:25:18 – 00:26:03
when you set up a Lambda function in AWS, the only real thing you can control is how much memory it has. And there is some relationship between memory and CPU. So if you give it lots of memory, you get more CPU, but I'm not quite sure how much more. So, yeah, so by giving it more memory, we're effectively giving ourself more CPU, which is, you know, our benchmarking showed that we were able to get a lot more performance out of that, that sidecar function. I think, last time I looked at the thing running in production, we had, I think, an average response time out to the sidecar Lambda of about 40 milliseconds with a minimum around 20 milliseconds, and I think a 95th percentile of about a 100 milliseconds.
Greg
00:26:03 – 00:26:18
There are occasions where it gets, like, a lot higher than that. Like, so immediately after deployment when everything's cold again, we'd we'd then Yeah. Have to wear, like, 1 or 2 requests at 300 milliseconds while it sorts itself out. And we haven't really I I think you actually did release, like, a warming solution, but I don't think we've done anything.
Aaron
00:26:18 – 00:26:59
I did. Yeah. I released, I'll be I'll be curious to hear if y'all end up using this, how you like it, but I released a a pre warming function or a pre warming flag basically. So you can deploy your Lambda, pre warm it, so it'll send Sidecar will send as a part of the deployment process, it'll send requests to the Lambda before it's activated, and you can, you know, configure if you wanna send 1 or, you know, a1000 or whatever. And then once those are once those requests are fulfilled, then it will activate after they've been warm.
Aaron
00:26:59 – 00:27:27
So like, you know, let's say you're deploying version number 10 and version number 9 is active. It'll deploy version number 10 and all of your production traffic is coming into 9. We'll hit version 10 with a bunch of requests, just from sidecar itself, and then we'll switch the active alias to 10 after it's warm. So hopefully the theory is that you can avoid cold starts altogether, you know, provided you warm enough containers ahead of time.
Greg
00:27:27 – 00:27:32
So And you just you just include that in your deployment script before you hit the activate. Right?
Aaron
00:27:32 – 00:27:47
Yeah. Exactly. So you you do I think you do, activate dash dash pre warm. So it'll just as a part of the activation, it it sends out those requests. So it's just another flag on the deployment script.
Greg
00:27:47 – 00:27:53
Yeah. Yeah. I'll I'll after this call's over, I'll, I'll check on and let you know how how that goes.
Aaron
00:27:53 – 00:27:59
Yeah. It's some I guess it's the middle of the day for you. You know, it's 10 o'clock over here, but you got a work day, so you can you can get up to something.
Greg
00:28:01 – 00:28:20
Yeah. But, no, it's, in terms of the performance side of things, it's it's really not as big of an issue as I thought it was gonna be. And the other thing is that inertia makes it not so much of an issue because you only have this server side rendering problem on the initial visit. After that, it's a single page application. It's just communicating
Aaron
00:28:20 – 00:28:21
via That's true.
Greg
00:28:21 – 00:28:47
JSON anyway. So it's the initial hit and also the way that crawlers work that, that you need to wear that sort of extra somewhere between, say, let's say, 20 and a 100 milliseconds, worst case. After that, it's it's it's just as responsive as a regular inertia app would be. Hydrates the page, loads everything up, and it's it's just running in your browser at that point. So, really wasn't as big a deal as I thought it was gonna be.
Greg
00:28:47 – 00:29:25
It'd be interesting to benchmark it against Blade and see because I think I think the node the node runtime, I'd imagine, is gonna be faster than the PHP runtime anyway. And it'd be interesting to see whether or not whether or not doing this is is quicker. But, yeah, it's, if anyone's sort of worried about the performance side of thing, it's unless you were had a really intensive performance concern, I don't think it'd be a major issue. And if you had a really intensive performance concern, you you're probably gonna be looking at some fairly comp, complex and custom infrastructure anyway. So I think for the 80% use case, it's
Aaron
00:29:26 – 00:29:41
perfect. Yeah. This is absolutely that's interesting you say that. Because when I was writing Sidecar, I was thinking this is not for the hardcore serverless, like, for the server the AWS serverless heroes. This is not this is not for them.
Aaron
00:29:41 – 00:30:18
This is for people who find themselves, like like you mentioned not wanting to try to synchronize a deployment to Laravel Vapor plus some, you know, server on forge or some container manage somewhere else, or you end up on vapor and you're like, well, f. I need a node process or I need, you know, for whatever reason I need to run some Python, and I'm still gonna keep my Laravel app. I just want to do a little bit of extra stuff. That's what sidecar is written for. So, yeah, it's definitely the 80% the 80% use case like you said.
Aaron
00:30:19 – 00:30:30
I'd be curious, like, how does it work with a team? Like, you're you're like a proper team of developers, and you're using this tool that I made that I wrote as an individual and use as an individual.
Greg
00:30:38 – 00:31:02
There's there's probably only 3 of us who really understand at a deep level what's going on under the covers. And really of the 3 of us, there's only 1, which is, Reese, one of one of the seniors, that I work with. He he's the guy that that has really gone to town on on on making it work, in a production sense. For the most part, it just gets out of your way. You don't even need to really know that it's there.
Greg
00:31:02 – 00:31:32
Like, from a developer experience point of view, it really looks an awful lot like dispatching a command. Like, you just call your little sidecar class and execute it as if you were dispatching a command or or raising an event. So from a from a developer experience point of view, there's there's not it doesn't get in your way. It doesn't get in the way of Teams because it kind of just works the way you expect anything else in Laravel to work. Like, if it it almost feels like a first party kind of concept in that way,
Aaron
00:31:33 – 00:31:35
which, which That's amazing.
Greg
00:31:35 – 00:31:54
Which which is fantastic. I mean, I think where it gets a little interesting is when you sort of have people like me who want to use it for a local development, side of things. You just really need to run those in separate environments. So, you know, I'm gonna run like a a Greg local environment and deploy to that. I'm not trampling on a production, like a production.
Greg
00:31:54 – 00:32:08
So I can't it is cool though, when you when you do wanna sort of see what's happening in production on your local environment, like, you wanna just dump out the markup that's coming through, you just point it at the production, like, locally pointed at what's running in production and see what's going on. That's kinda cool.
Aaron
00:32:08 – 00:32:25
Oh, dude. I have never ever thought of that. That is the first time that that has occurred to me. So what yeah. Like what what Greg is describing is when you when you deploy a sidecar like it separates it by default it separates it by environment.
Aaron
00:32:25 – 00:33:02
Right? So you have a local, you have a, you know, a staging, and you have a production. And that's so you can push it to CI and run some tests, or you can, like, be on your local machine and run some tests, and you're not collaborating, the production Lambda that's like serving your Google SEO because that would be very bad news. It also has a feature because of y'all. I don't know if you knew that this was because of y'all, but because of y'all it has a feature where instead of just using the Laravel environment which is like local dev production or whatever, you can pass through a sidecar environment.
Aaron
00:33:02 – 00:33:24
So like you said you can your sidecar environment can be Greg local or Aaron local instead of just local so that you know, like, 10 people on a team can have a local environment, and they're not clobbering each other being very confusing. So what you're telling me is sometimes you'll just change your sidecar environment to production and just kinda poke around and, like, see what it's returning?
Greg
00:33:25 – 00:33:27
Yep. Absolutely.
Aaron
00:33:27 – 00:33:28
That's genius.
Greg
00:33:28 – 00:34:21
Well, it's it's it's it's it's again, it's it's one of these sort of constraints of operating in a Lambda environment. If if if you've got a problem between the if you've got a problem between sort of Laravel running in vapor and Sidecar running in vapor, seeing what's going on between those things can be really, really tricky. And you can dump things out to logs and go and I think the 2nd biggest hell in AWS after IAM is, CloudWatch logs. So you really don't want to be there if you can avoid it. So sometimes it's like if you if you suspect something weird is going on and I particularly think if you were doing something like I wanna if you were running, say, a a a PDF or something that was running in a sidecar and someone was sort of saying, I'm getting weird PDFs back when I do this, you could potentially run it locally and then just stream back from a production sidecar, the p the the payload that's coming back and sort of be able to see see what the user is gonna be able to see while you got the code open and while you're debugging stuff.
Greg
00:34:21 – 00:34:25
So, yeah. I mean, it's it's not a big thing, but it's it's a handy hack when
Aaron
00:34:25 – 00:34:52
you need it. Yeah. For sure. I mean, it may not be a big thing, and it's pretty clever, and I'd never ever thought of that, so it seems pretty cool to me. So you you mentioned I think you've mentioned twice now the PDF thing, so I'll be curious because the first time the first time I, like, got sidecar working properly, I felt like my eyes opened and I was like, what else could I do?
Aaron
00:34:52 – 00:35:06
Like, what else could I run-in a sidecar? What other, you know, node libraries could I wrap up and kind of run without having to think about infrastructure? So have you all been it sounds like you've thought of a couple, but what's y'all's process there?
Greg
00:35:07 – 00:35:42
We haven't gone down the road yet. We still use a third party PDF ing service, but there's a a lot of these services that we use don't have PHP SDKs, so we're writing directly to their APIs. It's just a real pest. If you can come up with a way if you need to, like, generate a, a screenshot, like, if you're screen grabbing a URL, or if you were generating a PDF or, if you were generating an avatar for somebody with their name and all sorts of things that you could do, with that. Because the developer experience is so great in that you just write a little bit of JavaScript and you just call it.
Greg
00:35:42 – 00:35:53
You don't have to worry about how how do I authenticate against an API? How do I, you know, what are all the status codes that I'm gonna have to deal with? What's the shape of this? Do I trust that these people aren't gonna change the shape of their API? You can kinda own that.
Greg
00:35:54 – 00:36:17
And there's whole piles of really, really small, node and Python libraries out there that people have already written. You can just kinda grab, wrap them up, chuck them onto a, onto a Lambda, and then just call them as if they're effectively call them as if they're just PHP functions really. Right? So, there's a few things there that'd be really, really interesting. Another interesting one that that we run is we we have a disaster recovery process where I won't bore everyone with the details, but we have a
Aaron
00:36:17 – 00:36:19
No. No. No. Tell us.
Greg
00:36:20 – 00:36:43
We have a a scheduled process, that runs regularly that effectively backs up our database, for us. And that's all run using Lambda and set functions and, you know, CloudWatch schedules and so on. There's a there's a huge CloudFormation script that sort of, handles that. So AWS actually provide that to one of their, one of their, Git repository somewhere. There's kinda like a recipe for doing this.
Greg
00:36:44 – 00:37:19
But I've been thinking recently, given that it's ultimately just calling some Lambdas that are orchestrating all of this stuff. Could I get rid of all the complexity and then just use Laravel schedule, right? Just have Lara say, every night at 11 o'clock, run the backups and have it just orchestrate stuff that, that's already there and just do away with all the complexity. And then I'm sort of managing that schedule and code that I understand, not some, you know, confusing CloudFormation script that I I don't have a huge huge amount of understanding of. So there's a whole bunch of really interesting little things that you can do.
Greg
00:37:19 – 00:37:34
Anytime that anytime that you wanna run one of these Lambda functions, you can potentially, like, roll them into Laravel and use all of Laravel's cool stuff, like queues and schedules and so on, and then just execute them across using psycho, which is which is a neat a neat thing, I think. So yeah.
Aaron
00:37:34 – 00:37:55
That's about you get to keep it all, like, you get to keep it all in the same repo, and you get to keep it all in the same frame of mind, and and you get to deploy it all together, and everyone's always looking at the exact same thing. And you're not like, hey, Greg. Did you update the cloud whatever whatever script? And you're like, well, no. Now it's out of sync with the app or whatever.
Aaron
00:37:55 – 00:38:16
Yeah. And for the long running, like, I assume the the, you know, the database backup stuff is long running. I I haven't really had a need for it, but you can dispatch those sidecars, like, asynchronously and just not wait for them. Like, you just dispatch them and get out of there, and that sounds perfect for the backups.
Greg
00:38:17 – 00:38:38
Yeah. Yeah. So that's that's something that I'm I'm I'm really keen to to look into. So, it also means that I can I don't need everyone who needs to manage that backup process to have access to more parts of AWS? Like, there's people on my team who who have access to Vapor but then don't need access to, like, production AWS environment, which is, which is great.
Greg
00:38:38 – 00:39:07
And and the more that I can pull back into the code and not have running over in weird processes that, you know, we don't have a great understanding of a lot of the time because we don't have that in house expertise. We're sort of relying on AWS to tell us what to do, in a lot of regards there. Yeah. The more we can pull in the code, the more we can manage and the more we can own it. And if things go wrong, it's easier for us to debug and we don't have to elevate people's privileges to things that, you know, we might not want to or, might be uncomfortable doing.
Greg
00:39:07 – 00:39:16
So yeah. It there's a there's a huge pile of, like, interesting quality of life things and and management and maintenance things that that that sidecar enables. So, yeah, it's really cool.
Aaron
00:39:17 – 00:39:24
What kind of traffic are y'all doing? So tell me again the name your the company is iseekplanthq. Is that right?
Greg
00:39:24 – 00:39:27
Iseekplant.com.au is the is the company.
Aaron
00:39:27 – 00:39:27
Dot com.
Greg
00:39:27 – 00:39:42
I don't have the traffic figures, to hand, but it's it's a fair bit. I think the yeah. I I don't actually I don't I don't have the numbers, to hand today. So, I can't really disclose that. But, yeah, it's a fairly busy, well traffic website.
Greg
00:39:42 – 00:39:51
So we're the largest marketplace of its type in Australia. Okay. So, yeah. There's and then
Aaron
00:39:51 – 00:39:52
we it's a lot of traffic.
Greg
00:39:53 – 00:40:18
Yeah. So we we service the construction industry. Right? So we're connecting people who are looking for construction services and heavy plant equipment all the way from, you know, small residential jobs right the way up to giant mine sites. And we have people, who are looking for equipment or looking for construction services every day coming to our site and trying to find, the right companies to work with and we sort of manage the connection between those, between those parties.
Greg
00:40:18 – 00:40:23
So, yeah, there's there's a fair bit of business gets done on the platform, every day.
Aaron
00:40:23 – 00:40:29
And how big is your, Laravel team or, I guess, your general development team? I assume they're all Laravel.
Greg
00:40:30 – 00:40:52
Yeah. Yeah. So we're all full stacks and we've we've we've proudly maintained let's be full stack. We find that most of the problems we solve are full stack problems and we we haven't yet got to the point where having a dedicated react person would be, beneficial. Some people have gotten really good at react though, which is especially as we've moved into inertia, so we have some people who have some really great expertise in that area.
Greg
00:40:52 – 00:41:29
There's 11 of us in the team currently, so we've divided up into 4 squads. 3 squads who are working on on new products, new features, enhancements to existing, products that we maintain. And we have a a platform and architecture team that's looking at all the good work that those people are doing and then sort of putting it on rails and and making it, making it easy to to replicate across those teams. So it's it's quite a large team, certainly not the biggest team that I'm aware of that's using Laravel, but, in terms of, a lot of Laravel community that I'm aware of where where
Aaron
00:41:29 – 00:41:30
Yeah. Same. Like you
Greg
00:41:30 – 00:41:34
said, you you work you work by yourself more or less. So
Aaron
00:41:34 – 00:41:34
Yeah.
Greg
00:41:34 – 00:41:35
It's,
Aaron
00:41:35 – 00:41:55
Yeah. We, so I all the sidecar stuff I did was all side project stuff. So that's all, you know, obviously by myself. At my full time job there are 3 of us, total of which I am 1. So there are 3 Laravel developers and we're in a, you know, similarly, unsexy space.
Aaron
00:41:55 – 00:42:19
We're in, like, real estate taxes. But all of our, like, all of our work is pretty much internal. We service our employees basically. So we build a, you know, CRM and process automation stuff for our employees. So I never ever really think about, like, you know, traffic or is the site gonna stay up or whatever.
Aaron
00:42:19 – 00:42:34
So if you're telling me you're the largest, you know, construction marketplace in Australia, you're doing you're doing a a lot more than I am. But, yeah, I feel like 11. 11 is is a big team for me. I know for some, they're like, oh, that's so small. But for me, that's that's a huge team.
Aaron
00:42:34 – 00:42:38
So that's that seems pretty cool. How long have you been there?
Greg
00:42:39 – 00:42:55
I've I've been with the company for, I think this is my 5th year. Wow. Now, so, yeah. We've had a lot of growth the last, particularly over the last 2 years. So so a lot of a lot of the a lot of the team we have now, has sort of joined us within the last 2 years.
Greg
00:42:56 – 00:43:36
And, yeah, a lot of the people who who've built all this cool stuff, who've really helped out with this, you know, rearchitecture to React and and inertia our new people that we've brought on sort of in the last 24 months, which, which is really cool. And part of the advantage of having a large team is you end up with a lot more brains in the room. So the the pace at which you can pick the pace at which you can do cool stuff just kicks right up because you're not relying on 1 or 2 people to have all the ideas. You got this huge melting pot of, you know, I've tried this at my previous business and how do how do we mix that with this other thing that we've got going on over here. And, we just find there's this huge acceleration that you get when you have, a whole bunch of smart people in a room working together.
Greg
00:43:36 – 00:43:37
It's really cool.
Aaron
00:43:38 – 00:43:46
Okay. So, Greg, listen. Every, like, week or 2, you DM me something that's, like, 3 levels above my head. You're like, hey. What if what if you tried this?
Aaron
00:43:46 – 00:44:03
Or, hey. I was thinking about this, and what if we did this? I need you to be, like, I need you to be more public. I need you to be writing, and I need you to be, like, tweeting and telling me, like, explaining all of these. You DM me and you expect me to understand, and I'm like, dude, you're so far beyond me.
Aaron
00:44:04 – 00:44:16
So do you write anywhere? Do you I know you don't tweet a lot. I I think you have a couple times in the past week, but, like, you don't tweet very much and I haven't seen a lot of writing. So I need more access
Greg
00:44:16 – 00:44:33
to your brain. I'd love to do more writing. I've done I I've I wrote an article, about 8 months ago on LinkedIn. I I made a commitment at the beginning of the year that I would write an article every week and I wrote one article. I didn't write anything after that.
Greg
00:44:33 – 00:44:40
So, yeah, I I have an article floating around on LinkedIn on on continuous deployment and continuous delivery to production, which is,
Aaron
00:44:40 – 00:44:41
I mean, it sounds great.
Greg
00:44:42 – 00:44:54
Yeah. That's kind of the space that I I really like playing. You know, I really like workflow and I really like, you know, reducing the time to deliver value to users. It's sort of, like, my passion, I guess. Yeah.
Greg
00:44:54 – 00:45:14
So I wrote this article, got a fair bit of, of good feedback on it and then sort of got busy and life got in the way. So I I stopped writing, which was, so that was that was that was a shocker on my part. I do run the the Brisbane Laravel meetup, which has been growing in spring. We haven't had it for a little while. We we sort of had a bit of a mini COVID lockdown recently and that kind of Mhmm.
Greg
00:45:15 – 00:45:32
Put paid to that. But, I think last time we ran it, we had Mohammed from Laravel come in and talk to us about Laravel Octane. So, yeah, that was really cool. And I think off the back of that, I had some chats with you about Laravel Octane running in vapor, which I think is probably the next area where we'll do some damage. Yep.
Aaron
00:45:33 – 00:45:39
I'm still secretly hoping that Taylor's gonna pick that one up again. They they recently closed that issue, but I'm hoping they'll pick it up.
Greg
00:45:40 – 00:45:45
Yeah. They closed the issue but said that it's been moved to their internal backlog. So I I'm I'm taking that as they're working on it.
Aaron
00:45:46 – 00:46:01
That's kinda what I'm hoping. We'll see. So what what we're talking about is I figured out a way to run, octane, which is Laravel's like, what would you call it? What would how would you describe Octane?
Greg
00:46:01 – 00:46:11
It's like an async long running it kind of it kind of breaks the way PHP works a little bit. Right? So it moves from a shared nothing to a to a daemon sort
Aaron
00:46:11 – 00:46:12
of style.
Greg
00:46:13 – 00:46:17
Yeah. It's it's tricky one to kind of. I don't know that I can get it out in one sentence what
Aaron
00:46:17 – 00:46:49
it is. Yeah. So, like, the I guess the Makes PHP high level view is yeah. Makes PHP fast and makes it so you don't have to boot the Laravel framework over and over and over again. I think that's probably the key part, and I figured out how to get that running on vapor which would shave off maybe, you know, 20 to 30 to 40% of the response time in vapor, which would be, you know, amazing if you don't have to, like, reboot the Laravel framework each time you're just running your app code.
Aaron
00:46:49 – 00:47:04
So we've Greg and I have messaged about it a little bit and I'm hoping that I opened a big issue on one of Laravel's repos with like exactly how I did it. And they looked at it and we're like, we'll do this maybe later.
Greg
00:47:05 – 00:47:18
Yeah. It's one of those things I think that one has to be, for that to work, I think it has to be part of the, like, the blessed path. I don't think you could do that as an add on. It's kind of there's some spicy things in there that
Aaron
00:47:19 – 00:47:41
No. I was I was, like, I was dipping into, like, the container runtime. Like, part of part of the way that I got it to work was during the deploy process. I overwrote the runtime handler that Lambda uses with vapor. And it's like that's not a good thing, like that's not a good thing to be doing from the outside.
Aaron
00:47:42 – 00:47:55
And I don't want to be personally as Aaron. I don't want to be responsible for dorking up somebody's you know, run time when vapor inevitably changes. Yeah. Exactly. So
Greg
00:47:56 – 00:47:58
Yeah. That'd be cool if that's on the ground.
Aaron
00:47:59 – 00:48:00
Yeah. Yeah.
Greg
00:48:00 – 00:48:22
I mean, for us, that'd be great. Again, it's I'm looking at this stuff from an SEO and from a page speed performance point of view. And if I could get, 40% of that time back, that that would just be golden. So, yeah, it'd be really, really keen to see that. I'll I'll pray to the Laravel gods to see to make sure we get them over the line.
Aaron
00:48:23 – 00:48:28
Yeah. Okay. So we agreed you're gonna write an article every week for the rest of the year.
Greg
00:48:28 – 00:48:28
I think
Aaron
00:48:28 – 00:48:29
we agreed on that.
Greg
00:48:31 – 00:48:32
I'll try.
Aaron
00:48:32 – 00:48:50
But you're not you're not gonna post it on LinkedIn because I'll never see it if you post it on LinkedIn. So post it on Twitter. So last thing on sidecar is there anything that I need to fix or anything that I need to add or have you this and and this would be great. Have you just completely forgotten that sidecar exists and you just go about your day job.
Greg
00:48:51 – 00:48:53
Well, that's probably the biggest compliment I can
Aaron
00:48:53 – 00:48:54
give you. Right? Is Yeah. That's great.
Greg
00:48:54 – 00:49:09
It feels like it's it feels like it's first party. And, like, I don't think about how commands work or how queues work. I just use them and they just stay out of my way and sidecar's kind of the same. It's just, it's just there. I've it yeah.
Greg
00:49:09 – 00:49:23
It doesn't fall over. It doesn't give me any pain. It's just and and I mean, even even those little, like, sidecar classes you have to write that sort of tell it how to deploy and and Mhmm. What files to upload and so on. It's the smallest amount of boilerplate.
Greg
00:49:23 – 00:49:33
Like, I think ours is I don't know. It'll be like it'd be 15 lines of code just to kind of say, this is where the JavaScript is. These are the things you have to upload. This is what I wanna call it. Go away.
Greg
00:49:33 – 00:49:50
So yeah. I mean, from my point of view, it's, yeah. The biggest compliment I can give you is they're just we just don't even think that it's there. And in fact, the hardest part about the whole SSR thing is not thinking about sidecar. It's it's remembering that you can't do things like access document or access window if you want anything to work.
Greg
00:49:50 – 00:50:11
And that's not something that sidecar can can help with but, you know, that's kind of where we're thinking. It's like, oh, we don't access document, don't access window inside of your your components because you're not you're gonna have a bad time. It's not do this really complicated thing and and build your components in an awkward way because that's the only way that it'll work with sidecar. There's none of that at all. It's it's just yeah.
Greg
00:50:11 – 00:50:13
Completely stays out of our way, which is yeah.
Aaron
00:50:13 – 00:50:21
So weird. I'm so, like, it I'm thrilled to hear that you just don't think about it, and, like, you've basically forgotten that exists. Like, that's that's amazing.
Greg
00:50:21 – 00:50:40
That means it's It's a double edged sword though because you don't think you don't think that it's there when you sort of when you when talking about some of these, like, creative problems it could solve. It's because it stays so far out of your way, it's not the first thing that you go to when you're trying to solve the problem. And then, you know, in the middle of the night, you'll wake up and go, oh, hang on a second. There's that sci fi thing that could do something like that.
Aaron
00:50:40 – 00:50:45
Also, I'm never I'm never gonna get famous if everyone that uses it just forgets that they're using it.
Greg
00:50:45 – 00:50:49
You seem to introduce some really painful DX just so that everyone has to remember.
Aaron
00:50:49 – 00:50:57
Yeah. Exactly. I love it. Okay. So I think that's I think that's probably that's probably good.
Aaron
00:50:57 – 00:51:12
We can probably leave it there. I mean, that's the deepest we've ever gone on Sidecar anywhere. This has been a thrill. I'm so pumped to hear how y'all are using it and the fact that y'all don't think about it makes me so happy. So Yeah.
Aaron
00:51:12 – 00:51:19
Provided that it's not on LinkedIn, where can people find you online if they do wanna keep up with you?
Greg
00:51:19 – 00:51:25
So I'm on Twitter. I can't even remember my Twitter handle. I think it's at gregskirma, on Twitter. I can't either. Let me look.
Greg
00:51:25 – 00:51:28
Chuck it on the show notes or something. Yeah.
Aaron
00:51:28 – 00:51:39
I'll put on the show notes. Greg Skerman, s k e r m a n. Yep. And tell me, tell me about this avatar. Is this one of your children?
Greg
00:51:39 – 00:51:42
It is. That's my oldest. A long time ago when Oh.
Aaron
00:51:42 – 00:51:43
Long time ago. Yeah.
Greg
00:51:44 – 00:51:45
She's 7 years old.
Aaron
00:51:45 – 00:51:49
Okay. Yeah. So that is probably 7 years ago.
Greg
00:51:49 – 00:51:50
Probably 7 years ago.
Aaron
00:51:50 – 00:51:58
Okay. And then your, your company is iseekplant.com.au. Is that right?
Greg
00:51:58 – 00:51:59
That's it.
Aaron
00:51:59 – 00:52:07
Yeah. Iseekplant.com.au. And then tell me, again, you said Brisbane Laravel meet up? Brisbane. That's the one you run?
Greg
00:52:07 – 00:52:09
The Brisbane Laravel meet up.
Aaron
00:52:10 – 00:52:10
When
Greg
00:52:10 – 00:52:20
I do tweet, I generally tweet about that. So Perfect. Okay. Well, well, this is come in come in for a talk on the next one.
Aaron
00:52:20 – 00:52:25
Oh, I would love that. That would be so fun. Yeah. I would love that. This is this has been a blast.
Aaron
00:52:25 – 00:52:43
Tell tell your team, just give them all of my thanks for I think they had some good suggestions for sidecar and let them know if they ever need anything to reach out to me. And thank you for DMing me great ideas at all hours of the night, my time. And then
Greg
00:52:43 – 00:52:46
I I I'm sorry about that. The time zones are a killer on me.
Aaron
00:52:47 – 00:52:50
No. It's it's great. Yeah. I I'll wake up wake up in the morning with
Greg
00:52:50 – 00:52:52
a stream of consciousness. Exactly.
Aaron
00:52:52 – 00:53:03
I do. And I'm like, hang on. It's too early. What the hell is Greg even talking about? But, no, it's a lot of fun, and this has been great, and thank you so much for coming on to the show.
Aaron
00:53:03 – 00:53:03
Yeah.
Greg
00:53:03 – 00:53:06
Thanks for having me. This has been great. We should do it again sometime.
Aaron
00:53:07 – 00:53:10
We will. Alright. Talk to you soon. Later. Bye.
Me

Thanks for reading! My name is Aaron and I write, make videos, and generally try really hard.

If you ever have any questions or want to chat, I'm always on Twitter.

You can find me on YouTube on my personal channel or the Try Hard Studios channel.

If you love podcasts, I got you covered. You can listen to me on Mostly Technical.