Astro Q&A

[00:00:00]
>> Does anybody have questions about Astro the framework? From this point forward, I'm talking about deployment.
>> Do you have an idea, you're starting your site, you're like, I'm not gonna do service side rendering, I'm gonna do a hybrid or what? Do you have a list or an idea when you're starting that to pick your starting point? You know, whether you want it to be server-side rendered or what.

[00:00:21]
I'm imagining building something and thinking like, I want that, and then getting into going, actually, that was the wrong choice. So what you consider at the start.
>> It depends on the framework that I'm using, right? But so because we're talking about Astro today, I'm gonna answer in the context of Astro.

[00:00:37]
I start static because if I need servers later, you only have to add this, This. You don't have to refactor anything else in your site, you're just telling it, okay, I'm gonna use some server stuff now, and it's like, okay, do whatever you want. [LAUGH] I'm not your dad, you can do whatever you want.

[00:01:01]
[LAUGH] And I think that's such a powerful way to think about it. So to answer that question more specifically, when I get a new project, what am typically looking at is, what are the deliverables that are considered like the value metrics for the client, for the customer, for my boss.

[00:01:21]
And what are the things that, why are we building this? What goal does it accomplish? And in order to accomplish that goal, what do we have to build? So if somebody comes to me and says, we are a fintech company and you need to build a real time stock ticker, and if you're not up to the second accurate we can get sued.

[00:01:41]
I'm making very different choices because that's a very specific set of requirements that has legal ramifications. If somebody tells me we've got an e commerce store, and our inventory updates, people, we sell a few things an hour and so because of that we need our inventory to be up to date.

[00:02:01]
I can make a client side request to validate whether or not something is in inventory, and the inventory itself will rebuild the site every time something's sold. And it'll be live within minutes, so I don't need to do anything else, right? I don't mind having that little client side request just to say, hey, is this sold out?

[00:02:19]
Because if so, disable this button. So I'm kind of looking at what are the requirements? What does the failure state look like? What is the consequences of something being a minute out of date or 5 minutes out of date? And typically speaking, the penalty for being 5 minutes out of date is nothing, nobody cares.

[00:02:38]
So I'm usually gonna reach for static by default, and then when I hit a case, add a newsletter form, then I can flip the switch and now I've got pre-rendering for just that newsletter form page. Or again, we have to add user accounts. Maybe I would turn on server rendering for my user account so that I can avoid a loading skeleton when I wanna bring in the user specific data, I wanna instead do that on the server side.

[00:03:01]
It all kind of depends on what we're doing. Who's impacted by it, who our competition is, right? If I'm building a site where I have to compete with Amazon, I'm probably making different choices than if I'm building a site that has to compete with the average local restaurant website.

[00:03:17]
And so it really kind of comes down to the specific requirements, the specific client and what the success criteria is. But, yeah, I mean as a general rule, static first, you can turn on hybrid whenever you want, and there's not really any consequences for doing that.
>> How would you approach authentication?

[00:03:38]
>> I would approach authentication using cookie based auth. I prefer cookie based auth in general, because you can do things like HTTP only cookies and you can make them same site only and you get a little more kind of security baked in from the browser that way. And if you're doing that, then you've got the ability through this hybrid rendering to check the cookies as part of the rendering flow.

[00:04:05]
Or if you want, you can also make the cookies not restricted from JavaScript and then you can use the cookies as part of your client side rendering to determine auth state as well. So that's how I approach it, and in Astro I don't think it would be much different than how I've approached it in any other framework.

[00:04:26]
If you need server rendering, If you've got it, if you don't, all the client side approaches work, you can use, also if you wanna add auth, like auth isn't your business. There are some great tools out there like clerk.io that will, my goodness, it's good. It just like cleans up that whole process or clerk.dev.

[00:04:42]
Let me actually load the website now that I'm saying that out loud. Clerk.dev. You just add it and it just works and you don't have to think about anything, it's what I always wanted other auth as a service platforms to be and you'd like to get you off the ground.

[00:05:01]
This is perfect if you need to custom build your auth, yeah, get into the cookie stuff. There's a lot of different ways that you can build that into both client side and server rendered workflows. And in either case, you can do that with Astro.
>> Is there anything special that has to be done with serverless functions?

[00:05:20]
For instance, with the form submission? Is it better to use a serverless function or go with a custom Astro server function.
>> So if you are using the server, like the hybrid mode in Astro, depending on where you deploy, it will be a serverless function or a server rendered function.

[00:05:49]
I guess the short answer is it doesn't matter, like whatever you wanna use is fine. If you would implement a custom serverless function as opposed to using the hybrid rendering mode in Astro. Also kind of functionally, you're gonna get the same outcome, you just choose which you prefer.

[00:06:12]
If I already had a bunch of serverless functions built that did all the form submissions and stuff. The advantage of porting those into an Astro server rendered page are just having the access right there to customize the template with whatever the results of the request are. But outside of that, there aren't a lot of additional huge benefits.

[00:06:31]
So if all you show is a static template that says like, thanks for signing up, please check your email to confirm. You can just show that page, you don't need to port that into Astro, you can keep the stuff you've already got, submit to your serverless function and then redirect to that page that says please check your email to confirm.

[00:06:50]
But under the hood, those Astro server rendered pages, if you deploy to Netlify or Vercel it's gonna be a serverless function, if you deploy to some of the other platforms it might be a long running Node server but it depends on the specific implementation. And as we'll see, when we get into deployment, there are a lot of options for that specific implementation.

[00:07:10]
And I haven't looked at what the underlying details of all of them are. But yeah, if like you're deploying on Netlify, the functional difference between deploying to your own serverless function and using the Astro, like server rendered page, there is no difference, they're both serverless functions. So at that point, it comes down to like, what do you want to build?

[00:07:33]
What does your team understand? Do you have a really good serverless workflow on your team, then you probably don't need to adopt a new one. If you don't have any serverless workflow, Astro is probably gonna be a little more understandable because it's closer to the rest of what you're building on the website.

[00:07:48]
It's always trade offs. You've just got to decide which one makes the most sense for your team and your particular use case.