Securing and deploying your Replit applications
1. Securing and deploying your Replit applications
So now we're gonna talk a bit about securing and deploying your Replit application, and security is really important, can't be an afterthought, so we have to check a few things before we launch. First: Authentication. Can we log in? Is our data protected properly? Second: Data storage. This kind of goes hand in hand with another point. Input validation. Are we processing user data, form data that users submit properly and storing it in our database? Is that secure and inaccessible to others? Secrets and variables. We don't have any API keys in this application, but it's always good to make sure if you do have API keys, that they're protected and not accessible from the front end. And lastly, performance. Is our app performant? Does it do what we want it to do? How are we gonna do this? We're gonna use our security scanner, we're going to do some manual testing, and we can also rely on Agent to take a first pass and do app testing as we saw when we were building out our application. Once we're ready to publish our app, we're gonna click the deploy or publish button. Now, an important point is that deploying is actually a snapshot of our app, so when we click deploy, the version that's visible to everybody else is not going to be visible if we make changes. So if we make changes to our application, we'll need to republish, or redeploy our application. Second, because there are multiple databases, we have a prod and a dev database, you can rest assured and know that making changes while you're developing won't reflect the front end state of your application. That does mean however, that if we click deploy, the database that goes out with our app will be a brand new database. And lastly, there are four types of deployments. We'll only be using Autoscale deployments for this tutorial, but I'll do a quick overview. So on Replit, we have static deployments, scheduled jobs, autoscale deployments, and reserve VMs. First up is static. So if you've ever built like a blog or a site that just displays texts, you've probably used a static deployment in some capacity, and Replit supports these. Now, what does it mean to be static? Just means that your browser is rendering a set of static files. So when I go to, you know, like your website on my browser, it's just going to render the files that exist there. It's not fetching data from a database, it's not calling a backend, it is simply a set of static files, whether that's a blog or any other website. And that means that site needs to be built before it's served. But Replit supports these static deployments, we won't be using them for this course. Second Autoscale, that's what we're using today. The reason it's called Autoscale is because it scales up or down from zero to infinity. And what that means is that if you have, you know, a hundred thousand people come, use your application, we're gonna spin up more servers. We can scale not only the number of servers, but also the amount of compute that each server has, so that's the difference in a nutshell, if you hear about horizontal and vertical auto-scaling. And the cool part is it also scales to zero, so if nobody visits your application, that's something I always worry about, it will scale to zero and you won't be charged. So it's really usage based, you can think about it like, Hey, as people are using my apps, we're gonna accrue usage and cost, but if people aren't using them, I won't. So we'll use Autoscale here. Now we also have reserved VM deployments, so if you're building something like an API, or you're building something that needs to be always on, you don't want that scale up or down functionality, reserved VMs are for you. They're always on, which means that they get a fixed set of resources. You pick the amount of compute and the amount of power you want this thing to have, and it also means that there's a fixed cost, so there’s some certainty there. Now, the flip side to that is that, you know, if you don't allocate enough resources, you could run into issues or if you allocate too much, you might be wasting money, so to speak. And last scheduled jobs, so if you wanna deploy more of a script or something that just runs every day at a certain time, you can absolutely do that on Replit, definitely check that out if you're somebody that's into scripting. I also wanna spend a little bit of time talking about the difference between Reserved VMs and Autoscales. I think about it like the difference between a Nest thermostat and a greenhouse, right? So a Nest thermostat, you wanna keep your apartment cool, you want to keep it at a certain temperature. And if I throw a party and I invite all my friends over, the apartment might start to warm up, right? But our thermostat is smart, so it's going to kick in the AC a little bit extra and cool the apartment down. The flip side to that is a greenhouse, I want my greenhouse to be at the same temperature all the time. There is no change in demand, no change in capacity. My plants, they need to thrive regardless. So my greenhouse is gonna be at the same temperature all the time. You can think about that as like the difference, and then mapping that onto the types of apps we build. You know if we're building a website or an application like we are in this course, Autoscale is a pretty good choice because it doesn't have to be on all the time. It can start up when people visit it and spin out. Now, if we were building a Slack bot that had to listen for any command that someone sent at any time and needed to be instantly available with an API that's always exposed, that might be when we want to use a Reserved VM, same thing is true of an API. In the next lesson, we'll jump into Replit and deploy our app using an Autoscale deployment.2. Let's practice!
Create Your Free Account
or
By continuing, you accept our Terms of Use, our Privacy Policy and that your data is stored in the USA.