Redis Caching

[00:00:00]
>> Brian Holt: So we're here on 06 caching. Any questions before we move on from caching to email that anyone had overnight? Grand insights or revelations that they could share with the class? Well, online Mate said using Redis to cache. It is kind of fun. I like Redis until you have a problem with Redis, and then you're going to learn to really hate Redis. But Redis is always doing what you told it to do, we'll put it that way.

[00:00:28]
Did you ever mention why we use unary operator on those article IDs? Uh, I mean, that's a good question. Uh, let's pull up the, see if I can find one. I do this quite a bit. Some people find this like to be too clever. I think plus ID is one of them, yeah, like here, like this one. So let's just take a look at this one. I'll close this for now. Um, ID here, when it comes in, you can see is a string, right?

[00:00:59]
This is because it's coming from a URL. The URL is always going to be string, it's going to be like something like, though 3 right there, it's going to be an ID like this and it's not going to be 3 as in like the number here. So you need to get this somehow from string 3 to number 3, right? Type coercion, you have to coerce it. Um, there's a 1 trillion ways to do that in JavaScript. Um, there's this unary plus.

[00:01:30]
I like this because having seen this so many times, it's very obvious to me exactly what this does, but I can see someone saying this is too clever. I don't like this, if you've never seen that before. Um. Uh, const. Temp ID equals, like, is it like new number or something like that, and you give it ID. And now this will be. No, that's a number, that's the number constructor. I forget. Uh, string to value maybe.

[00:02:04]
Anyway, there's another way of doing it that escapes me, and obviously I can't remember it and I can remember this quite easily, so that's why I do it. Um, now it's going to bother me. Uh, it's not is integer parse in ID. And now temp ID should be a number. OK, so that is one of the ways that you could do this and you might find that to be a bit more explicit, right? I would almost agree with you, other than I'm just lazy.

[00:02:39]
Anyway, that's why it's type coercion. Because if I take this off, it's going to say, hey, I expect you to get this to be in the same type before you give it to me. Um, this might work if this was just JavaScript and not TypeScript. I don't know. I've never tried that with Drizzle. You shouldn't, right? You should figure out the types yourself first. I don't know if this does type coercion or not.

[00:03:09]
Quick question, yeah, so, uh, regarding caching with, uh, with Redis, I mean, um. If we wanna go, um, that route, should we also consider like the implications of caching on the edge? I mean, does it have any benefit if it's just if Redis is only hosted in the East region in the US, but you're serving customers everywhere, everywhere. Do we get some benefit on caching that whatever um. God, I love giving this answer.

[00:03:40]
It depends. Uh, let me qualify that. Um, there's a great tweet from, I think it's from Lee Rob from, from Vercel about how caching at the edge ends up, so Vercel used to push everything to the edge, right? And like, we're going to do all of your functions at the edge and a bunch of stuff like that, and they found out over time that with the way that modern people architect their apps, I don't say modern like people just in general architect their apps, um, it usually doesn't benefit from being at the edge, because you have to like specifically architect your app to take advantage of things at the edge.

[00:04:16]
So for our app, for example, um, if we were really smart about um all of our API requests would only go to the edge, and that we were populating the edge with all of our, you know, pre-made queries, actually it's not even that, you wouldn't want to populate it with the intermediary results, you want to populate it with the end results. So rather than populate it with like the results of the database, you'd want to populate it with like the API response.

[00:04:41]
So then people would, then you'd be like cutting the round trip down from like, I have a mobile app, I'm in the middle of Chicago, and I make a request, it's going to go to the nearest edge cache, grab that and come back, and there's no extra round trip. You would get advantage from that, right? You would get lower uh speeds and all that kind of stuff. It'd be on the order of milliseconds, probably.

[00:05:06]
I don't say milliseconds, like maybe, 100 to like 600 max milliseconds. I'm just going to finger in the air, that's my guess. Um, the problem is like, let's say we put our database cache results in the edge cache. Now, what's actually going to happen is, I opened my app in Chicago, it's going to go to, um, my API server first because that's where the request is going. My API server is then going to call to the cache, which is at the edge, which might be close, might not be.

[00:05:34]
But it could be closer if it was in the same data center, which is like what Upstash would be now, the way that we have it. Um, so you're actually adding more time and space to your, uh, to the system here, so it actually would go slower. So you see what I'm saying? If you architect it correctly, absolutely, but almost nobody does. That's why we don't do it by default. It has to be like a special use case.

[00:05:57]
Now it's, that's what kind of my advice for like, how can I use like Cloudflare workers effectively or Vercel has a product like edge functions on Vercel or something like that. You need to like make sure that whatever you're doing is optimized for that specific use case. Is that too much or too little information? Somewhere in the middle? OK. There was like a moment in time where everyone's like, everything should be on the edge and everyone like got really hyped about the edge, right?