Help us to make this transcription better! If you find an error, please
submit a PR with your corrections.
Luciano: A couple of weeks ago, AWS announced a new open source tool, CloudFront Hosting Toolkit, a new tool that promises to streamline the experience of deploying front-end applications to AWS while retaining full control of the underlying infrastructure. We are particularly excited about this announcement because it was recognized by some people in the community as the AWS response to something like Vercel.
We took CloudFront Hosting Toolkit for a spin and we are eager to tell you what we found out. In this episode, we'll discuss all about CloudFront and Toolkit, but we will also talk about modern front-ends and what's the expectation for a modern web application these days, brought from a user perspective, so visiting an application, but also from a developer perspective, so building that kind of application.
We will then discuss CloudFront Hosting Toolkit and see how it stands against this way of seeing modern front-ends. My name is Luciano and as always, I'm joined by Eoin for another episode of AWS Bites podcast. AWS Bites is brought to you by fourTheorem, an AWS consulting partner with tons of experience with AWS. If you need someone to help you with your ambitious AWS projects, check out fourTheorem.com.
You can contact us directly using the links in the show notes. So maybe we can start this episode by describing what a modern front-end application looks like because for many years, the golden standard of front-end application has been single page applications. And if you're not familiar with that definition, a single page application is effectively, you can imagine like a single HTML shell that is loaded and that shell only loads some JavaScript.
And inside that JavaScript, you have all the logic that your application needs. So that JavaScript will do client-side routing, which basically means that once the application is loaded, there is JavaScript logic that will look at the current URL and decide which components need to be mounted or unmounted to effectively refresh the page dynamically. It will also do client-side HTTP requests, something that has been called originally Ajax requests.
In the past, now it's more called fetch requests. But the idea is that once the application is loaded, it doesn't really have any dynamic data, something that you might keep, for instance, in a database. So whenever you need to load dynamic data, you need to do HTTP requests to a backend API, and that API will give you the dynamic data that then can be displayed in the page. So this basically means that you can also the entire front-end as a static website in something like CloudFront, for instance.
And the great part of all of this is that you don't need a backend at all. It's just static files. The browser can load them, and all the business logic needed for your front-end exists in those JavaScript files loaded by the browser. And this keeps things very simple, and it can be also very cost efficient, because once you host in S3 and CloudFront, that can scale to a massive amount, still with very little cost.
The main frameworks that emerged in the last decade that try to cover this kind of use cases are probably React, Vue, and Angular. There are so many others, and your framework comes out every week. But these are probably the three main ones that you will find in most projects. Now, there are some problems with this approach, this SPA's approach. One problem is that you have perceived loading times that can be very long.
And this is because until all the JavaScript is loaded in the page, you basically see an empty page. You see just a white screen, and it might look like the website is broken if it takes too long. And with some framework, it's actually very easy to forget to do some optimization, and you might end up with your JavaScript bundle that can be multiple megabytes. So really, lots of people might have this risk if they underestimate the effort and optimize the JavaScript code that you just deploy your application, you expect everything works perfectly, but then the user has a very bad experience.
We also mentioned that all dynamic data needs to be loaded externally. So that means that for all the kind of stuff, you need to build your own API, you need to deploy that API independently, and then your UI still needs to fetch all of that data, which might add to the delay before the user can see something useful. And that also creates some SEO problems because search engines will access your website, but then everything is happening after JavaScript is loaded, and not every search engine will actually wait for that amount of time or even try to run JavaScript.
So your indexing against search engines might be not necessarily the best because it's going to be very unpredictable what different engines will be able to see from your website. So to address all these problems in the last few years, this trend of building UIs has evolved a little bit, and it seems like we are going back to server-side rendering. So what we used to do in the times of PHP, Ruby or Rails, Django, basically you always have a server that's generating all the HTML, all the JavaScript, CSS for your websites, and you can generate all of that stuff dynamically. So whenever you need to read data from a database, your server will do that, compile the final page for the user, and then send all the assets to that.
So in the JavaScript space, there are some new tools that have emerged to try to satisfy this need, and probably one of the main ones is Next.js. And Next.js basically allows you to do everything still with JavaScript. So you will be able to use, for instance, if you like React, you will be able to use React components both on the client-side and the server-side. And Next.js gives you an experience, a development experience, where it's easy to perform actions on the server and pre-generate content, ship that content directly to the user, so it's going to be loaded very quickly. And then whenever you need to do something client-side, you can still use all the tools that you generally use with React and do client-side stuff. So it's kind of an hybrid, where in the same application, you can define all the backend logic and the frontend logic, and wherever you need to share components, Next.js makes it very easy. Now, Next.js is an open source project that is built and maintained by Vercel. And of course, Vercel has an interest in that project because they have a commercial offering where they make it very, very easy to host Next.js projects and more. And we think that their experience is actually very interesting. So maybe we should talk a little bit more about that, just to see how this tool announced by AWS compares to that kind of experience.
Eoin: The number one thing that you'd think about when you think about Vercel is probably the developer experience. And that involves how easy is it to get up and running and deploy your first application and keep it running. And the zero-config nature of Vercel is probably one of its best selling points because it's just very easy to connect your GitHub repo and have something deployed in a couple of minutes. It doesn't just limit itself to Next.js as well. It supports many other frameworks out of the box. And when you deploy it, you get the automated deployment from your repo, but you also get custom domains and your HTTPS certificates are going to be provisioned for you. And then it'll also scale on demand for you. So it's using other cloud providers under the hood, including AWS, and it's managing all of the scalability. But as well as just scaling within regions on cloud providers, it's also edge optimized. So it's doing edge up deployments as well to various CDNs and running a lot of those server actions and server component rendering on the edge for low latency. One of the really cool things is that if you're working with branches, it will give you preview deployments from your branches. So this means that right away, when you create a feature branch or a fixed branch, and you're working on something, you immediately get a preview URL that you can share with stakeholders. And one of the cool features of that is that your participants can annotate and make comments in line in your preview environment. So you can iterate really quickly with feedback. It also has a whole set of other integrations with other products like databases, you can get a Postgres database up and running pretty quickly. You get logs, they've been putting a lot of investment into AI support recently, CMS integration, and also other things like analytics and important security aspects as well. So there's a whole lot to love about Vercel, but they're not a sponsor of this episode. So while we like the developer experience and the feature set, it's still a software as a service, and you have a build or buy decision, and you have to evaluate the vendor on their own merits. If you want some more control autonomy around the infrastructure, you might want to deploy it to your own AWS account. And Vercel isn't something that will allow you to do that. So if you use Vercel, you don't have a lot of visibility into how your code is deployed and where it's going under the hood. And especially in the context of working with enterprise organizations, there are a lot of good reasons to avoid Vercel and to host front end applications yourself directly on AWS. So where do we start? If we want to host a front end on AWS, this is something that we've talked about a lot. It's a bit of a bugbear of ours, I suppose, just trying to find the right most optimal way to host static websites. We covered it in one of the very first episodes, episode three, how do you deploy a static website on AWS? And then back in episode 80, we were talking specifically about private static websites for enterprises. And there was always, it's always a trade off, no clear winner there. But now AWS has announced a new open source tool to help you tackle this problem. And this is the CloudFront hosting toolkit. So this certainly got a lot of people's attention, a lot of people talking because just you only have to mention Vercel competitor to get people's ears pricked up. And Luciano, you've been good enough to take a good look at this for us. So maybe your best place to give us an introduction, what is this CloudFront hosting toolkit and what can we do with it?
Luciano: Yeah, if you look at the announcement blog post, we will have a link in the show notes, they describe this tool as an open source command line interface to help you deploy fast and secure front ends in the cloud. So that kind of tells you what is the ambition of the tool. And the idea is to try to remove as much as possible the complexity of setting up everything you need to run your own front end on AWS. So you have a CLI, you run the CLI, it can, once you install it and run it against your particular repository where you are building your own front end, it can detect the framework of choice. For instance, Next.js is one of the supported ones.
And at that point, it can start to generate configuration for you, for instance, recognizing how do you build for this particular front end. It integrates with your repository. Right now, it supports GitHub. And basically what it does, the CLI will allow you to connect your GitHub with a build pipeline hosted in AWS. And also at that point, it can create all the necessary resources. So for instance, what do you need to host a front end? You would need an S3 bucket, you would need the CloudFront distribution, DNS record, TLS certificates, and more. It will create all of that stuff for you using infrastructure as code. So you don't really need to worry about basically coding all these things or figuring out where to find all of the examples to put all these things together. So that removes a lot of the friction of self-hosting your own front ends.
And everything that it does, as I said, is done through infrastructure as code, and it's made very accessible. It's still deploying through CloudFormation so you can see exactly what's being deployed. You have configuration files that gets generated for you. So you have also opportunities to still sticking with the same process that is given to you by the CLI. You can tweak and configure certain things to your liking. And then even if at the end of the day, you still want to change more, all the infrastructure is there, all the CloudFormation is there.
So you can take that and do further customization if you need to. And somewhere else, I think in the repository, they say something that to me represents the ambition of this project. And it reads us, gives you the convenience of a managed service while putting you in full control of the hosting infrastructure and deployment pipelines to make it your own. So that's a good marketing phrase to say, yes, we want to make it easy for you, but at the end of the day, this is your own infrastructure.
You'll have access to it and you'll be able to change everything you need. You can have your cake and eat it. Something like that, yes. But now we get to the more painful notes, I guess, because yeah, just to be real, we need to say that the current state is still a version 1.0 and it's still very, very early. Well, it was announced only a few weeks ago and it's fair to say that it's still very early days. So if our feedback is going to look a little bit harsh in some parts, at the same time, you have to think that this is an evolving project. It's only early stages, so it can only get better. So let's be fair in that sense. So if you look at the supported feature, right now it supports everything that you need to host an SPA that is statically generated.
And that is a very important note because it means that right now you cannot do any server side rendering. By default, it doesn't support any of that. So in a way, it's still a little bit behind the current trends. And if you use, for instance, Next.js, Next.js allows you to do websites that are only static generated with some tweaking in the configuration and just by not using certain specific features, you can do that. But you need to be aware that this is an existing limitation. If you want to use this tool with Next.js, you can only use the features that are supported with the pre-rendered static version of the website. The other feature is that, as we said, integrates really well with GitHub for version control. It's going to do for you atomic and immutable atomic deployments on CloudFront. We'll talk a little bit more about that later. It's a pretty cool implementation. So I think it's worth spending some time on how all of that works.
It's a CLI tool, so very easy to install with NPM, very easy to run it in any new project. It takes literally a few seconds just to get started. And also it does security and caching best practices. So all of these things are already incorporated in the generated infrastructure. So one less thing to worry about because if you were doing all of this yourself, maybe you get something working after a few hours of investigation and trainings, but then at the end of the day, you might still be unsure on whether that's something that can be production ready or not. This tool removes a little bit of that concern because it's already following tons of best practices that have been established in the AWS landscape for the last few years. And then it allows you to use custom domains. So if you want to host your own front end in your own custom domain, all of that process is streamlined. It's going to integrate with Route 53 and generate the necessary records, generate the TLS certificates for you, and make sure everything is integrated properly. If you don't have a custom domain, it's going to use a CloudFront domain for you. And finally, there is also a CDK level three construct for the toolkit that can be used as an alternative for the CLI. So that's maybe another option if you prefer to go more with something that is integrated with your own CDK rather than using the CLI. But I mentioned atomic and immutable instant deploys, which is a little bit of a mouthful. So do we want to try to explain what that really is and how it is implemented? Yeah, it's pretty neat.
Eoin: It uses CloudFront functions and CloudFront key value store, which you may not have come across. Let's go through these fundamental pieces of CloudFront first. So CloudFront functions are a little bit like CloudFlare workers, I guess, or other edge functions that you might've come across. They're like a much simpler version of Lambda because you also have Lambda at the edge, but Lambda at the edge is more like a fully fledged Lambda, although not quite. CloudFront functions are just more like lightweight JavaScript isolated contexts that are much more efficient, but also restricted in terms of what packages you can use and that sort of thing. So you could use CloudFront functions for writing lightweight functions for high-scale latency-sensitive CDN customizations like redirects or request response modification, URL rewrites, that sort of thing. And then you have CloudFront key value store. And this is a bit like a simplified version of DynamoDB that runs on the edge. And we've seen this kind of service from CloudFront, sorry, from CloudFlare as well. It's a global low latency key value store, and it allows you to read from CloudFront functions. And by having that state in your key value store, you can do more customizable logic at the edge functions. So when you have CloudFront key value store, you can make updates to function code and updates to the data associated with the function independently of each other. This kind of separation will simplify your functions code and makes it easy to update data without the need to deploy code changes.
Now, when it comes back to this CloudFront hosting toolkit, the basic idea is that every time you want to deploy a new version of your front end, rather than replacing the entire content of the S3 bucket hosting your assets or overwriting, you'll create a new unique deployment ID and host all the files for a deployment version in a dedicated prefix, like a subfolder. So let's say your first deployment ID is version one, then it'll create a prefix like slash version one.
And then within that, you'll have your index.html and your bundled JavaScript. And then with your second deployment, it would be version two under a slash version two prefix. So when a user will try to access a page by doing get index.html, this request goes to CloudFront first and the CloudFront function is the first bit of logic that gets evaluated. It can go to the CloudFront key value store to read the ID of the latest deployed version. And the function will then rewrite the URL to point to the specific assets in the S3 origin for that current version.
So if you're going, making a request to get slash about that would become get slash version two slash about dot html, for example. So then it'll load that specific asset from S3 or cache and return it to the user. And then when you have a new deployment, it'll just create a new prefix in S3 to host all those assets. When all is done, the new version ID is stored in that key value store. And the next time somebody is accessing the website, they'll get the latest version. Now, there's a few nice things about this approach. It's an immutable deployment approach, which means that every deployment is clean and new, and you can troubleshoot it in its own space. But you also retain older versions, which would make it easy to do rollbacks if you have to do that. There is little risk then that a user will receive assets from different versions, which is a common problem if you're just kind of overwriting into a single prefix in S3 or if they're accessing the website during an update. The other nice thing about this is that it could easily support preview environments. But we haven't seen anything showing that this is supported yet in CloudFront hosting toolkit, but it seems like this kind of architecture would certainly enable it. So maybe let's talk about your real world practice. You've taken it for a good test drive CloudFront hosting toolkit, and you've had some successes and some bumps in the road Luciano.
Luciano: So I'm going to try to describe the steps that I performed to try to test this tool and the different things that I found out. And hopefully that can give you an idea of how the tool works, the kind of developer experience you get and what gets created for you behind the scenes. So I started with a plain vanilla Next.js project. There is one CLI command that you can find in the Next.js documentation that basically uses a starter kit. And that starter kit is just a simple repo where you have a one Next.js page that points you to the documentation, to the about page and a few other simple things. So effectively it's like one page application, and it's like a static, statically renderable application because it doesn't really do any server side action or anything like that. So you run this first command, this command will do all the scaffolding for you. At that point, you can do npm install to install the dependencies. And if you want to run your frontend locally, just to see it running and play around with it, you can just say npm run dev, and that will give you locally an environment that you can use to tweak things around. Then at some point you are maybe happy with it and you want to try to deploy it using this CloudFront hosting toolkit. The first thing you need to do is install the toolkit itself. We said it's a CLI application, it's built with Node.js. So of course Node.js becomes a requirement at that point. But once you do that, you can easily install with NPX or just by doing an npm install global of the @aws/cloudfront-hosting-toolkit. And that will basically pull the latest version of the toolkit for you in your local development environment. Now the idea is that you need to use it against an existing repository. So this is why I created an Next.js project first. Once I did all of that and I was happy with the outcome, then you can start the tool. And the way you start the tool, you go with your CLI into the specific folder where you have your frontend application and you just run cloudfront-hosting-toolkit init That's literally the one command you need to run. And at that point, you have a guided process that will effectively ask you some questions to try to understand how to deploy this project for you. And the first question that it's going to ask is what is your repository? And of course, it's going to be able to auto detect it from the current working folder. If you have already initialized that as a Git repository and it's hosted on GitHub, it's going to automatically complete that particular question. But you can change it if you have different requirements, or maybe if you haven't set up the repo yet locally, you can still point it to a repo that you have set up already remotely on GitHub. The next step is going to ask you the name of the branch for deployments. It defaults to main, but I think you can use this if you want to change that to something else. Maybe you want to have a branch called deployment or deploy that you specifically, when you want to trigger a deploy, you can decide which branch is actually going to trigger the deployments that way. The next question is what is your framework of choice? And here, you have a few frameworks that are supported. AngularJS, Next.js, React, Vue.js. There is another one which is no build required, which basically means everything that is in the main folder is going to be deployed. And I think this is for static websites that don't require a build process. Maybe you just created a few simple HTML, CSS, and JavaScript files. You have them there and you just want to deploy them. The cool thing here is that it was able to automatically detect that I was using Next.js. So that option was already selected for me. I just needed to hit enter and proceed.
But of course, you can change that if maybe it's not able to detect your framework, or maybe you are actually using something else and it didn't really detect it correctly. The next step is asking you if you want to use a specific domain name, or if you want to use the default CloudFront domains. In this particular case, I didn't have a domain, so I just went with the CloudFront one, which maybe is a little bit of a simpler path. I'd be curious to try it again with a custom domain, just to see all the extra resources that it needs to create to support that. But I haven't done that yet. Once you've done all of this, this is basically the initial setup. So it's basically making sure that it understands your project and the configuration of your project. But at that point, it can start to generate things for you. And it's interesting to see that it generates a folder called the ./cloudFront-hosting-toolkit. And in this folder, it will generate three files for you. The first file is a code build job configuration. So it's basically the YAML file that contains all of that configuration. And this is awesome because that means that if you want to change anything in the pre-generated build step, because it's kind of assuming, okay, this is a Next.js project. I know how to build a Next.js project, but maybe you have additional requirements.
Maybe you want to do additional things that are not the standard way of building an Next.js website. You can easily change all the steps and customize it to your liking without having to change the toolkit or having to change anything else in the infrastructure as code. So it's just this one file allows you to change things. It also generates in this folder the CloudFront function that is used for URL rewriting, the one you described before, Eoin. And you can see all the JavaScript code that is being generated. So also there, you have an opportunity to change things around. Maybe you can, I don't know, add some extra logic to check if there is a query string parameter that says version equals something. Maybe you can actually enable that feature preview that way and by yourself, assuming that it's not supported yet. But basically, this is just to tell you that you have one file with all the logic that are visible. It's easy to change. And if you change it, this is what's going to get deployed for you. And then finally, there is a generic JSON file that contains all the options that were requested to you in the initial init phase. So if you change your mind, maybe you don't want to deploy from main anymore, you want to deploy from another branch, you can easily change that JSON file to get your base configuration updated. At that point, what you can do is that you can effectively deploy. At this point, you haven't deployed anything. You just generated these three configuration files, but those three configuration files are enough for you to start the deployment. So you can run another command called cloudfront-osting-toolkit deploy And what it's going to do is basically going to take all these three generated files as an input, and it's going to create all the necessary cloud formation templates to deploy everything else that we described before. So it's S3 buckets, CloudFront distributions, the CloudFront function, the CloudFront key-value storage, and there is a lot more. You can check out, there is a diagram in the announcement page and in the repository showing exactly all the resources that get created and how they are related to each other. And this is also going to do a few other things. So initially it's going to bootstrap your AWS account, which I think it means it's going to create a dedicated street bucket for the deployments. It's going to create the repository, the CodeStar integration. And actually the CodeStar integration is really interesting because what it does the first time you need to manually confirm that connection between your GitHub account and AWS. And it's something that you have to do in a browser where you are effectively authenticated on both sides. So what it's going to do is going to generate the request for you. Then it's going to redirect you to the AWS console and in the AWS console, you can click to basically connect your own GitHub account. To be honest, this was amazing to see on one side, but on the other side, in my case, it was a little bit annoying because I use, when I access to AWS, I generally use anonymous sessions because I might have sessions for different AWS accounts. So when I was trying to connect to GitHub, it didn't have my own credentials. And it took me a while to connect into that anonymous environment with GitHub, asking you MFA and confirmation by email, just because they see that it's a different session that you haven't used before. But eventually I managed to get it working. And then all the local setup was done. The remote setup was done on AWS. And you just need to click enter to say that you successfully connected GitHub with AWS. And then at that point it's going to proceed with the cloud formation deployment. Now, at this point, I had a problem because once everything is deployed for you, it's also going to try to run the code build for the first time and try to do a first deployment of your front-end application. Like if you were doing your first commit, basically. And that one actually failed because there is an issue with the version of Next.js that I'm using. I'm using the very latest version and that latest version doesn't support Next export, which is what the default build pipeline is using to create the static version of the website. Now, this is something you can easily fix. You just need to create a Next config.js file, do the modern way of saying that you want to produce a static website, which is just like one option, I think it's export static or something like that. Commit that into your own repository. And of course you also need to update the code build pipeline, not to use Next export anymore, because at that point, when you do Next build, it's already creating the final version of your website for deployment. And this is basically where I stopped, but I could see that everything was generated correctly. I could see that if I was doing another commit, the build pipeline would trigger automatically and do all of the deployment we described. So I think even though there are some steps that might be a little bit annoying, overall, that experience was quite pleasant. I don't know what you think so far, and if you have any final consideration on your end. You know, we talked about this kind of stuff when we were talking about CDK in previous episodes.
Eoin: I personally have a bias against code, sorry, against tools that generate code that introduce another level of abstraction, mainly because it's just another, you have to understand kind of what's going on under the hood, and then also what's happening in this abstraction layer. And if, especially with a tool like this that might not be perfectly stable yet, you might wonder, will it suddenly generate a completely different set of infrastructure that might make it difficult to do seamless upgrades? And I'd much prefer to spend the time to provision all of the infrastructure myself and really understand it more often than not. But I can certainly see the value in it, because I have been in a case recently where I've been trying to deploy a static version, like a SPA version of an Next.js app, with only client-side rendering, with static export to CloudFront, and it's definitely not a trivial thing. So I think there's, I definitely commend the effort here to get all of this stuff working. It's not an easy thing to do, and it does provide like a good blueprint for people to get started with it. So while my bias isn't necessarily drawn to a tool like this, I think it is pretty promising. I think there's some really good ideas in here, like the immutable deployments, and it seems to be simple enough to use. There's obviously some rough edges that need to be polished. The fact that it doesn't support server-side rendering may be a bit of a blocker for a lot of people at this point. Let's hope we'll see a bit of evolution there. I mean, I kind of think back to one of the previous releases from AWS we covered, which was the integration testing toolkit, the IITK, and it was also a similar kind of review, like a lot of promising stuff, but needs more work. And when I went back to look at that recently, because I did use it in a side project, it doesn't seem to have actually evolved that much. So I know, we know that AWS likes to release things early and get feedback from the user base, but let's hope that this one sees the love and attention that we need. What's your take?
Luciano: Yeah, I absolutely agree with everything you said. A few things that I can mention in addition to that is that I was able to fix an initial issue that I had with the CLI not installing properly. So I just submitted a PR and I was impressed to see how quickly I got a review. The PR was properly commented and released and very quickly all happened in the span of an hour. And the problem was fixed immediately. The maintainer was extremely welcoming. So that's definitely a good thing to see. And I think that creates a big opportunity for everyone that wants to contribute to this kind of project to be able to do that. It seems really like a very welcoming environment for people to contribute. So maybe if the tool doesn't have all the things you need and you are willing to invest a little bit on it, definitely think about contributing and giving back and working with the maintainer to get to the point where this tool is actually going to be helpful for you and for other people. So that's absolutely a plus one for the tool and the current maintaining team. Another thing that I think is worth mentioning is that there is another walkthrough by our friend Sandro Volpicella. We will have the link in the show notes. He has also done a similar kind of test ride of the tool and wrote a blog post detailing all the things that he found out. I think there is even a few more things that he explains. Like for instance, there is a step function that is used for updating the versions and he also goes through on how that works and why it needs to be there and maybe how it can be improved. So if you want to do an additional deep dive on the technology and get another perspective on the tool, definitely recommend to read that blog post. And then finally, I think it's worth mentioning a few potential alternatives because we are effectively working with a customer that might need this kind of stuff. So we are doing lots of research on what are the possible options there. And it's also a topic we are really passionate about. As you can see, we keep talking about this. So other things that we think are going to be suitable, for instance, you can more or less relatively easy, you should be able to create a container and then run that container with a Next.js application with full server-side rendering either on AppRunner or Fargate. But then of course, you have something that is running 24/7. So maybe not necessarily what you want to do if you want a more serverless approach. And in that front, there is another project that seems very promising that is called OpenNext, which we haven't tried yet, but in the docs, it says that it also supports server-side rendering on Lambda. So that seems maybe a closer re-implementation of what Vercel does for you, but that you can deploy on your own on AWS. It's definitely worth a look. And hopefully we will have time to try it out and maybe give you an overview of what that looks like. Similarly, there is another project called Coolify, which is a little bit more generic. It's probably a modern take on Heroku. So it allows you to host your own PaaS and it does that in a serverless way. But as such, you should be able to host a container that you can run with everything you need to run an Next.js project. So another thing that we really like to try, we haven't had the time yet, but if we do try it, we'll let you know our findings. And finally, there is Amplify, which always gets mentioned every time that people talk about Vercel versus AWS. I don't personally have an opinion on that one because I haven't really used Amplify much. So, oh, and I'll leave it to you to mention something about Amplify if you want. I've looked at, you know, I don't have a huge amount of experience either.
Eoin: I've used the Amplify CLI and the client SDK a lot. The managed side of Amplify is a whole other set of features. Like they allow you to easily provision storage and hosting and all sorts of other stuff. I know that they've introduced a new generation two, and I'd love to do an episode on that in the future. But from what I can see with the new generation two Amplify, it's also solving the same sort of problem in a much more managed service kind of way. So it seems a little bit more like an AWS managed Vercel alternative. And I think from what I've seen so far, a lot of work has gone into that. I haven't tried it, so I don't know exactly what the experience is like. Let us know if you have, because I'd love to know. I have seen some online discussion. Actually Yan Cui was mentioning the release of the CloudFront hosting toolkit. And one of the principal SAs at AWS was answering the question, well, why did you actually create this tool when you already have Amplify? And it seems like they explained pretty clearly that strategically they're basically saying, if you want to manage service, use Amplify. But if you want a little bit more control over the infrastructure and you're really just looking for something to generate that blueprint infrastructure, then that's what the CloudFront hosting toolkit is aimed to solve for you. So at least that gives you the right kind of context for deciding which approach you might like to take. Awesome. And I think that covers everything we wanted to cover for today.
Luciano: Let us know if you had a chance to try the tool yourself and what is your opinion, or if you've used any other alternative tool, what do you use and whether you like it or not. I think this is still a topic that deserves a lot of attention. I don't think there is a final solution that is going to fit all the use cases. So I'm really good to see... Well, unless you use PHP and become a millionaire that way. But yeah, let us know what are you using today. And I'm curious to see how this space is going to evolve in the next few years, because I think there is still a lot of innovation that needs to happen in this space to fit all the different use cases that people have today. So thank you very much, and we'll see you in the next episode.