A little bit more Lambda

Speaker 1

All right. We're gonna have Aaron come in here. Stop my share. Hello?

Aaron Francis

Hello. Can you hear me?

Speaker 1

Yes.

Aaron Francis

Perfect. Got it. Okay. And I will share my screen. Okay, are you seeing that?

Speaker 1

Yep, I see it. You're good.

Aaron Francis

Okay. Starting the timer. Here we go. All right. I'm gonna start my slides. So, I've got a lot to cover in the next 40 minutes, um, so I'm just gonna dive right in. The title of my talk is A Little Bit More Lambda. It would've been better if I had called it Add a Microservice to Your Monolith.

I stole this title from my friend Samuel, so thanks, Samuel, for the better title, and we'll see as we go why this makes a little bit more sense. Um, before we dive in, a little bit about me. My name is Aaron Francis. I'm a software developer in Dallas, Texas. I have a full-time job at a property tax company.

I'm also the co-founder of a company called Hammerstone, where we make, uh, software components for your Laravel and Rails applications. You can find me on Twitter, @aarondfrancis. I'm there all the time, so if you're there, I'm probably there too. More important than any of that, and more important than anything I'm about to say, is I'm dad to two nine-month-old babies, so my wife and I have nine-month-old twins, which is 100 times more important than anything I'm about to talk about.

But y'all don't care about that, so we will move on. Um, a disclaimer. This has almost nothing to do with Vapor. So if you're not using Vapor, please don't tune out yet. You can tune out in a second, but don't tune out yet. I know that I said Lambda, and this is a Laravel conference, but it has nothing to do with Vapor. So this works on Forge, it works on Heroku, it actually does work on Vapor, and it also works on your local machine, which is what we're gonna be doing here.

So, if I'm setting out to solve the problem, what is the problem? Well, the problem is monoliths are great and Laravel is great. We looked earlier at moduli- modu- yeah, at monoliths, and we love monoliths. We have all of this tooling that makes monoliths great. So deploying, developing, hosting, all of that is super great, and we love that part about Laravel, right?

But what happens when you need to step, like, half a step outside or a, a one step outside of Laravel's default stack, right? So maybe you need, um, a node process to run Inertia server-side rendering, or maybe you need Headless Chrome to take screenshots with Browsershot, right? So now you're in this situation where you have to inherit or take on some DevOps complexity, and this screen grab on the right is somebody adding Chrome to Docker so they could run it on Vapor.

So you take just the smallest step outside, and you have to figure out a little bit more DevOps stuff. So what is a possible solution here? One solution would be to use Lambda, right? So if you use Lambda on your own, you get, um, you get AWS managing all of the stack for you, right?

So they'll give you Node, Python, whatever. But you have to take on, um, deploying, packaging, executing the Lambda itself, right? And so now you're in this situation where you've got two separate repos, you've got two separate deploy processes, and then you have to figure out, how do these two things talk to each other, right?

So you've got this Lambda over here. Now you need to put API gateway in front of it, and you have to secure that endpoint because it's now public to the internet, and you have to write a client on your Laravel side to talk to that. It just gets to be a pain. Serverless framework is amazing and it solves a lot of these problems, but for one, like, for one stupid function, it's really heavy to set all of that up, um, and it's kind of frustrating.

So my solution is a little bit of Lambda using Sidecar, which is a, um, Laravel package that I wrote. Using Sidecar, the Lambdas live inside your Laravel app, no separate repo. They're deployed along with your Laravel app, and they are executed through your Laravel application.

There is no public interface. There is no API gateway. Everything is executed under the hood through the AWS SDK, so there's nothing to secure. In fact, we don't handle API gateway, databases, resources. We handle packaging, deploying, and executing Lambdas. That's it. So you can think of this as like the ease of Laravel Vapor, but for one little function.

Not for a whole app, just for a little function. So for you visually inclined people, this is what we're talking about, right? We want Laravel to be the main driver. Laravel is our main app. And then in the Sidecar, we can put Node, we can put Ruby, we can put Chrome, we can put a little dog. We can put anything we want in the Sidecar, but it stays connected to our Laravel app and we deploy it together, right?

So as Taylor is fond of saying, DHH is fond of saying, show me the code. So let's get out of these slides and go look at some code. We are, with any luck, gonna deploy and execute some Lamba- Lambdas. So we'll be live coding and live deploying to AWS and really just hoping it all goes well.

So we're gonna create a basic function here, and it's going to extend Lambda function. And Lambda function ships with Sidecar. I've already composed a required Sidecar. If you implement the two methods that are required, you'll see that it's package and handler And package is the set of files that you want to ship to Lambda, right?

So in our case, we are just going to return sidecarbasic.js. You could, if you wanted, um, ship your entire node modules directory. That's fine. It'll work. We're not gonna do that. We're just gonna ship a single file. We'll come over here and create basic.js. So now this is the function, or this is the file that we're shipping.

So we need a JS handler, and what this is, is it's, it's just a function, and we named it Handler and put it on the exports object. Nothing too fancy. We're gonna return, um, a Hello World, but we're also going to pull an environment variable out of the Lambda runtime. So this is to help us see that, in fact, this function will be executed on Lambda, not on our local machine.

So we're just gonna pluck something out and plop it in the string. So that's the package, just basic.js. That's it. The handler tells AWS, "When you call this function, here's what you should actually call." So what we do is we give it the path to the file and then the name of the function.

So we don't have to put j- .js because it's a node runtime, and it will look for the js. In fact, we can make the runtime explicit, um, by saying node. That's not totally necessary because by default it is, you know, node 14 is the runtime. But we're gonna change that later, so we'll make it explicit for now.

So this is all that's required on the PHP side to develop a Lambda function. We have the handler that says, "Please call this method," and we have the package that is the entire set of files that we need. So to deploy this thing, we're gonna come to Sidecar PHP, which is our configuration file, and we're gonna say basic function class.

So all we're doing here is we're letting Sidecar know, "I've got a function. It's called basic function. Please deploy it." Let's take a look first at the console. We see there are no functions here already, which is good. We're in US West Two because there are never any bugs on the West Coast, and so we're gonna go ahead and try to deploy this thing. To deploy, it's pretty easy.

You say Artisan Sidecar deploy. We are also going to pass a flag called activate, which we'll talk about in a second. So fingers crossed. Well, okay, that went great. Um, so we just deployed our first Lambda function, and if we look in the console, we do see that the Lambda function is there, so this is going well so far. We deployed basic function to Lambda as this long string, which is customizable.

You see we're in the local environment. The runtime is node. It noticed this function doesn't already exist, so I need to create a new one, which is good, and then it packaged the files, put the zip on S3, and then because we asked it to, it went ahead and activated the function, right? So good start so far. We have packaged and deployed a Lambda function.

Now how do we execute it? Well, we just call basic function execute. That's gonna execute the function on Lambda, and we're gonna return body to the browser. We could return logs. We could return is error. We're gonna return body because that's what we wanna see. Okay, this is the final risky step.

If we refresh this, look at that. So we have now, um, packaged, deployed, and executed a Lambda from our Laravel application that lives inside our Laravel application and is running node 14 somewhere out there, right? So pretty cool so far. It gets a bit cooler when you start thinking about what if we didn't have a node function?

What if we had a Python function? I don't know Python, so I copied this off the internet. This is gonna do the same thing. This is gonna say hello from Python, and it's gonna pluck out an environment variable from the Python runtime, right? So let's check our basic function Python handler. The runtime is Python. The package is python.py. That's great.

We're gonna deploy and activate again. And you see that Sidecar just happily changes the runtime. So the runtime was node. It's now Python. It noticed the function exists. I'm gonna potentially update the code and configuration. Um, because stuff changed, it did update the code and configuration, and now the new one is active.

So if we hit this from the browser again, we see that we're now running Python. We switched our entire, like, infrastructure in what? I don't know, 30 seconds. So you're starting to kind of hopefully see the power of this. If we take this back to node, because I don't speak Python, if we take this back to node, and then we come back to our node handler, we'll drop this ugly variable.

We'll get excited. We'll say hello. Uh, let's do event.name. So we're gonna say, "Hello event.name from Lambda!” because we're excited to be here. So we're gonna do something a little bit different on the deploy process though. Instead of saying activate, we're just gonna deploy. So we'll see it, same kind of deal.

It's switched the runtime to node. The function already exists, creates a new zip file, puts it out there. The code is updated, right? You don't see that second part that says configure or, um, activating. And so if we hit it from the browser again, you see that we're still running Python, right? And so this is great because you can separate your deployment step from your activation step so that you can deploy from CI and then right when your Laravel, like, right when your new deploy goes live, your Laravel app, you

can activate your new Sidecar function. So you can use one of those Envoyer hooks. You can use a Vapor hook, whatever. But you can deploy the heavy stuff from CI and then lickety-split activate the new one. So we've got that function out there that's waiting to be activated. If we say sidecar activate, you'll see that new function is activated.

So if we hit it again from the browser, we're, we're definitely running JavaScript, 'cause hello undefined, if, if that's not JavaScript, I don't know what is. So we're back to our JavaScript function. We've activated it, right? The undefined is because we're looking for event.name, but we haven't sent anything over the wire. So if we pull this out and we call this result and we call that result, we can send some data over the wire to Lambda, right?

Um, so if we hit it again, it says, "Hello Aaron." And if we hit it a third time, it says, "Hello Laracon." So now what we're doing is we are controlling the behavior, we're controlling the behavior of our handler from the Laravel side without redeploying our Lambda. And you can make your handler as, uh, complicated, let's say sophisticated, you can make it as sophisticated as you want because you control both sides, right?

You're controlling the part that's deployed, and then you're controlling the part that's calling it. So as long as you know, as long as you know what you're doing, you can call ... You can make it as complicated as you want and send any data over the wire without having to redeploy your Lambda a bunch of times. So it is cool, I must admit, it is cool to see Hello World.

Hello World is not, um, is, it's not the coolest, so let's look at some things that are potentially a little bit more practical, we'll say. So I was, um, talking about this talk on Twitter, 'cause I'm always on Twitter, and Stefan Zweifel reached out to me and was like, "Hey, I've almost got, um, Spotsy's Browsershot package.

I've almost got it working with Sidecar." So we worked together and finished that up, and now we've got Browsershot, but it's being driven by Sidecar. So there's no more deploying, like figuring out Chrome, there's no more Lambda. We have, like we have that figured out. So let's take a look at this function, and this is really cool because this is a Composer package.

So Composer packages can ship Sidecar functions to you, and then you deploy them into your AWS account, right? So they can create this utility that you then install and then if you want, deploy to Lambda. So it's very cool. You'll see some stuff here you recognize. The handler is Browsershot.handle. He gave it a pretty name because the fully qualified class name gets to be a little wordy.

This package is a little bit out of scope, but I'll come back to this in a second. Um, the runtime is Node. We gave it more memory, um, because it is, you know, launching a Chrome browser. The interesting part, um, an interesting part down here is layers. So if we're gonna run Browsershot on Lambda, we need Chrome, right?

There are a couple ways you could get there. You could, uh, NPM install it and then ship your whole node modules. You could just get the binary and ship the binary. Instead, what we're gonna do is we're gonna add a publicly available layer that brings Chrome to us, right? So there's this layer out here. If we look at this, you'll see it is Google Chrome for AWS Lambda as a layer.

So this brings Chrome to us, and AWS is just gonna plop it right on top of our Node 14 runtime. So we don't have to worry about if Chrome is there or not, it's gonna, it's gonna bring it for us. So let's deploy, what is this called? Browser, Browsershot function. So you can see it's the exact same setup.

I'm gonna turn ours off just 'cause it doesn't matter right now. Clear AR sidecar, deploy, and activate. So this is, this is, um, being deployed, and this is the driver for Browsershot. So that's out there. It's crazy how fast that can be deployed. Um, let's look at how you would use this guy.

We have been historically interacting directly with the Sidecar function, right? We've been calling execute on it. An interesting thing about this one is we don't actually interact with it directly. We're gonna call Browsershot Lambda, and then you can see, look, you see all of these Spotsy, um, completions over here.

So we're gonna go to google.com. We're gonna take a screenshot, and then I think it's image response. We're gonna return an image with the right header. So let's look at this Browsershot Lambda real fast. It extends Spotsy's Browsershot. So you have all of those methods, you just don't have to have Chrome.

What we do is we sneak into this call browser right here, and we will execute that command on Lambda instead of shelling out to a local node plus Chrome, right? So let's make sure we got this right. We're gonna go to, uh, google.com, take a screenshot, send it back with the header of PNG. Okay.

Let's see if this works. This is gonna take a second 'cause it's a cold boot, so it's gotta boot up a Lambda container. And then holy moly, look at that. So if we run it again, it should be a little bit faster 'cause the container is warm, right? So it's like, step back and think for a second what is happening. My browser is hitting Laravel.

Laravel is hitting Lambda. Lambda is launching a browser. That browser is going to google.com and then sending the screenshot all the way back to us. And that's like, that's like decades of people's infrastructure work across, across dozens of companies, and we set it up in like, I don't know, a minute or two minutes. And it's incredible to me that we get to use all of this and keep building nicer and nicer interfaces on top of it.

And so this is like, this is obviously very exciting for me because now we can do things- That used to be hard, are now very easy, and so we can do some very cool stuff, right? So you have to consider, like, the, the shoulders of the giants that we're standing on. It's pretty amazing. So if, if, um, if what Stefan has done here is on one side of the scale of practicality, what he's done is 100% practical, 100% useful.

Let's step into the realm of, uh, the truly bizarre. Let's step into the realm of, um, something that's completely wacky and potentially serves no purpose at all, but is very cool, and that's one that I wrote. So, um, if we look at ... We can close some of this stuff. Let's get rid of all of this. We don't need that or that. If we look at the runtime, um, constants that Sidecar ships with, you'll see all of the runtimes that are available, um, on Lambda.

So you see Node, Python, Ruby, Java, Go, .NET. Those are all of the runtimes that Lambda will provide. You can run code in that in two seconds flat, right? What happens when you wanna run PHP? We love PHP. Gotta love it. So what happens when you want, want to do that? Well, I know that Bref has figured it out, and I know that Vapor has figured it out, so I know that there's a way to do it.

Well, it turns out we have figured this out, too, and so what we do is I have a package called Sidecar PHP, and I'll have links to all of this later. Um, I have a package called sidecar-php. It brings you a PHP runtime that you can put on Lambda without worrying about a thing. So let's look at this real fast.

This is all boring. The runtime, the runtime is Provided AL2, and the Provided AL2 is saying, um, is basically the good luck with that runtime. Lambda will say, "Here's Linux. Have fun. I hope that you can figure the rest of this out." And so that's what, that's the runtime that we're gonna use.

But then we're gonna add a layer on top of it, just like we did with Chrome, except this time we're adding the Vapor layer on top of it, right? So Vapor builds PHP for Lambda and publishes, publishes it as a layer. So does Bref. I looked at both. Vapor fits, obviously fits Laravel a little bit better. So we're gonna bring PHP and smack it right on top of the Alpine Linux, and now we have PHP, right?

So now we can run PHP on Lambda. So before we go too far, let's, um, let's go ahead and get this deploying. Gonna turn that guy off. PHP Lambda, not execute, class. Uh, okay, clear that out. Deploy and activate.

So this is, this is now being deployed, right? You see that it's AL2. It's gonna be a little bit bigger 'cause there's some runtime stuff, and then we have environment variables as well. So if you look down here at variables, you'll see there are a few Lambda environment variables required to make the runtime work. We handle that for you, um, so you don't need to worry about that. But if you do want to add your own environment variables, this is the method there, where you would do that.

Okay, that's all out there. Let's take a look at how we would use this PHP function. Let's name it result, and let's say PHP Lambda execute. We have been historically passing through an array, right? Name Aaron, name Laracon. Let's instead pass through a function.

So if we pass through a function, you're already thinking, "Is that function gonna run on Lambda?" Yes, that's the whole point. So in this function, we're gonna do basically the same thing. Um, we're gonna pull an environment variable out of the Lambda container and return it to the browser, just as, like, proof of life, right? So if we return result body, we return that to the browser.

Let's see if PHP can run on Lambda. There you go. PHP is running on Lambda. So it's pulling the log group name out of the container, giving it back to the browser. There's one other variable that I have memi- memorized. It's handler. Handler's a no-op, and that's because handler here is a no-op. We handle, we deal with the handler ourselves.

So we're now running PHP on Lambda. Is this useful? I have no idea. I have no idea if it's useful. I know that it's cool. It's crystal cool that we are running PHP on Lambda where Lambda doesn't support PHP. My job, my job as the, uh, uh, uh, as it relates to Sidecar, my job is not to figure out if this is useful.

My job is to make it possible. So if I can make something that was previously very hard, if I can make that very easy, or if I can make something that was impossible possible, then you get to figure out why is this useful. That's not my job. I trust that y'all are gonna figure out why this is useful. I think it's super cool, and so I did it, and now you guys get to do the fun part.

One way that it is useful, I know one way that it is useful, and that is it serves as the base for Laravel Lambda. What is Laravel Lambda? Well, let's get that deployed before we do anything else. So let's get that deployed. We're gonna clear this, deploy, and activate. That's going. Let's look at Laravel Lambda.

Laravel Lambda is an extension of PHP Lambda, but it ships your entire application. So where PHP Lambda ships a bare runtime that lets you execute a closure without any vendor dependencies, eh, kinda cool, this ships your entire application to Lambda, vendor directory and everything.

Is this a replacement for Vapor? 100% no. It doesn't handle incoming requests. It doesn't handle responses. It doesn't handle a dang thing, right? It just puts your app on Lambda, and it waits for you to invoke it. You still have to invoke it from somewhere. Remember, this is a sidecar. This is not your main app. So we're putting our app on Lambda, and it's just sitting there waiting for us to invoke it.

So can we do something cool with it? Wellll, potentially. So let's take a look. If we have Laravel Lambda now instead of PHP Lambda, now we have Laravel Lambda. We could, if we could spell, we could, um, we can do all kinds of stuff. We can return one, which is pretty, pretty cool. Not super cool though, right? We have the entire context of our Laravel application, so we can do anything inside the context of our Laravel app.

So what if we were to call a Laravel command? This is the default one that ships with Laravel. We're gonna call inspire. Then we're going to return, uh, let's return artisan output. That's gonna take the, the output from this command and send it back to the browser. So hopefully, fingers crossed, it's gonna boot the cold container, and then it's gonna run.

Look at that. It's gonna run the, um, artisan command in Lambda. It's not running locally. So if we do it again, you see it's faster now 'cause the container's warm. And so now we have our entire app out there waiting to be executed by you from the same copy of your app, right? So we're in this weird multiverse setup where you have your app in base reality, and then you have infinite Lambdas out there just waiting for you to ask it to do something.

So if we can just, like, let's just keep going because let's say it's been a day, let's say it's been a bad, bad day, and inspiration times one is not enough, and you want inspiration times two, three, four, five. Let's call it inspiration times 10. But you don't want these to run back to back to back because that's lame.

Who would do that? You can ask Sidecar. You can tell Sidecar, execute these all at once. It's Lambda, it's, you know, infinite or whatever, so 10 isn't gonna hurt us. So if we execute all of these at once, properly, this should be called results. Messed that up. Properly, this should be called results here.

We'll need to do a little bit of mucking around. We'll collect this, um, we'll map over the results, pluck out the body, and implode with a BR. So what we're doing is we're gonna run 10 commands in 10 containers, collect all the results, and return them. So now it's gotta boot nine more containers 'cause, you know, those were cold.

But now we've got our 10 responses here. And now that they're all warm, look how fast we're running 10 copies of our app just somewhere. Who knows where? It's out on Lambda. I don't know. And what if, I don't know, instead of 10, you want 20, 30, 40, 50? You can do that because Lambda is gonna spin up m- more multiverse side, and it's gonna run your app across all of these different containers.

Is this useful? Not for this purpose, but it is cool, right? But it's useful for something because it breaks the concept of, like, my machine because now you have this copy of your app out there ready to go, but it's still executed from your machine. But it is your app, but it's not your app. But you can... Like, you have, you know, unlimited compute or whatever. Everything costs money.

But you have all this compute power, and you can invoke it from your central app, whether that's on Vapor, my local machine, or on Heroku or Forge, whatever, right? So is this useful? Uh, I don't know. It's pretty cool. I can think of one place, one place where it's actually useful. Let's say, let's imagine you've got a bunch of tests, right? And maybe for the sake of a demo, you've got 50 tests.

And maybe for the sake of a demo, they all take three seconds. So now you've got, you've got 50 tests that all take three seconds because we're doing a demo and we wanna prove a point. And you don't wanna run 150 seconds worth of tests, right? What if you could say test parallel and use Sidecar as the runner to run your tests?

And instead of 20 processes, what if we did 50? So what if we ran those 50 tests in 50 different containers and they finished in three seconds, right? Did you see that? So what if we ran those tests in 50 different containers and it finished in three seconds? Pretty cool. And if you didn't see it, what if we ran it in 20?

So now we're only running 20 at a time, so you'll see 20 complete, and then in about three seconds later, you'll see 20 more complete, and then finally you'll see the final 10 complete. And we're, we're running those on Lambda. And you still get, you still get your, uh, you still get your feedback, right? So this is a little bit ugly. We can fix that.

You still get the feedback that example five test failed. It still turns red down here. If you look at example five test, you can see, oh, that was a classic mistake. So you, you still get your feedback, but you're running it somewhere else. And we've already looked at how you can add Chrome as a layer. So imagine if you had a bunch of tests that ran Dusk that required Chrome and you could run them on Lambda.

That's pretty cool, and I think that's actually useful. I don't know if this is the best example I could come up with. I think it's pretty useful. Um, I would be lying if I told you it had an edge case or two. It is just edge cases. Every edge case has its own edge case. Um, but it works, right? So what, what I did was I, I extended this ParaTest runner. I don't know anything about ParaTest, but what it does is it yields these promises.

So Sidecar will allow you to execute a function async and that is a guzzle promise. So we just yield them back. ParaTest handles, um, pooling up how many processes you wanna run. In our case, we ran 50 and then 20. And then as those promises settle, ParaTest handles, you know, filling them back up. So this is insane because it allows you to break free from whatever server you're on.

And there are specific workloads that I think will work under this paradigm. I don't know exactly what they are, but I know that there are some workloads that will be great for this. And you don't have to send the response back. You could put the response in the database. You could put the response on S3. You could, you know, just completely fail. You could have a queue worker that runs on Lambda, but your main app is on, let's say, Vapor, right? So before I fly out of my chair, that's what I wanted to show you in terms of code I think it's very cool.

I'll have links to all of this. This is what Sidecar enables. Um, Sidecar makes something that was hard easy, and now you get to do something easy and make something cool. That's my hope. Let's finish some slides before I explode. Um, thank goodness.

All right. Who's actually using this thing? Um, not the PHP part, Sidecar as, Sidecar as a library. Gitt is using it over at bannertize.com. He's built an entire image generation product on top of Sidecar. It's very cool. Um, you should go check it out at bannertize.com. Greg Schurman is, um, the OG of Inertia SSR rendering.

He, uh, beat me to it and has now run tens of millions of requests through it. So his app's on Vapor, and he does SSR in a Sidecar. Then Philo over here on the right, um, has a product that, um, distributes RubyGems as well as Composer packages, so look into it. It's unlock.sh. But to generate RubyGems, it turns out you need Ruby, so he's running Ruby in a Sidecar.

Very cool stuff. Exactly what I hoped to see when I built this. It's very fulfilling for me to see this kind of stuff. Okay. What's next? What's next after this talk is I take a nap for, like, two weeks. After that, I know that a lot of people, um, I know that a lot of people are concerned about Lambda, and rightly so, there's billing risk.

Um, also it feels pretty heavy, it feels pretty heavy to set up an AWS environment for, say, a side project or a hobby app, right? So a couple weeks ago, good guy Marcel was like, "Hey, I know that you built Sidecar to rely strictly on Lambda. Could you make it work for this other thing?" And I was like, "I don't know, man.

I don't think..." He asked if it was, it would work on Vercel, and I was like, "I really don't think I can make that happen." Well, I was wrong. I got it to work on Vercel. So what's great about Vercel, Vercel is a, uh, serverless platform that itself sits on top of Lambda, but is extremely focused on developer experience.

It's, it's very, very nice. They provide more predictable billing. They have a generous free plan, and then I think the next plan is, like, $20 a month or something. But it's v- it's much more predictable, right? I was under the impression that it wouldn't work because when I first evaluated it, I noticed they don't give you access to the underlying Lambda. And part of Sidecar's whole thing is we don't want you to have to worry about exposing these functions to the public internet and then, you know, securing it, whatever.

What Vercel does do is they give you the ability to write middleware that sits on the edge of their network. So you can, we have written a middleware where all of your Sidecar functions are secured by a side, by a middleware that Sidecar itself writes. So when you are, um, when you're deploying your function, you get to write it without any authentication, without any worries about parsing response, request

bodies, any of that, because our middleware sits in between the public internet and your function, and it has authentication built in. And it speaks the same language, obviously, that Sidecar PHP speaks, right? So you, as the developer, get the exact same invocation benefits in that you get to call basic function execute, and then under the hood, Sidecar notices this one's deployed on Vercel.

I need to add that secret auth token that I deployed myself. I need to add that secret auth token to the request and then get the response back, right? So you don't have to worry about that. One of the things, so what I thought was a drawback, this publicly required DNS, right? What I thought was a drawback turns out to enable a pretty cool feature in that we can, Sidecar can generate pre-signed invocation URLs.

So you can, um, get an invocation URL that's valid for a day, a month, a year, one hour. You can get a pre-signed invocation URL and send it to your front end so you don't have to make the hop from front end to executing your Sidecar back to Laravel, um, back to the front end. You can go from the front end directly to Vercel and back, right?

So you get to skip the Laravel hop. So if you have some kind of, like, image generation tool on the front end, you can pass a signed URL and just let those hit Vercel over and over and over, and so you, you avoid that penalty. So what I thought was, uh, what I thought was a drawback turns out to be a very cool feature that only Vercel as a driver is gonna have, because Lambda doesn't give you those public URLs for free.

You have to set up API gateway. So this is coming. I've got it working. Um, I will, uh, be probably releasing it in the next, you know, couple of weeks. It is going to be in the Sidecar package. So Sidecar's going to go from Sidecar Lambda to Lambda, Vercel, uh, Google Cloud Functions, Azure Functions, Cloudflare Workers.

I don't know. Never done anything with those, so who knows? But then you're gonna have the choice. Sidecar's becoming this, um, serverless agnostic interface to make your life easy, regardless of what platform you wanna go on. So that's coming. Follow, uh, probably follow along on Twitter to, to find out when that's gonna happen. That is all.

That's a lot, but that is all. Um, please, uh, go check out hammerstone.dev. That's where you'll find all of the Sidecar docs. That's also where, um, we, we make components for Laravel and Rails apps, and our first component is a query builder for your users. So if your users need to build queries, you can drop in our component.

We'll handle the front end, the back end, the database, the validation, the storing of the filter, everything. We'll handle it all. Um, I'm also working on a MySQL for developers course. So if you're an application developer using MySQL, this is gonna teach you the things you need to know without boring you with all the stuff that's irrelevant. You can find that link and all the links at aaronfrancis.com/laracon.

I will put this repo that I was just demoing, I will put this on there in the next hour or two, um, so keep an eye out for that. And then finally, I'm on Twitter always and forever. You can find me @AaronDFrancis over there. I would love to hang out. So with two and a half minutes to spare, I yield my time back to Ian.

Speaker 1

Thank you. Wow, amazing.

Aaron Francis

Yeah. It's a lot.

Speaker 1

Um, yeah, they're going crazy in the chat in there. I think minds have been blown, so.

Aaron Francis

Oh, that was the goal.

Speaker 1

Great job.

Aaron Francis

Okay. All right. Thanks y'all. Appreciate it.

Speaker 1

Now you can rest.

Aaron Francis

Thanks.

Speaker 1

Thanks. All right. Let's see what we got going here