Microservices in your monolith

Speaker 1

All right, I, I think, I think the live stream started. Give it a second here. Um, and hello from YouTube, maybe. Let's see, it's going. Yep, okay, we're good. All right, mute myself. Uh, and take it away, Aaron.

Aaron Francis

Okay. All right. I am going to share my screen and... All right. If that's not coming through, chime back in, but I'm gonna assume it's coming through. Um, okay, let me see if I can move these controls.

All right, here we go. So, um, like Logan said, I am, uh, a, um, developer educator at PlanetScale, and I'm gonna talk to you about something a little bit different than databases tonight. Um, gonna talk to you about putting microservices in your monolith, which is gonna be a lot of fun, I hope.

Um, my name's Aaron Francis. Uh, I just started at PlanetScale about a month ago. I am a Laravel developer by trade. Um, but now I'm a developer educator teaching people about MySQL and databases in general, and having a lot of fun doing it. Um, I am dad to two little babies.

We have- My wife and I have, uh, year-and-a-half old twins. Um, so we stay super busy, um, and it's a lot of fun. Um, you can follow me on Twitter @aarondfrancis. This talk has been sponsored, um, so I need to thank my sponsor who is inside right now with our two, uh, 18-month-old babies.

So my wife is my sponsor for every single talk because she bears a lot of the brunt of, um, handling the kiddos when I'm out here in the backyard doing this kind of stuff. Um, so thank you to Jennifer for allowing me, um, to have the freedom and flexibility to do this kind of stuff while she's in there with the kiddos. So thank you, Jennifer.

Okay. I need to tell you what my biases are before we start, 'cause that's gonna kinda color everything else, and you can kind of, uh, listen to everything else I say through my biases. I love monoliths. I think they're great. I think we have a lot of tooling for developing, deploying, and hosting. Like, a lot of our tooling is set up specifically for monoliths.

I personally like them because I find them easy to reason about. Um, I find having all of the code in one repository, um, is easy for me to think about. I like being able to deploy everything at once. I don't like, um, ha- splitting it across a couple repos and figuring out CI/CD in a couple of different repos.

It's hard, it's hard enough to figure it out in one and get it working in one repo, and then to do that to yourself a bunch of times, I don't like doing that. Um, so this is, this is my bias. I prefer monoliths. So this whole talk is gonna come from a, a place of how can we keep kind of like that warm, fuzzy monolith feeling, um, but still get some leverage?

Because what about situations where you do need to step outside of the monolith? Because you may have, um, you may have parts of your app or your service that you truly do need to scale independently. It's not like you think you might need to scale it, but you actually do need to scale it independently. Or if your monolith is probably PHP, um, one of the big frameworks in PHP, but you need like a node process or a Python

process or, God forbid, a Ruby process, right? If you need some other kind of language in your stack, now you're in this situation of, "Well, I am fully set up for PHP, but what about Python? Like, am I gonna manage that?" And then that stack complexity isn't just like, it is languages, but it's not just languages, because you could wanna put, um, like Headless Chrome in your stack.

And so now you're managing, um, the Headless Chrome binary so that you can run it to take screenshots or to do, um, scraping or fill out forms or whatever. So you wanna take one, like just one step outside of the monolith, and you run smack into a bunch of complexity, right? And so one of the solutions that people will say is to just use microservices.

Um, and that little word just, like, carries a lot of, of weight. It's doing a lot of work in that sentence of just use microservices. Because now you're in charge of how do I package these microservices? How do I deploy them? How do I secure them? So do you deploy them at the same time?

If not, is there some sort of versioning you have to keep in sync? At the very least you're either talking to your team about it or you're having to handle that mental overhead yourself. And then how do those services, like, how do they communicate? Is it over the public internet? Well, how do I secure that? Am I setting up some sort of API gateway and some sort of auth layer?

And now you're just spiral- spiraling into more and more complexity. Um, and so what I'm gonna try to convince you to do is to put a microservice inside of your monolith. And we're gonna do it tonight with a package called Sidecar, PHP, Laravel for now, but a PHP package called Sidecar that brings microservices into your monolith.

And so I think at this point it's probably important to commu- like, to be clear what I mean when I say microservice, 'cause it is a pretty it's a pretty overloaded term that kind of means nothing anymore. This is, this is specifically what I'm talking about when I'm talking about microservices. I'm talking about things that are, like, microservice shaped, but are on one of the serverless platforms.

So we're gonna take something from our monolith and deploy it to one of the serverless, you know, infinite scale or whatever, one of the serverless platforms. And so for the rest of kind of our conversation, this is what I mean. It's just functions running on a functions as a service, as a serverless, um, platform.

Microservice has much broader meetings, but I, I don't know what they are, and we're not gonna talk about them. So this is as far as I've gotten. This is as far as my skills have gotten me. Um, I would love to have the rest of these knocked out, but I need help from kind of everyone in the community. So right now, it's, it is Laravel and Lambda, and the Vercel driver is written by me, is open as a pull request.

I just haven't finished it, so it's a draft. So I've written Laravel, Lambda, and Vercel. If you want to write one of these other ones, or you like this pattern and wanna, like, co-op Sidecar for your community, please let's do it, and let's talk about it and figure out how I can help you. So with, um, with Sidecar, these microservices, these microservices live inside of your monolith.

Um, and they are... So there, it's a, it's a single code base. The microservice lives inside of the monolith. They're deployed along with your monolith. So they're deployed at the exact same time that your monolith is deployed. They're actually deployed from your monolith. Um, and I think maybe the most interesting part is they are executed from your monolith.

So this is a big, like this is a big trade-off, um, that I personally think is worth it, and I'll show you what it means here in a second. But this is a big trade-off because I don't, or Sidecar doesn't create, um, publicly accessible URLs yet. Um, you have to execute it from inside your monolith's code base.

And the way that that works for Lambda is it executes through the AWS SDK, so it's like a direct invocation through the SDK, not through any sort of API gateway or publicly accessible, um, function URL. So it's really nice because you don't have to set up API gateway, you don't have to secure anything. It's all done through keys and tokens through the AWS SDK.

I think it's a good trade-off. I'll show you why in a second, but it's absolutely a trade-off that doesn't come for free. So if you are, um, visually, visually inclined, this is the best picture I could come up with to demonstrate what I'm talking about. Your monolith remains in charge. Your monolith remains your main driver, but bolted onto it, connected without being able to separate it, connected to it is, um, Sidecar

and Sidecar functions. Whether that's Node or Ruby or Headless Chrome or Python or whatever it is, it is connected to your monolith, who remains the driver. The monolith is still in charge. So, um, that's kind of the theoretical.

I wanna show you a little bit of the practical by doing a little bit of live coding here. Um, so hopefully this goes well. Um, I can't see my cursor. There we go. So what we're gonna do is we are going to write some microservices.

We're gonna write some functions, then we're gonna deploy them to AWS. So not only are we live coding, we're live deploying to AWS on a Zoom in my backyard shed, so hopefully this goes well. I have here just like a, a totally stock Laravel application. Um, I have installed, I have installed Sidecar, the package.

So I've composer required Sidecar. That's it. That's all we have here. So the first thing we're gonna do is we're gonna create a new class, we'll just call it Basic Function. And this is going to be basically our container for our, our, you know, microservice. We're gonna start by extending Lambda function, which is a class that Sidecar ships with, and we'll add the method stubs here.

There are only two methods required, um, and that's handler and package. And we're actually gonna start with the second one. So this, this package, um, this tells Sidecar which files to ship to the serverless platform. So this is either, like, your entire node modules directory.

This is a bunch of images. This, this is whatever you want, but it lives inside your monolith. In our case, we're just gonna ship a single file. We're, we'll call it Sidecar basic.js. So we're gonna ship one file, JavaScript file. That's gonna be our microservice. So we'll come down to Sidecar, do basic.js, and then we'll put a JS handler in here.

And what a JS handler is, is it's just a function. It's just a JavaScript function. Um, we put it on the exports object, and I just happened to name this Handler. You could name it FUBAR if you want, but Handler seems to make a little more sense. Um, and that's it. That's, like, the entire entry point for your microservice.

From here, we're just gonna say return, "Hello, world." I hope Um, hopefully this works. So that's gonna be the extent of our service. We'll hop back to the PHP class, and in here, now we have to fill out this second stub, which is the handler. Now, if the package is the set of files, the handler is the path to the specific function that you want.

So in our case, we're gonna say return Sidecar basic, which is the file path. You don't need the JS because it's a Node runtime, but you do need to tell it which function in that file we should use. So let's just double-check that we named it handler, which we did. Um, and that's where handler comes from.

That's it. That's all you have to do. Um, we're gonna ship some files, one in our case, and now AWS knows of all of those files, which file and which function should I use. We're gonna add one more thing that's not strictly required, but I like to be explicit about it. We're gonna say that the runtime is Node 16.

I think by default, the runtime is Node 14 because this was written, I don't know, a year ago maybe, um, Sidecar was. So I'm gonna bump it to Node 16, um, and I think that is it. So we've written our function. Um, now all we need to do is in our, um, sidecar.php, this is just a configuration file.

I'm just gonna tell Sidecar that this function exists. Whoa, don't do that. Um, there we go. So now I'm basically just adding it to a registry so that Sidecar's aware of which functions I want to deploy. There are a lot more options in here. You can do all kinds of stuff in here. Um, that's all in the documentation. This is the fun part.

Okay, so we've written our function. Now let's see if we can deploy it. So we're gonna deploy this function to Lambda through, um, through this monolith. So I'm gonna run PHP Artisan, which is Laravel's CLI thing. Artisan Sidecar, and then I'm gonna say deploy an activate flag.

And with any luck, if we run this, you're gonna get a bunch of output that I think is pretty. I wrote it, so I'm biased, but it's nice and, uh, formatted here. So what happens here is deploying basic function to Lambda as this long, ugly name, which is totally configurable.

It is a Node function. Function already exists because I was practicing earlier, um, potentially updating the code. So it, it actually noticed, hey, this function exists. Let me just, let me just update it instead of creating a new one. It put the zip file on S3, which is a Lambda requirement, and then it updated, um, it updated the function.

I'll talk about activation in a little bit. So in theory, that Lambda function is now on AWS ready to be invoked by us somehow. Um, and that's where I think it, like, that's where I think the trade-offs really start to show because we can invoke that function just by saying basic function execute.

That's it. Like, you saw the only thing that I had prepared was I had a Laravel app installed, and I installed Sidecar. That's it. So now we have deployed... We've packaged, deployed, and we're about to execute a Lambda function, and this is the extent of it. So if I hit this in the browser, with any luck...

Hey, there we go. So hello world, I hope. That is coming from Lambda. So the browser hits PHP. PHP uses the AWS SDK to invoke that function on Lambda and then send the response back, which then sends it back to the browser. So we did it.

Like, that is, that is a relief. It worked. But let's keep going because there's a lot more to show. In this basic function, I think a lot of people maybe have Node on their web server because you're doing some sort of maybe asset compilation or whatever. Um, but you might not have Python 3.9, or for whatever reason, 3.8 is absolutely necessary.

So you can just swap these runtimes, and the cool part is Lambda manages that for you. So you, you do, like, you lose a little bit of control because Lambda's in charge now, but you gain a lot of simplicity because you're like, "I don't care what you do. Just give me Python 3.8, and I'll send you some files, and you take care of the rest." So what we're gonna do here is I have copied off of the internet this Python file because I know nothing about Python.

It's basically the same deal. Um, it's a handler function, which again, you could name Foo if you wanted. Handler is a good convention. It's a handler function that says hello from Python, and then what this one does is it pulls an execution environment. So it pulls an environment variable out, um, and it tells you, um, what Lambda is running under the hood.

So this is just a nice, like, proof of life that we're not running it on my machine, basically. Okay, so this is named python.py. Let's make sure we did that right. Python.py is good. We switched the runtime to 3.8. Could be 3.9, who cares? Um, Python at handler, and our function is named handler.

So I think we're good to go. Let's deploy this one and see what happens. So it notices again the function already exists. Um, it did switch the runtime to Python 3.8, and then it updated everything and activated version 4, which is the newest version. So if we hit this from the browser, we should see... Yeah, there we go.

Hello from Python AWS Lambda Python 3.8. So, um, Lambda injected that environment variable, and we just pulled it out and sent it back to PHP. So now you can kind of start to see, like, wow, I can get a whole new stack to run this one stupid little function that I had to run without bringing in that complexity into my main, um, web server setup.

So let's continue on, 'cause these Hello Worlds are kinda, like, they're kinda interesting, but maybe not that interesting. Um, so instead of Hello World, let's say hello event.name, and this is where it starts to get a little bit more powerful even. Um, let's switch all of this back to JavaScript.

Okay, Node 16, basic JS, basic handler, and let's look at this handler now. So when I wrote this handler, um, there was an event parameter there. Now I'm just gonna pull stuff off of that event parameter and shove it into the string, and the question is, where does that come from?

And that is what we're gonna look at. So let's get this deploying. It switches back to Node, creates the zip file, puts it out there, and we're ready to go. So now if we hit this from the browser, you can tell we're running JavaScript again, 'cause that's the most JavaScript thing I've ever seen. Um, so Hello World undefined.

Should probably have named that Hello just name, but that's okay. Now we can pass data over the wire from our PHP side. So I didn't redeploy the function, right? I didn't redeploy the function Hello Merge PHP, but now I'm driving, I'm driving behavior, um, I'm driving behavior in a Lambda from PHP

without redeploying anything, right? So now you're in this world where your service lives inside your monolith, so it's all in the same repo, which is very tightly coupled, which I, I think in this case is a, is a good thing. You may disagree, but I... That's why I like this so much, 'cause it's so tightly coupled. So now you have this service and this calling code all in the same repo right next to each other.

You are in control of both, and so you can make it as complicated or sophisticated as you want. You can write your handler to accept this massive configuration object and have, like, 1,000 different routes through the code, and then drive everything from your PHP side, right? So now you're in a world where you have full and ultimate control over this handler and the calling code, and you can do whatever you want, whether that's scraping or taking screenshots

or whatever. So one of, um, one of the promises... Let's go back to this. Let's say, uh, I think it's JS sleep. Here we go. So one of the promises of Lambda, and one of the reasons I said that you might consider doing this, is if you need to scale something independently, right?

So if you have a process, um, that you have to do a lot and it takes a long time, and you're bound by the resources on your, your current web server, that would be a good candidate to, like, farm out to one of these infinite scale platforms, right? So if we say that this is, um, this is some sort of processing thing.

So what's gonna happen here is this is gonna sleep for two and a half seconds, um, and then it's just gonna return hello event.name. So this isn't gonna do much, but let's pretend that this is some sort of Python script running some sort of data analysis, right? All right, so we need to redeploy this. I don't think anything else has changed, so we can just redeploy this, and that'll go.

That will update. There we go. And if we hit it in the browser, it should take a while. So two and a half, two and a half seconds. So it takes a long time, right? Here's the deal.

If you needed to run, um, if you needed to run a bunch of these... So let's say you've, for whatever reason, you're trying to fan out and you're trying to run three of these functions. Well, this would be the worst way to do it, to execute three in a row and return the response bodies, because bear with me, this is gonna take seven and a half seconds plus a little bit of overhead, and it's gonna be so boring.

Okay, so hello response one, two, and three. Seven and a half seconds. Total waste of time. The whole point of Lambda is that there are a bunch of them, right? So instead of doing it like this, what you wanna do is you wanna say execute many, and what this is gonna do is this is gonna put them... This is gonna run them all in parallel, which is kinda wacky 'cause PHP doesn't really do that, but we can thank Guzzle for this one.

So if we say execute many, need to put some commas here. Execute many. We're gonna execute three different payloads. And instead of, uh... Let's rename this guy responses, and we'll return collect responses map, and then we'll pluck out the body.

So what we're gonna do is we're gonna tell Sidecar, "I've got three payloads. Please execute them in parallel, not sequentially, in parallel." Then once they're all done, collect them back up, map over them, pluck out the body, return that to the browser. So with any luck, this'll take two and a half seconds instead of seven and a half seconds, and it's kinda hard to see.

So one, so that's three, six, nine, 12, 15. So if we ran 15 of them, it's much easier to see that this doesn't take whatever that would be, 30 something seconds. It takes two and a half seconds plus a little bit of overhead, right? So if we were to do that again, and instead of however many that is, we did double that, you could run it again and it just keeps fanning out, right?

So now we've got whatever that is, 30 that are coming back. And now that all those containers are warm, it's gonna be two and a half seconds just with a little bit of overhead to get the respo- the request out and the response back, 'cause all those containers are warm now. So now we've warmed up all these Lambdas. They're just sitting there waiting for requests, and we can just fire requests at them. So this is one of my favorite things, is that you can scale out horizontally like this.

And just as a little bit of, like, nerd trivia, the way that this works is, um, Guzzle PHP, which... So it's Sidecar, then the AWS SDK, and then Guzzle. So AWS sits on top of Guzzle. Guzzle has this really cool, um, cURL Multi driver. Who, who knows how it works?

I'm sure some of you do. But basically what it does is it's not like promises, um, but they're treated as promises. It's like a JavaScript promise brought to PHP, but only for Guzzle cURL Multi. And so it basically, like, collects all the HTTP requests, and then when you are ready to fire them off, it fires them all off at once, and then it kinda waits for them to all settle. Very, very cool.

I did none of that work, so I feel good saying that it's incredibly impressive. Um, but that's how this is handled. So if you wanted to fan out horizontally, you would do execute many. Um, there may be times where scaling out horizontally is, like, not that helpful, and what you wanna do is scale up vertically.

And you have a little bit of ability to do that. If we look at our basic handler here, we can change the memory per function. So instead of, instead of one gigabyte of memory, we could say, "Why don't we give this one, why don't we give this one five gigabytes or 10 gigabytes of memory for this specific little function?" And there's actually, I asked on Twitter earlier for use cases, and I'll show you some of the use cases after this.

Um, I asked on Twitter, like, what are you guys using this for? And somebody is using the 10 gigabyte Lambda, which is the max that they will allow you to provision. Somebody is doing that to generate, um, PDFs, so I'll show you in a little bit. So this is how you would scale that up vertically. Um, and then scaling it horizontally, you would just execute more.

Just run them in parallel. And you know, of course everything has the cost, um, but the cost for Lambda is pretty low at, you know, reasonable volumes. So you might consider scaling up the memory to get shorter runtimes or fanning out to get faster aggregate runtime. So let us, um, let's keep going.

Um, I am very glad that that worked. It's always a risk and, um, we can skip this slide, but I just leave it there just in case. But we can skip it today, which is good news. Uh, I wanna talk to you just real quick here at the end, um, about the deployment story, because I think one of the promises I made up front is that this is a better way to deploy, um, a microservice, and I just kinda breezed through, like, deploying it to Lambda.

So I wanna show you how this might fit into your existing workflow, which is really important to me. I want it to fit into what you already have. I don't wanna saddle you with a bunch of new stuff. What we have here is, um, this happens to be a Vapor.YAML, which is a Laravel service. That part's unimportant. I think the important part is that it gives you a build step and a deploy step.

And so Vapor says, all right, you can do things while your application is building and, um, going to be deployed, and then you can do things like the moment before it's flipped live. And so you have these two separate steps. Build usually runs in CI or, like, GitHub actions or something, and deploy usually runs on the server that's about to flip the symlink or whatever your deploy process is.

Let's look at the build step first. We have separated, um, we have separated the Sidecar deploy process into two distinct steps. I was running them as one step. If you remember, I had the dash dash, uh, activate flag. I was running them as one step. They're actually two distinct steps. The first step is to deploy the function.

And in the deploy process, there are a lot more things required than in the activation process or in the execution process. In the deploy process, you need all the files, right? You need all the files that you're gonna ship, and you need a little bit of time to package it all up and ship it off to Lambda.

Mine was super quick 'cause it was one file, but imagine packaging up node modules and just imagine how long that could take. It could take, you know, up to 30 seconds or more. Um, and so what this does, this deploy command packages your function and puts it on Lambda, but does not activate it.

You are not able to hit it through Sidecar. You're not able to hit it with requests. And so it's just out there waiting. And then- Right before, um, your new app code, so right before your new monolithic code goes live, this would be like at the same time you kind of run migrations maybe. So you run migrations and flip it live or vice versa.

So this is when you would run Sidecar activate, and what that does is it fires off a single API request to, um, AWS that says the most recent version of the Lambda that you have, make that one available. So it's super fast 'cause it's not send- like, it's not sending any files, it's not making any zip files.

It's just saying to Lambda, "Go. I'm ready." And that's what keeps your, um, your monolith and your microservice in sync, is because you can put it out there and just wait, just wait and wait. And then when it's time to go, flip it on, and they're both in sync ready to go. So your old monolith runs against your old service, and then your new monolith runs against your new service.

So I wanna talk... I had a whole bunch of, um, use cases. I wanna talk about one in depth, and I'm super familiar with this because this is, this is, this is about me. Um, so it's kind of a cheat, but this is the reason that I wrote, this is the reason that I wrote Sidecar. I was writing, um, documentation for another product that I have, and the syntax highlighting was frustrating me because it was missing a bunch of like the PHP 8 stuff.

And so like every developer would do, I stopped working on documentation and started working on a new product , which, whatever. Um, so Torchlight is a syntax highlighting API. So instead of highlighting code in the browser, I have clients that gather up all the unhighlighted code, and it sends it to a central server, which is me, that does all the highlighting and then sends the highlighted code back.

So that's the setup. And this is kind of, um, this is kind of what it was in the beginning. It was a central single, um, API endpoint, basically. I've had to since change it because when it was a central, um, when it was just a single process highlighting the code, um, it worked fine when people would send me 5 or 10 code blocks in some, in like a single request.

But then it started getting like used in bigger sites and it, like specifically static site generators and the Laravel documentation. And so it would gather up literally like 150 code blocks and fire them all at me. And it was like, "Hey, can you highlight these in under a second?" I was like, "No. In fact, I'm gonna fall over on my face and not highlight them at all." So that's embarrassing.

So here's what I have now. I have this Laravel router that sits on fly.io, which is a super cool service if you haven't checked it out. Highly recommended. Um, in this router I have this, this, this is kind of pseudocode, but you get the point. I have this little endpoint that is just highlight. Um, and the first thing that happens when like 150 code blocks comes, come in, is I partition them by lines of code.

So if I got one giant guy, I'll highlight it by itself, and then like 10 little guys, I'll put all those together. And I highlight it or I partition it by lines of code. And then I just run it through Sidecar and say execute mini. And it could be, it could be 50 different Lambdas that fire up. It could be 100. It could just be one. But the point is, I'm basically setting kind of the upper bound of response time based on how big I allow my partitions to be.

And then I just get all the results back, kind of put them back together, and send it back to, um, the requester. And so now this is what my, this is what my, uh, infrastructure really looks like, is I've got my Laravel router that does two very stupid things. It does partitioning and caching. So I cache at the Laravel router layer, and then I partition the blocks and fire them out to Lambda, and all of those Lambdas are controlled by Sidecar.

So that's kind of, um, my setup, and that's one of the reasons this exists. I did ask, um, I did ask on Twitter yesterday, um, I was like, "It would be really cool to have other people's use cases." I know, I know what a lot of them are, um, but I wanted, I wanted people to like say it in their own words.

And so I asked, "Hey, what are y'all using it for?" Um, the first like, the first like 10 of these slides, they're all PDFs. So a lot of people are using Sidecar to do PDF generation, which makes sense. It's kind of a pain. Um, some people are generating PDFs.

Some people are manipulating. This guy is taking an image of the first page. This one I found really interesting. Um, they're using it to parse and automate filling of forms embedded in PDF. And so this is one of those things where it's like there's a super good JavaScript library for it, and boy, it would just be better to use that than try to recreate it in PHP.

And that's when you reach for, that's when you reach for Sidecar, when you're like, "Man, I don't wanna become a subject matter expert in filling forms in PHP. I'm just gonna use this JavaScript library." Um, there is a package in the Laravel space called BrowserShot, um, and a guy called Stefan Zweifel has written a bridge, um, between Sidecar and BrowserShot.

So now you can use the BrowserShot API, which is really nice and expressive and stuff, but your Chrome instance is running on Lambda. So it's like the BrowserShot you know and love without having to deal with Chrome at all. Um, so that's kind of cool. PDF generation, this is the guy, this is the guy that's doing, um, that's doing 10 gigabyte Lambda.

Renders hundreds of pages in a few seconds, which I just, I just can't even fathom that. Um, he's using Prince, which is a little bit lower than, um, like using something like a headless Chrome. Um, but this, this made me smile 'cause I was like, "Oh, you're the one person that I've heard of that's using 10 gigabytes." PDF generation, PDF generation.

This guy's doing QR code detection as well, which I think is interesting. PDF generation, um, PDF generation. But then they're also, um... This guy's name is Chris. He's also gonna use it as a part of the Laravel, um, compilation process to transpile, transpire, transpile ES6 to ES5, um, which he's already doing locally, but he wants to kill the node process.

Open Graph images is another fun one. Um, you can use this along with a couple JavaScript libraries or headless Chrome to generate images for your blog posts, and they can be super dynamic, right? 'Cause you can send stuff over the wire. It just keeps going. This guy's doing a PyTorch model. I don't fully even know what that is, um, some sort of machine learning thing.

Um, but he passes the text over the wire and structured JSON comes back. Um, this person is compiling email templates. Mailziel is a super cool, um, email tool, and apparently there's a compile step, and so he's running that on, um, Lambda as well. Parsing content, no idea what that means, but great, it works.

It's node. And this is one of my favorites, 'cause it's just so wacky. Um, so this guy, Philo, runs a super great service called Unlock.sh, and it lets you sell private, like, composer packages, private node, um, NPM packages, and also private RubyGems. And the deal with the RubyGem is for him to figure out the correct file format such that the, um, package manager will recognize it, he has to run Ruby.

And he didn't wanna, he didn't wanna futz about with figuring out how to do that, and so he builds this RubyGem, um, manif- manifest file in a Sidecar, and then sends it home, um, back to his, his Laravel app. And I just, I just... That just tickles me. I love that one so much. So I would ask you to consider putting a microservice in your monolith.

When you run into something that is microservice shaped, maybe not whatever real microservice is, but it is shaped like a microservice, I would ask you to consider this pattern. If I don't have Sidecar for your community yet and you wanna do it, let's talk about it. I think the pattern is really interesting, and I think it is a, um, in my opinion, I think it is a reasonable middle ground between going full microservices and also it is a nice escape

hatch from staying strictly monolith. So that would be my request to you. Consider it. It might work for you. If it does, it's kind of a lot of fun. Um, that's it. That's all I've got. Um, you can find the docs and everything at hammerstone.dev/sidecar. Um, and you can find me on Twitter @AaronDFrancis.

Um, and then if you're gonna be at Longhorn PHP, I'll be there as well. So that is it. That's all I've got. Um, Logan, I will hand it back to you. Let me stop my, uh, let me stop my screen share here.

Speaker 1

Awesome. Uh, thanks Aaron. Uh, thank you all for joining us, uh, for October Merge PHP. Um, get your questions ready here. Um, I, I guess if there's any questions, um, uh, uh, you know, you can ask it here in the Q&A or in the chat should also be working. Uh, thank you so much, Aaron.

I really appreciate the talk.

Aaron Francis

Yeah. Yeah, you're welcome. Whew. It's always a relief when it works.

Speaker 1

Yeah. Successful demo. All right, I'm gonna stop the recording