00:00:03.690 --> 00:00:06.517 About why the code is there, the purpose it serves and then
00:00:06.517 --> 00:00:08.967 actually physically walking through the code to see
00:00:08.967 --> 00:00:09.580 mechanically.
00:00:10.530 --> 00:00:12.380 What it's you know how it actually does it.
00:00:13.640 --> 00:00:17.820 So without further ado, let me share my screen.
00:00:18.840 --> 00:00:20.990 And we will do that thing.
00:00:22.850 --> 00:00:26.711 So for anybody who is there, anybody that isn't familiar
00:00:26.711 --> 00:00:27.050 with?
00:00:28.240 --> 00:00:33.842 I guess the the general concept of server side caching and and
00:00:33.842 --> 00:00:35.710 browser side caching.
00:00:36.930 --> 00:00:41.470 And no shame if you're not. It's it's kind of a weird one, so.
00:00:42.730 --> 00:00:44.770 OK cool so.
00:00:45.600 --> 00:00:49.470 Uh, that was very strange. Seems just closed itself for a second.
00:00:51.370 --> 00:00:52.220 So basically.
00:00:53.440 --> 00:00:54.440 Conceptually.
00:00:55.310 --> 00:00:59.973 Uh server side caching? Uh, well, I guess starting at kind
00:00:59.973 --> 00:01:04.794 of the top level caching in general is basically a mechanism
00:01:04.794 --> 00:01:09.220 for improving response time for any given resource. So.
00:01:10.860 --> 00:01:14.681 Effectively what we can do is we can say we know that this thing
00:01:14.681 --> 00:01:18.149 is not gonna change anytime soon. So we can basically save
00:01:18.149 --> 00:01:20.030 an easily accessible copy of it.
00:01:21.430 --> 00:01:25.485 So that instead of having to recalculate it or re retrieve
00:01:25.485 --> 00:01:29.815 that item or that result, we can just give you what we already
00:01:29.815 --> 00:01:31.740 know is the result for that.
00:01:34.000 --> 00:01:37.627 Uh, so that that's kind of the the the top level of caching
00:01:37.627 --> 00:01:40.710 server side caching specifically as it relates to?
00:01:40.790 --> 00:01:41.260 You.
00:01:42.540 --> 00:01:47.359 Uh websites is effectively it's kind of a layer between the API
00:01:47.359 --> 00:01:51.726 and the front end. That's basically you could think of it
00:01:51.726 --> 00:01:56.243 as it sort of intercepts a request and says, have I already
00:01:56.243 --> 00:02:00.987 figured out the result of this response and has the result for
00:02:00.987 --> 00:02:05.730 this type for this exact request changed since the last time I
00:02:05.730 --> 00:02:06.860 figured it out.
00:02:07.620 --> 00:02:10.264 If I already know what this is and it hasn't changed, then I'm
00:02:10.264 --> 00:02:12.320 just going to give you back what I already knew.
00:02:13.150 --> 00:02:16.477 Umm. And so that's really good. For example for like really
00:02:16.477 --> 00:02:20.137 large database queries. If we're reading a ton of data out of the
00:02:20.137 --> 00:02:23.520 database, it could take a not a ton of time, but enough time
00:02:23.520 --> 00:02:26.792 that you would notice some slowdown in Page load and stuff
00:02:26.792 --> 00:02:30.174 like that. Half a second for a ton of data or something like
00:02:30.174 --> 00:02:31.450 that, and that adds up.
00:02:32.620 --> 00:02:36.151 And so if it takes half a second to query all that data out of
00:02:36.151 --> 00:02:39.627 the database and and you know line it up into DTO to serve it
00:02:39.627 --> 00:02:42.654 out, but it takes 10 milliseconds to read it out of a
00:02:42.654 --> 00:02:45.961 cache and give it back, then obviously you want to save it
00:02:45.961 --> 00:02:49.381 from the cache where you can. And so that's what server side
00:02:49.381 --> 00:02:50.670 caching pretty much is.
00:02:51.610 --> 00:02:54.956 Is. It's basically the first time we need to calculate a
00:02:54.956 --> 00:02:58.009 result. We also store that result and then any time
00:02:58.009 --> 00:03:01.591 somebody needs that same thing again, we just give them back
00:03:01.591 --> 00:03:04.879 that same thing and it's a mechanism that increases the
00:03:04.879 --> 00:03:08.636 response time of the website. Or I guess I should say increases
00:03:08.636 --> 00:03:11.924 responsiveness, decreases response time on the site and
00:03:11.924 --> 00:03:15.329 reduces the amount of resources needed on the server side
00:03:15.329 --> 00:03:16.210 because we can.
00:03:16.690 --> 00:03:19.632 We can basically for go calculating things we've already
00:03:19.632 --> 00:03:20.200 calculated.
00:03:22.260 --> 00:03:25.850 The the kind of next layer of this, uh, which, like Brendan
00:03:25.850 --> 00:03:29.261 Flaherty said, is browser caching and browser caching is
00:03:29.261 --> 00:03:29.620 funky.
00:03:30.300 --> 00:03:33.962 Umm. So effectively what your browser, your browser can decide
00:03:33.962 --> 00:03:37.449 that certain resources can or should be cached. And I think
00:03:37.449 --> 00:03:41.053 this is super important. Any back end is listening. This is a
00:03:41.053 --> 00:03:44.656 really important thing because we have some amount of control
00:03:44.656 --> 00:03:48.260 over this based on how we build our API and something that we
00:03:48.260 --> 00:03:49.190 should all know.
00:03:49.680 --> 00:03:53.876 Umm, but your browser might see a get request to a path and say
00:03:53.876 --> 00:03:57.220 ohh you just ask for that. Here's the same result.
00:03:58.480 --> 00:04:01.380 Even if you would expect that the result would be different.
00:04:03.780 --> 00:04:06.835 At, at least in the way that you've written your code, you
00:04:06.835 --> 00:04:09.527 would expect that each individual get request might
00:04:09.527 --> 00:04:12.893 return something different, but because it's a get request, your
00:04:12.893 --> 00:04:16.000 browser by nature is going to cache the same get request to
00:04:16.000 --> 00:04:19.365 the same server, and oftentimes it caches it pretty aggressively
00:04:19.365 --> 00:04:21.540 to the point that it's very difficult to.
00:04:22.290 --> 00:04:25.717 Circumvent. Uh, without like manually doing, you know, like
00:04:25.717 --> 00:04:29.373 we've all seen empty cache and hard reload or like the disabled
00:04:29.373 --> 00:04:31.830 cache tick box in the dev tools, etcetera.
00:04:33.410 --> 00:04:40.623 And so part of the role we play in browser side caching is these
00:04:40.623 --> 00:04:43.730 30 fours. So what we can do.
00:04:44.950 --> 00:04:50.741 Is we can, whenever we serve a response from our API, we can
00:04:50.741 --> 00:04:56.628 attach a header to our response that tells the requester this
00:04:56.628 --> 00:05:00.900 resource has was last modified at this time.
00:05:01.920 --> 00:05:04.620 And then for future requests for the same information.
00:05:05.600 --> 00:05:10.558 The browser can say hey, give me this item unless it was modified
00:05:10.558 --> 00:05:11.760 after this time.
00:05:12.570 --> 00:05:17.103 And what we can do on the server side is we can we can check did
00:05:17.103 --> 00:05:17.800 we modify.
00:05:18.620 --> 00:05:21.979 The the result of this query since that time and if not, we
00:05:21.979 --> 00:05:25.395 don't respond with the entire payload. We don't respond with
00:05:25.395 --> 00:05:28.866 anything we give. We just return a 304 not modified. And what
00:05:28.866 --> 00:05:31.330 that does is that would tell the front end.
00:05:32.270 --> 00:05:35.522 That it it's basically that it's local cache at the browser's
00:05:35.522 --> 00:05:37.620 cache is valid and that it can be used.
00:05:38.200 --> 00:05:42.887 Umm. And so that's that is what 30 fours are is it's effectively
00:05:42.887 --> 00:05:47.358 the browser says, hey, I've got a I've got a cache result for
00:05:47.358 --> 00:05:51.757 this for this request is this is my cache still valid and we
00:05:51.757 --> 00:05:56.372 could return a 304 in which case the browser would just use its
00:05:56.372 --> 00:06:00.843 cache and the nice thing about returning A3 or 4 is that it's
00:06:00.843 --> 00:06:05.242 extremely fast. It is a 0 byte response it's just a response
00:06:05.242 --> 00:06:07.550 status code with no body at all.
00:06:08.460 --> 00:06:12.036 So there's there's no serialization cost, there's no
00:06:12.036 --> 00:06:15.882 deserialization cost on the browser, there's no download
00:06:15.882 --> 00:06:19.323 time to receive the result. I mean, it's basically
00:06:19.323 --> 00:06:21.820 instantaneous, ping notwithstanding.
00:06:23.210 --> 00:06:27.442 And so it's a nice way for us to still maintain some level of
00:06:27.442 --> 00:06:31.401 control over the validity of browser side cache while not
00:06:31.401 --> 00:06:34.883 losing too much of the performance of just blanket
00:06:34.883 --> 00:06:36.180 caching everything.
00:06:38.270 --> 00:06:41.424 Obviously, all this three or four stuff relies on the browser
00:06:41.424 --> 00:06:44.477 actually tearing that we're giving it back. A last modified
00:06:44.477 --> 00:06:46.360 header and it implementing 30 fours.
00:06:47.140 --> 00:06:53.920 Uh, but ultimately the 304 stuff in our code is kind of a.
00:06:55.380 --> 00:06:58.512 A side note to the more important part of it, which is
00:06:58.512 --> 00:07:02.100 server side caching, and that's what we're going to talk about
00:07:02.100 --> 00:07:02.670 today, so.
00:07:03.620 --> 00:07:06.902 All of Seth's uh, I guess before I go on, does anybody have any
00:07:06.902 --> 00:07:10.184 questions or or anything about that and I'll go through. Like I
00:07:10.184 --> 00:07:13.415 mentioned the stuff that we can do as API developers to have a
00:07:13.415 --> 00:07:15.620 little bit of control over the cache, but.
00:07:16.320 --> 00:07:19.592 Uh. Outside of that piece of it, that will cover in a bit. Does
00:07:19.592 --> 00:07:22.761 anybody have any other questions or or anything about caching
00:07:22.761 --> 00:07:23.630 before I move on?
00:07:30.640 --> 00:07:35.873 I will take that as a no. OK. So this is gonna be a little bit
00:07:35.873 --> 00:07:36.870 back, Wendy.
00:07:37.050 --> 00:07:41.320 Umm, but I I will encourage all the front Enders to.
00:07:42.420 --> 00:07:43.390 To try and.
00:07:44.640 --> 00:07:48.660 I mean it's it's not complicated stuff, so I think.
00:07:49.720 --> 00:07:53.605 I think you guys will be fine, but just bear in mind, you know
00:07:53.605 --> 00:07:57.428 it is this is in C# side, so it's a little bit, it's a little
00:07:57.428 --> 00:07:58.230 bit weird so.
00:07:59.670 --> 00:08:04.885 Uh to kick it off. So we have, I guess I'll start and show what
00:08:04.885 --> 00:08:08.960 the usage of this looks like, but we've got some.
00:08:09.070 --> 00:08:12.820 Uh, some functions that allow us to return cached results and
00:08:12.820 --> 00:08:16.329 kind of makes it easy to use them. And what that actually
00:08:16.329 --> 00:08:17.660 looks like, I'll just.
00:08:18.570 --> 00:08:19.670 No, not that one, this one.
00:08:20.930 --> 00:08:25.127 Find an easy one in here, like uh, OHS. Just do accounts that
00:08:25.127 --> 00:08:28.714 account, that's good enough and we'll go look at the
00:08:28.714 --> 00:08:31.760 implementation get. So this is kind of what?
00:08:33.250 --> 00:08:36.444 That's not a good one. I'll find a better one. Hold on. Get
00:08:36.444 --> 00:08:36.870 singles.
00:08:40.890 --> 00:08:43.640 Alright, hold on. I want to find one that that uh.
00:08:45.380 --> 00:08:48.980 Kind of displays a little bit better what's going on. I guess
00:08:48.980 --> 00:08:52.696 I could just have 12 in one of these, but you see we have these
00:08:52.696 --> 00:08:56.413 super long method names in the service layer used last modified
00:08:56.413 --> 00:08:59.955 for 304 or create and return cached result. And then there's
00:08:59.955 --> 00:09:00.710 some kind of.
00:09:01.460 --> 00:09:05.736 Extensions like by name, single by key, single by ID, single UM
00:09:05.736 --> 00:09:09.010 and then there was another one up here that was.
00:09:10.170 --> 00:09:13.849 Create return cached result set, so that's multiple items in the
00:09:13.849 --> 00:09:15.490 response et cetera et cetera.
00:09:17.380 --> 00:09:20.407 But all of these, if we have 12 into any one of these, you'll
00:09:20.407 --> 00:09:23.289 see that they're all kind of doing the same thing. They're
00:09:23.289 --> 00:09:24.070 all calling the.
00:09:25.210 --> 00:09:28.510 Like the the lowest level function which is used last
00:09:28.510 --> 00:09:32.298 modified for three or four or create and return cache result.
00:09:32.298 --> 00:09:35.965 So that is the this function that will have 12 and two here
00:09:35.965 --> 00:09:39.753 in just a moment is the actual implementation. So you can see
00:09:39.753 --> 00:09:43.603 that you pass in your request which would be like your DTO and
00:09:43.603 --> 00:09:47.453 then you have two functions that you pass into this. The first
00:09:47.453 --> 00:09:51.058 function is we call it the last mod function and what this
00:09:51.058 --> 00:09:54.724 actually does is it tells the caching code how to determine
00:09:54.724 --> 00:09:55.580 the last time.
00:09:55.680 --> 00:09:59.600 The result would have been modified and so, for example, in
00:09:59.600 --> 00:10:00.580 this case it's.
00:10:02.580 --> 00:10:07.017 We're looking at the by name single, so this would just find
00:10:07.017 --> 00:10:11.382 the the object by its name in the database and then get its
00:10:11.382 --> 00:10:15.674 last modified or the updated date. Basically of the record
00:10:15.674 --> 00:10:19.675 and the database. That's the last time that record was
00:10:19.675 --> 00:10:20.330 modified.
00:10:20.900 --> 00:10:25.083 Umm, so this allows us to basically calculate. Was this
00:10:25.083 --> 00:10:29.938 modified since the last time it was cached and if it was then we
00:10:29.938 --> 00:10:33.150 would clear the cache and server response.
00:10:34.480 --> 00:10:35.800 The next piece is.
00:10:36.980 --> 00:10:40.163 Get by name. So this this second function that we pass in is
00:10:40.163 --> 00:10:43.554 actually the one that calculates the result and we call that one
00:10:43.554 --> 00:10:44.650 the factory function.
00:10:46.720 --> 00:10:48.680 The rest of these are sort of.
00:10:49.450 --> 00:10:52.853 Extra parameters that we passed into that that are well named
00:10:52.853 --> 00:10:56.036 enough to kind of Intuit, but we'll go through them as we
00:10:56.036 --> 00:10:59.220 start walking through the code. So like I said, all these
00:10:59.220 --> 00:11:02.458 different extensions, they're just calling the root method
00:11:02.458 --> 00:11:05.751 that does something. So the result set 1 just does get page
00:11:05.751 --> 00:11:09.154 results, get less modified, et cetera. They're all doing same
00:11:09.154 --> 00:11:11.240 thing. And what that does is up here.
00:11:12.640 --> 00:11:17.744 And so the very first thing that happens in here is we calculate
00:11:17.744 --> 00:11:22.533 the last time the result or result set or whatever it is was
00:11:22.533 --> 00:11:23.240 modified.
00:11:23.990 --> 00:11:24.720 Uh.
00:11:25.780 --> 00:11:29.772 And then we go in here and we say if the current kind, if the
00:11:29.772 --> 00:11:33.056 API is storefront, so specifically what the reason
00:11:33.056 --> 00:11:36.854 we're checking that is that caching is by default disabled
00:11:36.854 --> 00:11:40.911 outside, not even by default. It's hard coded to be completely
00:11:40.911 --> 00:11:43.100 disabled for server side caching.
00:11:44.430 --> 00:11:46.360 Outside of the.
00:11:46.530 --> 00:11:48.270 Uh. Storefront.
00:11:49.710 --> 00:11:50.320 Umm.
00:11:52.110 --> 00:11:56.196 So, or at least a three or fours are. So if the current API kind
00:11:56.196 --> 00:12:00.220 is the storefront and we're not explicitly requesting no cache.
00:12:00.860 --> 00:12:05.130 And the given request has a valid entry in the cache.
00:12:06.050 --> 00:12:09.725 Which is determined based on the last modified. If all of this is
00:12:09.725 --> 00:12:13.065 true, then we can return a 304 not modified. So this is the
00:12:13.065 --> 00:12:16.517 actual 304 response that we're giving back. That's what I was
00:12:16.517 --> 00:12:19.746 talking about earlier. This rarely happens, especially on
00:12:19.746 --> 00:12:23.198 locals, because we're typically developing with like disabled
00:12:23.198 --> 00:12:26.762 cache enabled in the browser or something, so the browser's not
00:12:26.762 --> 00:12:29.991 even sending the if last modified header that relies that
00:12:29.991 --> 00:12:33.443 this all relies on. So we can kind of step past this and just
00:12:33.443 --> 00:12:35.670 say, yeah, three or four is we get the.
00:12:35.750 --> 00:12:39.116 Get the concept, but the majority of what we're
00:12:39.116 --> 00:12:43.044 interfacing with on our day-to-day is gonna be just the
00:12:43.044 --> 00:12:47.462 regular server side caching and read. It's not 30 fours, so we
00:12:47.462 --> 00:12:51.390 set past this. We basically set up a little bit of the.
00:12:52.590 --> 00:12:56.323 Header stuff, which is fine, cool. And then we go into create
00:12:56.323 --> 00:13:00.238 and return cache result. So this is the actual raw result of our
00:13:00.238 --> 00:13:04.212 calculation. You see we actually pass in the factory function the
00:13:04.212 --> 00:13:07.886 original request et cetera. So we can jump into this guy and
00:13:07.886 --> 00:13:09.090 see what's going on.
00:13:09.900 --> 00:13:10.540 Umm.
00:13:12.840 --> 00:13:16.902 Uh, so then we're saying if we have requested a no cache or we
00:13:16.902 --> 00:13:20.706 are not in the storefront. In other words, if this request
00:13:20.706 --> 00:13:22.060 should not be cached?
00:13:22.690 --> 00:13:26.992 Then what we do is we calculate the response just by running the
00:13:26.992 --> 00:13:31.096 factory function, which this actually would calculate our our
00:13:31.096 --> 00:13:34.340 end result get by ID get by name whatever it is.
00:13:35.000 --> 00:13:41.910 Umm. And then uh, we serialize it and we compress it here.
00:13:42.820 --> 00:13:45.500 And that's what we returned is a compressed result.
00:13:47.540 --> 00:13:51.220 And then otherwise, if we are going to cache it.
00:13:52.040 --> 00:13:55.483 Uh, and then we generate a cache key based on the request, so
00:13:55.483 --> 00:13:58.703 that's if you've ever looked in like you're another Redis
00:13:58.703 --> 00:14:02.035 desktop manager. If you don't have this tool, say fantastic
00:14:02.035 --> 00:14:04.090 tool for troubleshooting stuff with.
00:14:04.760 --> 00:14:07.773 Caching in your local or even on QA or production sites or
00:14:07.773 --> 00:14:10.530 anything like that. This can be a really useful tool.
00:14:11.100 --> 00:14:13.910 Umm, but we'll go look at my develop local.
00:14:15.280 --> 00:14:18.679 Never mind, I don't have anything. Let me just let me
00:14:18.679 --> 00:14:22.518 just actually do something real fast on my help. Local. It's
00:14:22.518 --> 00:14:22.770 off.
00:14:24.300 --> 00:14:25.210 UH-1 moment.
00:14:31.530 --> 00:14:35.922 Uh, it's been spec up, but the cache keys that it generates are
00:14:35.922 --> 00:14:40.108 going to be colon separated values that determine where they
00:14:40.108 --> 00:14:41.000 land in here.
00:14:41.760 --> 00:14:45.800 And so I guess I can look at these and you can see SEF cache,
00:14:45.800 --> 00:14:49.515 colon dev, local dot clear, client com colon, earn colon
00:14:49.515 --> 00:14:51.340 ioth session colon and then.
00:14:52.110 --> 00:14:55.366 A session, a session identifier and you can see that the another
00:14:55.366 --> 00:14:58.623 reason desktop manager splits on the colons and lays it out like
00:14:58.623 --> 00:15:01.679 folders. So it's a lot easier to drill down into what you're
00:15:01.679 --> 00:15:02.280 looking for.
00:15:03.820 --> 00:15:07.530 But that is those this function here. If we go back in the code.
00:15:08.830 --> 00:15:12.940 Seth Cache response attribute dot build key this is what's
00:15:12.940 --> 00:15:17.328 actually generating that cache key and it does that by looking
00:15:17.328 --> 00:15:19.070 at the original requests.
00:15:20.480 --> 00:15:23.805 Uh, class name and the query parameters or the parameters
00:15:23.805 --> 00:15:27.417 that went into that request and all the different things we're
00:15:27.417 --> 00:15:30.972 passing in so varied by user, very by roles, very by headers,
00:15:30.972 --> 00:15:34.469 et cetera. And it generates a unique key for each individual
00:15:34.469 --> 00:15:37.737 thing. I think if I refresh there might be some stuff in
00:15:37.737 --> 00:15:38.310 there now.
00:15:40.180 --> 00:15:40.890 Or not.
00:15:43.360 --> 00:15:44.340 Still loading.
00:15:45.050 --> 00:15:45.340 But.
00:15:46.380 --> 00:15:47.590 What do you want from me?
00:15:49.690 --> 00:15:52.373 I might have broken my stuff. I don't know. I was working on
00:15:52.373 --> 00:15:54.925 something earlier, and I probably have a broken local for
00:15:54.925 --> 00:15:57.784 the moment. That's fine, though. It doesn't really matter. Ohh I
00:15:57.784 --> 00:15:59.060 know why it's taking forever.
00:16:00.120 --> 00:16:01.690 Alright, well anyway.
00:16:02.950 --> 00:16:03.900 Pretend that's not there.
00:16:07.140 --> 00:16:14.206 OK. Yeah. So we create a cache key for our request and then the
00:16:14.206 --> 00:16:18.180 last thing that we do is we have a.
00:16:20.060 --> 00:16:23.257 We take the request and we generate an optimized result
00:16:23.257 --> 00:16:26.569 using the cache. So we would pass in the factory function
00:16:26.569 --> 00:16:29.937 that generates the result. The timeout span for that cache
00:16:29.937 --> 00:16:33.648 result. The cache client itself and the key to cache it with and
00:16:33.648 --> 00:16:36.732 if we go look in here, effectively all we're doing is
00:16:36.732 --> 00:16:40.443 resolving it. If it's already in the cache based on the key, and
00:16:40.443 --> 00:16:43.926 if it's not, then we cache the result by calling the factory
00:16:43.926 --> 00:16:47.523 function and caching it with the key. The time that it expires
00:16:47.523 --> 00:16:48.950 in, et cetera, et cetera.
00:16:50.190 --> 00:16:50.660 So.
00:16:51.610 --> 00:16:55.267 That is all the way down at this layer. That is where the actual
00:16:55.267 --> 00:16:58.812 read it out of the Redis cache if it already exists, otherwise
00:16:58.812 --> 00:17:00.950 cache it and return it if it doesn't.
00:17:02.130 --> 00:17:06.306 So that's the end of this is this return return value. It has
00:17:06.306 --> 00:17:10.146 the compressed everything and etcetera and fun, fun, fun
00:17:10.146 --> 00:17:12.840 stuff. Cool. And we go back up a layer.
00:17:14.090 --> 00:17:15.460 If I keep pressing this button.
00:17:19.380 --> 00:17:22.920 There we go. OK, so the output of this is going to be either.
00:17:24.000 --> 00:17:25.440 A response from the cash.
00:17:26.270 --> 00:17:29.880 If it's already been calculated or a freshly calculated
00:17:29.880 --> 00:17:31.170 compressed response.
00:17:32.970 --> 00:17:34.660 That is the output from this guy right here.
00:17:35.390 --> 00:17:40.026 Uh, and that's the that's the raw response. The rest of this
00:17:40.026 --> 00:17:44.282 is pretty much parsing that content out into a bunch of
00:17:44.282 --> 00:17:49.223 different potential kind of edge cases that it could be where it
00:17:49.223 --> 00:17:54.087 could be a string, it could be null or it could be a compressed
00:17:54.087 --> 00:17:59.027 result most of the time it's the compressed result. So we set up
00:17:59.027 --> 00:18:03.284 the content content type, padding, LinkedIn headers and
00:18:03.284 --> 00:18:05.260 then we return right here.
00:18:05.350 --> 00:18:08.982 An HTTP result that contains the last time it was modified, the
00:18:08.982 --> 00:18:12.614 Max allowed age for this cache, which is typically a minute. It
00:18:12.614 --> 00:18:14.770 looks like the cache control headers.
00:18:15.530 --> 00:18:19.132 Umm the padding length and the content type and then the
00:18:19.132 --> 00:18:23.113 contents itself are attached in the constructor constructor of
00:18:23.113 --> 00:18:26.968 the HTTP result, so that is the actual returned response. We
00:18:26.968 --> 00:18:30.760 make sure we set our headers on the HTTP result and then we
00:18:30.760 --> 00:18:34.362 return it and that's the whole thing that's that is in a
00:18:34.362 --> 00:18:37.080 nutshell how all this Reid is stuff works.
00:18:37.890 --> 00:18:38.530 Umm.
00:18:39.800 --> 00:18:40.330 So.
00:18:42.080 --> 00:18:42.660 Yeah.
00:18:43.470 --> 00:18:48.250 And and and basically. So if you want to actually use server side
00:18:48.250 --> 00:18:52.451 caching, you have to kind of manually opt into it if that
00:18:52.451 --> 00:18:53.320 makes sense.
00:18:54.840 --> 00:18:57.366 And I'm seeing if I can find a good example of a place that
00:18:57.366 --> 00:18:59.850 does that, and there's like, I think maybe in a geography.
00:19:00.660 --> 00:19:01.910 Address service.
00:19:03.500 --> 00:19:04.650 Believe this uses it.
00:19:06.420 --> 00:19:08.210 Maybe maybe it doesn't.
00:19:10.470 --> 00:19:12.620 OK, this doesn't. That's fine.
00:19:13.930 --> 00:19:15.210 I don't the does.
00:19:16.980 --> 00:19:18.890 I want to find one that uses it that's not.
00:19:21.290 --> 00:19:24.314 Let's not like T4 generated so I can show you guys what that
00:19:24.314 --> 00:19:24.860 looks like.
00:19:31.010 --> 00:19:32.780 OK. Yeah, cool.
00:19:34.570 --> 00:19:38.078 So this one is the get current brand request and it basically
00:19:38.078 --> 00:19:41.643 just accepts the request, the last modified function, and then
00:19:41.643 --> 00:19:43.680 a function to calculate the result.
00:19:45.640 --> 00:19:46.730 And.
00:19:47.940 --> 00:19:50.150 Then then it goes through all that logic that we talked about.
00:19:50.810 --> 00:19:55.804 And that is what it looks like to explicitly opt into returning
00:19:55.804 --> 00:19:59.550 cache results from the server side Redis cache.
00:20:02.160 --> 00:20:03.250 And.
00:20:04.770 --> 00:20:07.880 Getting into, I guess, before I move on too much more, I guess
00:20:07.880 --> 00:20:10.990 it looks like Richard, you have a question and then if anybody
00:20:10.990 --> 00:20:14.248 else has any questions, you guys feel free to raise your hands as
00:20:14.248 --> 00:20:15.630 well. But Richard, go ahead.
00:20:17.340 --> 00:20:18.100 That you can hear me?
00:20:18.500 --> 00:20:18.730 Yep.
00:20:20.010 --> 00:20:23.126 I was saying the time frame before the browser actually
00:20:23.126 --> 00:20:26.020 checks for updated stuff was about what, 5 minutes?
00:20:27.580 --> 00:20:29.290 Uh, the browser?
00:20:30.380 --> 00:20:33.820 The browser should hold on to the cache as long as we tell it
00:20:33.820 --> 00:20:37.426 it's allowed to be valid, and it looked like in the code it only
00:20:37.426 --> 00:20:40.533 said one minute, but I've definitely seen it hold on to
00:20:40.533 --> 00:20:43.917 browser cache stuff for more than a minute, so honestly, I'm
00:20:43.917 --> 00:20:45.970 not totally sure what controls that.
00:20:46.740 --> 00:20:50.060 OK, we're using that, Alex is if I.
00:20:50.780 --> 00:20:54.590 Make an update to record and change the updated date.
00:20:56.720 --> 00:21:01.359 Should that immediately trigger the cache to tell the browser
00:21:01.359 --> 00:21:03.230 that data was changed or?
00:21:03.850 --> 00:21:04.380 No.
00:21:03.900 --> 00:21:05.530 Do I just have them naturally wait?
00:21:06.330 --> 00:21:07.340 For it to check again.
00:21:06.600 --> 00:21:07.110 So.
00:21:08.200 --> 00:21:09.900 So the way that that should work.
00:21:11.130 --> 00:21:11.800 Is.
00:21:12.800 --> 00:21:16.928 If the browser doesn't, if the browser serves a cache response
00:21:16.928 --> 00:21:18.370 and I can go and show.
00:21:19.420 --> 00:21:20.590 What that might look like?
00:21:21.420 --> 00:21:24.583 Uh, I'm gonna have to go look at, like, develop, though. It's
00:21:24.583 --> 00:21:25.450 my locals busted.
00:21:27.120 --> 00:21:30.961 So I'll turn off disable cache and I'll just hard refresh this
00:21:30.961 --> 00:21:34.742 page so you can see everything here is 200 okays the size and
00:21:34.742 --> 00:21:38.339 the time is all populated and everything's good except for
00:21:38.339 --> 00:21:42.302 this one says disk cache, which is exactly what I wanted to show
00:21:42.302 --> 00:21:46.205 now while this loads if I just light refresh the page without a
00:21:46.205 --> 00:21:49.924 hard refresh, you can see a bunch of stuff says memory cache
00:21:49.924 --> 00:21:52.790 or disk cache and the page loaded much faster.
00:21:53.630 --> 00:21:57.623 That is browser side caching these memory caches and disk
00:21:57.623 --> 00:22:01.823 caches. They didn't ask the server for anything. The bet the
00:22:01.823 --> 00:22:05.610 setback and never once received any of these requests.
00:22:06.740 --> 00:22:09.615 These ones did because they've actually got time and most of
00:22:09.615 --> 00:22:12.538 them are are set specifically not to be cached for one reason
00:22:12.538 --> 00:22:15.225 or another, but generally speaking, especially all these
00:22:15.225 --> 00:22:18.195 ones like these files, they were completely cached and I think
00:22:18.195 --> 00:22:21.306 maybe if I refresh one more time some of these are probably gonna
00:22:21.306 --> 00:22:22.060 be cached again.
00:22:23.560 --> 00:22:24.240 Umm.
00:22:26.090 --> 00:22:29.342 Let's see. So most of these were not cached, which is fine. I'm
00:22:29.342 --> 00:22:32.238 trying to see if I can see an actual stuff like back end
00:22:32.238 --> 00:22:35.185 request that was cached. It should be able if I go here I
00:22:35.185 --> 00:22:36.100 should be able to.
00:22:42.120 --> 00:22:45.081 You see a bunch of stuff floating, cool, and then if I
00:22:45.081 --> 00:22:48.042 just light and just F5 to refresh this page, it loaded
00:22:48.042 --> 00:22:49.550 much faster and you can see.
00:22:50.240 --> 00:22:54.172 Hopefully, yeah, this guy has a disk cache on it and actual set
00:22:54.172 --> 00:22:57.859 request is back and so this is a good example. This request
00:22:57.859 --> 00:23:01.853 previous page load actually went and asked the stuff back in for
00:23:01.853 --> 00:23:02.160 data.
00:23:03.070 --> 00:23:06.174 At that point the CEF back end could serve me this response
00:23:06.174 --> 00:23:09.381 from the cache. It could serve me this response directly from
00:23:09.381 --> 00:23:12.537 the database and then cache the result. But either way, this
00:23:12.537 --> 00:23:15.900 request in the last page should actually did go to the back end.
00:23:16.610 --> 00:23:20.329 The second time I refreshed the page, my browser said hey, I
00:23:20.329 --> 00:23:24.170 already calculated this and I already know the result for this
00:23:24.170 --> 00:23:28.073 exact request and the back end told me that my local copy of it
00:23:28.073 --> 00:23:31.792 is valid. So I'm just gonna give you it's valid for the next
00:23:31.792 --> 00:23:35.450 minute or it's valid until whenever. So I'm just gonna disk
00:23:35.450 --> 00:23:38.926 cache respond. So that's basically it's just saying that
00:23:38.926 --> 00:23:42.462 this was served from the disk cache. It never even sent a
00:23:42.462 --> 00:23:45.999 request to the back end at that stage. You have no way to
00:23:45.999 --> 00:23:47.340 intercept this change.
00:23:47.410 --> 00:23:49.370 Except 2 clear your browser cache.
00:23:50.300 --> 00:23:53.700 That's where the three or fours were supposed to come in. Is
00:23:53.700 --> 00:23:56.989 that in theory, we would be responding on an endpoint like
00:23:56.989 --> 00:23:58.550 this by telling the browser.
00:23:59.440 --> 00:24:03.976 This is valid, or. Here's a here's a response. This is this
00:24:03.976 --> 00:24:07.530 result set was last modified at 3:00 PM today.
00:24:08.160 --> 00:24:12.259 And then the browser for all follow up requests would send a
00:24:12.259 --> 00:24:14.410 request to the back and say hey.
00:24:14.830 --> 00:24:18.525 Uh has this result as a result of this query been modified
00:24:18.525 --> 00:24:22.345 since 3:00 PM and if the back end gives back a 304, then the
00:24:22.345 --> 00:24:26.290 front end would just serve this response from memory just like
00:24:26.290 --> 00:24:30.110 it did with this time, but you would see the status would be
00:24:30.110 --> 00:24:31.300 304 instead of 200.
00:24:33.020 --> 00:24:33.810 And then.
00:24:33.040 --> 00:24:36.372 So the so is it that there's it's a any acceptable time
00:24:36.372 --> 00:24:40.181 range. So if I'm either request 3:00 o'clock and then I updated
00:24:40.181 --> 00:24:43.751 that 301, is the browser gonna refresh the results or is it
00:24:43.751 --> 00:24:46.310 just gonna wait for a specific time frame?
00:24:48.050 --> 00:24:52.286 If the 304 stuff is working, it should give you a different
00:24:52.286 --> 00:24:52.780 result.
00:24:53.360 --> 00:24:57.190 Umm. In my experience that typically isn't the case.
00:24:59.100 --> 00:24:59.890 And.
00:25:01.250 --> 00:25:05.252 You'll need to like kill your browser cache or anything like
00:25:05.252 --> 00:25:05.580 that.
00:25:06.390 --> 00:25:06.760 OK.
00:25:07.530 --> 00:25:11.491 Now what I will say is something I mentioned earlier is that we
00:25:11.491 --> 00:25:13.100 do have some control over.
00:25:14.220 --> 00:25:16.050 Over the browsers.
00:25:17.230 --> 00:25:18.670 Caching of things.
00:25:20.170 --> 00:25:20.880 And so.
00:25:22.520 --> 00:25:26.191 There, there, there may be some adjustment you can make to your
00:25:26.191 --> 00:25:29.461 API or to the endpoint that you've made depending on how
00:25:29.461 --> 00:25:33.132 frequently you expect that data to change or kind of the nature
00:25:33.132 --> 00:25:34.050 of the endpoint.
00:25:34.780 --> 00:25:38.975 And so that might answer this question a little bit better,
00:25:38.975 --> 00:25:43.100 but generally speaking, I think it seems like the browser.
00:25:44.930 --> 00:25:48.705 The browser doesn't seem to care to do the whole three or four
00:25:48.705 --> 00:25:52.180 thing teams because pretty frequently I will have browser
00:25:52.180 --> 00:25:52.540 cache.
00:25:53.200 --> 00:25:56.661 Results, even with all the three or four code enabled, even with
00:25:56.661 --> 00:25:59.430 disabled cache not enabled, et cetera, et cetera I.
00:26:00.830 --> 00:26:02.900 I have never actually seen.
00:26:04.010 --> 00:26:06.550 A 304 get returned from the back end.
00:26:07.690 --> 00:26:11.249 At least not recently, so there may be some bugs we have to work
00:26:11.249 --> 00:26:12.070 out there, but.
00:26:15.250 --> 00:26:17.480 But generally speaking, if you're changing the data.
00:26:18.700 --> 00:26:22.040 You probably need to flush the OR the clear the browser cache.
00:26:22.800 --> 00:26:23.340 Umm.
00:26:24.600 --> 00:26:25.060 So.
00:26:25.790 --> 00:26:26.220 OK.
00:26:25.800 --> 00:26:29.092 One thing one thing that I did add not too long ago, that kind
00:26:29.092 --> 00:26:32.017 of at least helps in the development side while this is
00:26:32.017 --> 00:26:34.630 happening is there's this cache counter endpoint.
00:26:35.370 --> 00:26:38.991 And all this is doing basically is it's giving the front end
00:26:38.991 --> 00:26:42.613 which I don't know why it takes 953 milliseconds for that to
00:26:42.613 --> 00:26:42.910 load.
00:26:44.170 --> 00:26:45.680 Should be much faster than that.
00:26:46.850 --> 00:26:51.010 OK, 65, let's still really long, but whatever anyway.
00:26:54.260 --> 00:26:57.789 What this does is the front end and it's a it's a, it's a post
00:26:57.789 --> 00:27:01.430 uh post request. So we'll we'll talk about that in a moment. But
00:27:01.430 --> 00:27:04.958 the browser asks the page what's the current cache counter and
00:27:04.958 --> 00:27:08.263 it's one, and then you'll see that all of these have under
00:27:08.263 --> 00:27:11.960 score equals one appended to the end of them. The back end itself
00:27:11.960 --> 00:27:15.433 doesn't really care about this query parameter. It doesn't do
00:27:15.433 --> 00:27:18.849 anything, but the browser will see anything with this number
00:27:18.849 --> 00:27:20.810 different as a new unique request.
00:27:21.510 --> 00:27:24.410 And so if you go in the admin.
00:27:26.790 --> 00:27:30.133 And then clarity Converse admin wait for the load. There's a
00:27:30.133 --> 00:27:33.750 button you can Click to actually bump this counter up by 1:00 and
00:27:33.750 --> 00:27:37.203 what that will then do is every time the page loads, all these
00:27:37.203 --> 00:27:40.272 requests like these get requests that the browser could
00:27:40.272 --> 00:27:42.410 potentially be caching would now have.
00:27:43.250 --> 00:27:46.258 Under score equals 2 instead of 1 and when that two when the
00:27:46.258 --> 00:27:49.216 browser sees the two, it's going to basically gonna say OK,
00:27:49.216 --> 00:27:52.174 that's a different request. That's a different parameter to
00:27:52.174 --> 00:27:55.330 that request. So the results set could be different. So I'm not
00:27:55.330 --> 00:27:58.485 gonna give you my cache response for that endpoint anymore. I'm
00:27:58.485 --> 00:28:01.641 just gonna let this request go through to the server. So that's
00:28:01.641 --> 00:28:04.599 a decent way to kind of step around that. Still waiting for
00:28:04.599 --> 00:28:05.980 this to load taking forever.
00:28:07.250 --> 00:28:07.910 Umm.
00:28:10.630 --> 00:28:12.640 I log in this Claudia admin real quick.
00:28:24.150 --> 00:28:27.444 That button, by the way, to bump up that number is site
00:28:27.444 --> 00:28:28.150 maintenance.
00:28:28.940 --> 00:28:32.599 Other tasks and then increment cache counter right here. So now
00:28:32.599 --> 00:28:34.600 it's two. If we go back over here.
00:28:35.370 --> 00:28:38.620 To the product catalog and justice F5.
00:28:40.120 --> 00:28:43.990 We now see this have under score equals two and they made fresh
00:28:43.990 --> 00:28:47.860 requests. The only things that were served from disk cache were
00:28:47.860 --> 00:28:51.670 the static files, but all the actual requests to the back end.
00:28:52.480 --> 00:28:55.872 Uh were made fresh this one, this one as well. And you can
00:28:55.872 --> 00:28:59.206 see it has the and under score equals 2 on the end. Might
00:28:59.206 --> 00:29:02.713 become hard to see, but then if I refresh one more time over
00:29:02.713 --> 00:29:03.920 here we'll see. Oops.
00:29:05.100 --> 00:29:08.774 Fire refresh for more time light refresh then this one will
00:29:08.774 --> 00:29:12.694 probably be disk cached again. Yep, as are all of these so that
00:29:12.694 --> 00:29:16.430 is the intent with that button is to make it so that you can
00:29:16.430 --> 00:29:20.288 quickly blast the browser cache out without having to tell PMS
00:29:20.288 --> 00:29:23.962 or clients on QA sites like Oh yeah, try to just clear your
00:29:23.962 --> 00:29:27.759 browser because like most of them were like I don't know what
00:29:27.759 --> 00:29:31.250 you're talking about and we shouldn't have to. We should
00:29:31.250 --> 00:29:34.190 have to tell him to do that. So that's kind of.
00:29:31.510 --> 00:29:31.850 Yeah.
00:29:34.280 --> 00:29:36.780 A little work around that I built to to fix that.
00:29:37.420 --> 00:29:38.350 Can you?
00:29:39.180 --> 00:29:41.875 Well, I saw Tim had a I think Tim was going to say something.
00:29:41.875 --> 00:29:42.570 So I don't know.
00:29:43.210 --> 00:29:43.620 Oh, sure.
00:29:44.060 --> 00:29:46.180 Umm to everybody else, said anything to.
00:29:44.150 --> 00:29:44.500 Check.
00:29:45.210 --> 00:29:45.520 10.
00:29:45.230 --> 00:29:47.650 I'll keep her in my my question got answered.
00:29:48.540 --> 00:29:49.050 Oh cool.
00:29:49.510 --> 00:29:51.130 I was going to say could you?
00:29:52.020 --> 00:29:56.444 Talk a little bit about the earned setups in the custom
00:29:56.444 --> 00:29:57.550 service class.
00:29:59.020 --> 00:30:03.590 I kind of when I made a a few endpoints a while back.
00:30:04.400 --> 00:30:07.636 I ran into some caching issues because I didn't realize that
00:30:07.636 --> 00:30:08.220 you had to.
00:30:09.260 --> 00:30:14.291 Set up a specific list of earn IDs to get cleared. Once you do
00:30:14.291 --> 00:30:15.090 the whole.
00:30:16.730 --> 00:30:20.425 Like if you're indexing a bunch of objects and stuff, you gotta
00:30:20.425 --> 00:30:23.600 clear the entire cache, including all the urns in that
00:30:22.720 --> 00:30:24.110 Hmm hmm.
00:30:23.600 --> 00:30:27.179 service class. So I kind of have to like stumble upon it so I
00:30:27.179 --> 00:30:29.200 don't know if you wanna like just.
00:30:29.280 --> 00:30:32.813 That's a really good thing to cover. Yeah. So let me just
00:30:32.813 --> 00:30:34.580 close everything I have here.
00:30:35.400 --> 00:30:37.650 Actually, I'll close everything except this.
00:30:39.510 --> 00:30:42.490 And we will go and look at.
00:30:43.790 --> 00:30:48.687 Umm, I'm pretty sure the product one has it. So looks service.
00:30:48.687 --> 00:30:53.040 Yeah. Perfect. OK, So what Richard is talking about is.
00:30:54.240 --> 00:30:55.340 By default.
00:30:55.770 --> 00:30:59.063 As or I guess maybe not by default, but whenever you create
00:30:59.063 --> 00:31:00.710 new endpoints that are cached.
00:31:03.150 --> 00:31:06.550 For example, like non T4 generated so this endpoint this
00:31:06.550 --> 00:31:09.891 is not T4 generated. This endpoint has caching. You can
00:31:09.891 --> 00:31:13.232 see it's calling useless modified for 304 and blah blah
00:31:13.232 --> 00:31:13.530 blah.
00:31:14.510 --> 00:31:17.660 This endpoint is serving a cached response, but by default.
00:31:18.450 --> 00:31:21.712 The back end has no way to know that this endpoint should be
00:31:21.712 --> 00:31:24.920 cleared whenever you clear the product cache, and that that
00:31:24.920 --> 00:31:27.220 specifically we're talking about like the.
00:31:27.940 --> 00:31:31.100 Umm the the products button in here. Uh, right here. Clearing
00:31:31.100 --> 00:31:34.158 this cache the the back end by default would have no way to
00:31:34.158 --> 00:31:37.216 know that get products for current store is being cached in
00:31:37.216 --> 00:31:39.510 Redis or how to clear the specific endpoint?
00:31:39.750 --> 00:31:41.570 Umm. And so.
00:31:42.210 --> 00:31:46.238 The way that you specifically do that is inside your service or
00:31:46.238 --> 00:31:50.140 inside the product service you can override a list of strings
00:31:50.140 --> 00:31:51.840 called additional earn IDs.
00:31:52.640 --> 00:31:56.030 And in your service layer you override this.
00:31:56.730 --> 00:32:01.250 And you call Ernie dot create and then you pass in.
00:32:01.980 --> 00:32:05.498 All the different classes which are basically endpoint classes
00:32:05.498 --> 00:32:08.792 that you want to be cleared whenever the product button is
00:32:08.792 --> 00:32:11.640 clicked. Keep in mind that if you were looking at.
00:32:13.520 --> 00:32:14.700 That's good. Good example.
00:32:16.400 --> 00:32:19.454 Well, not really because it's using Jeff shared service, but
00:32:19.454 --> 00:32:22.559 pretend this was using product price point service instead of
00:32:22.559 --> 00:32:23.510 set shared service.
00:32:25.290 --> 00:32:28.918 And I added stuff in here, adding stuff to the product
00:32:28.918 --> 00:32:32.546 price point services. Additional earn IDs means that I
00:32:32.546 --> 00:32:36.570 specifically would need to click on the where's the product?
00:32:38.280 --> 00:32:41.127 Product price points button to clear that cache because that's
00:32:41.127 --> 00:32:43.838 the additional earn ideas I put in the product price points
00:32:43.838 --> 00:32:44.200 service.
00:32:44.910 --> 00:32:46.580 Umm, so just keep in mind that.
00:32:47.240 --> 00:32:47.890 UM.
00:32:48.910 --> 00:32:52.331 The the actual service class that you put the additional earn
00:32:52.331 --> 00:32:53.380 IDs in does matter.
00:32:55.660 --> 00:32:59.278 So this one will clear if I just click the clear product button
00:32:59.278 --> 00:33:02.897 but it will not clear anything that's under product category or
00:33:02.897 --> 00:33:05.950 product price point, excuse me, et cetera, et cetera.
00:33:07.460 --> 00:33:07.990 So.
00:33:09.370 --> 00:33:12.590 Yeah. So that's pretty much that's pretty much the the gist
00:33:12.590 --> 00:33:13.020 of that.
00:33:15.760 --> 00:33:16.640 And.
00:33:18.480 --> 00:33:21.470 Yeah, hopefully that covers, I think the the.
00:33:22.320 --> 00:33:23.410 What you were looking for there?
00:33:24.370 --> 00:33:29.227 And then last thing I have to cover before we can just get
00:33:29.227 --> 00:33:34.413 into some general stuff is what you can do as an API developer
00:33:34.413 --> 00:33:34.660 to.
00:33:35.350 --> 00:33:37.420 Take a little bit of control over caching.
00:33:38.620 --> 00:33:39.410 And.
00:33:40.350 --> 00:33:40.820 Uh.
00:33:42.020 --> 00:33:43.050 Tame the beast.
00:33:44.140 --> 00:33:48.327 Uh, so the first thing, the most basic thing is understanding the
00:33:48.327 --> 00:33:52.134 difference between the different the difference between the
00:33:52.134 --> 00:33:55.243 different types of HTTP requests. You can do the
00:33:55.243 --> 00:33:57.400 different methods, so by default.
00:33:58.300 --> 00:34:01.694 Uh, the browser will treat get requests as browser side
00:34:01.694 --> 00:34:02.300 cacheable.
00:34:03.020 --> 00:34:03.810 Umm.
00:34:04.560 --> 00:34:07.925 And we can dictate the way that it does that with cache control
00:34:07.925 --> 00:34:11.186 headers and the response, but the the best way to think about
00:34:11.186 --> 00:34:14.183 it is forgetting about cache control headers, forgetting
00:34:14.183 --> 00:34:17.443 everything else, get requests. The browser is just, it's just
00:34:17.443 --> 00:34:20.598 gonna try to cache it as much as it as you will give it the
00:34:20.598 --> 00:34:23.806 leeway to do. And if you don't tell it how much it can cache
00:34:23.806 --> 00:34:26.120 it, it's going to cache the **** out of it.
00:34:26.820 --> 00:34:30.812 Uh, so just keep that in mind. Get requests should primarily be
00:34:30.812 --> 00:34:34.493 used for things that you want the browser to cache, IE the
00:34:34.493 --> 00:34:38.548 data is largely static or things that you're telling the browser
00:34:38.548 --> 00:34:42.353 with cache control headers and things like that how to cache
00:34:42.353 --> 00:34:45.971 the response so that you have some control over it. So if
00:34:45.971 --> 00:34:49.402 you've got some live data endpoint that's doing you're
00:34:49.402 --> 00:34:52.958 expecting to be changing frequently, or you want to make
00:34:52.958 --> 00:34:56.950 sure that it's live calls every time, do not use a get request.
00:34:58.390 --> 00:35:01.020 Even if you are technically getting data.
00:35:01.740 --> 00:35:05.490 Get request will as much as the browser will as much as you give
00:35:05.490 --> 00:35:09.125 the browser leeway to will be cached, so that's just the first
00:35:08.570 --> 00:35:08.900 Is.
00:35:09.125 --> 00:35:09.990 thing to avoid.
00:35:10.440 --> 00:35:13.630 Is that true even if you add a timestamp to the URL?
00:35:14.880 --> 00:35:18.191 No, the so that's kind of like the the little thing I was
00:35:18.191 --> 00:35:21.616 showing over here, the under score equals two. That's a way
00:35:21.616 --> 00:35:25.041 to circumvent that because the browser does technically see
00:35:25.041 --> 00:35:28.466 different timestamps or other things like that as different
00:35:28.466 --> 00:35:28.980 requests.
00:35:29.590 --> 00:35:33.613 Umm, but if you make the same get request i.e. The same
00:35:33.613 --> 00:35:37.996 timestamp or the same iteration number or whatever you wanna
00:35:37.996 --> 00:35:39.720 call this cache counter.
00:35:41.560 --> 00:35:44.619 And it's a get request that is, that is the first ticket to
00:35:44.619 --> 00:35:47.475 browser side caching and generally speaking what I want
00:35:47.475 --> 00:35:50.585 to avoid here is telling people don't use Git requests ever,
00:35:50.585 --> 00:35:53.390 because the browser will cache it because that is not.
00:35:54.210 --> 00:35:58.242 That is not the the point I want to make. The point I wanna make
00:35:58.242 --> 00:36:02.088 is there's a time and a place for everything and get requests
00:36:02.088 --> 00:36:05.933 are a fantastic way to just get free performance optimization
00:36:05.933 --> 00:36:09.469 for largely static data. There is a small dog in my yard
00:36:09.469 --> 00:36:11.640 wearing a shirt. Hold on a moment.
00:36:13.780 --> 00:36:16.220 What a good dog. Why is he wearing a shirt though?
00:36:17.500 --> 00:36:18.390 Honestly, if you.
00:36:17.600 --> 00:36:18.870 Is embarrassed's body.
00:36:17.720 --> 00:36:18.560 Whose dog? West.
00:36:19.910 --> 00:36:21.130 This sounds like a fever dream.
00:36:20.020 --> 00:36:20.820 That is amazing.
00:36:22.120 --> 00:36:23.490 It just it just hanging out.
00:36:24.910 --> 00:36:26.020 OK, no shirt. Is he wearing?
00:36:26.800 --> 00:36:28.160 It's like a little.
00:36:27.440 --> 00:36:28.040 So I think.
00:36:28.240 --> 00:36:32.453 Uh, like a diamond pattern, like little vest. He looks very
00:36:32.160 --> 00:36:32.710 Ha.
00:36:32.453 --> 00:36:34.490 formal, actually. Very, very.
00:36:35.490 --> 00:36:39.330 I think he wants to be adopted into your cohort. Yeah, festive.
00:36:35.710 --> 00:36:36.810 Uh festive?
00:36:39.690 --> 00:36:43.059 He does. He looks very festive. He's in the neighbor's yard now.
00:36:39.790 --> 00:36:40.550 Interesting.
00:36:43.059 --> 00:36:43.940 Sorry about that.
00:36:45.220 --> 00:36:48.392 I got a little little bit of the little bit of the AD, just
00:36:48.392 --> 00:36:50.190 something in my peripheral moved.
00:36:51.570 --> 00:36:55.000 So anyway, back to what I'm saying so.
00:36:56.140 --> 00:36:57.210 When we're looking at.
00:36:58.830 --> 00:37:01.731 Building a new endpoint, the thing you need to ask yourself
00:37:01.731 --> 00:37:03.520 is how static or dynamic is my data.
00:37:04.210 --> 00:37:05.230 And.
00:37:06.040 --> 00:37:10.236 Uh, does it make sense that I would want to allow the browser
00:37:10.236 --> 00:37:14.432 to cache this and in a lot of situations the answer obviously
00:37:14.432 --> 00:37:18.560 is yes. A good example of that is the response for like this
00:37:18.560 --> 00:37:19.440 catalog page.
00:37:20.600 --> 00:37:24.174 In a production, obviously in our locals and in our QA sites,
00:37:24.174 --> 00:37:27.864 this date is going to be pretty fluid as we're iterating on the
00:37:27.864 --> 00:37:31.265 site, but ultimately when it once it gets into production,
00:37:31.265 --> 00:37:34.897 this data is going to be pretty static and so we want to allow
00:37:34.897 --> 00:37:38.471 the browser to take advantage of that and cache it to improve
00:37:38.471 --> 00:37:41.930 page load and reduce the load on our server or the client's
00:37:41.930 --> 00:37:45.446 production server, et cetera. And so in that situation, they
00:37:45.446 --> 00:37:46.830 get request makes sense.
00:37:47.290 --> 00:37:48.000 UM.
00:37:48.690 --> 00:37:51.898 But on the flip side, you also have endpoints for stuff like,
00:37:51.898 --> 00:37:54.899 uh, getting your current cart, which is gonna be changing
00:37:54.899 --> 00:37:57.899 pretty frequently. Even in production, you're going to be
00:37:57.899 --> 00:38:00.590 adding removing things from your card all the time.
00:38:01.290 --> 00:38:05.751 Uh, you've got post requests for calculating inventory, which
00:38:05.751 --> 00:38:10.068 obviously could change at any time. So we really don't want
00:38:10.068 --> 00:38:13.090 the browser caching that. We also have a.
00:38:15.320 --> 00:38:16.250 Trying to find it in here.
00:38:17.950 --> 00:38:21.140 Uh. Perfect pricing also is not cached in the browser.
00:38:21.840 --> 00:38:23.640 Because again, that could change at any time.
00:38:23.900 --> 00:38:28.533 Umm. And so we we can kind of dictate this is kind of the the
00:38:28.533 --> 00:38:33.167 first line of defense if you will for dictating how data gets
00:38:33.167 --> 00:38:37.501 cached and how to kind of manipulate maybe not manipulate
00:38:37.501 --> 00:38:37.800 but.
00:38:38.980 --> 00:38:42.281 But take a little bit of exercise, a little bit of
00:38:42.281 --> 00:38:45.712 control over what does and doesn't get cached by the
00:38:45.712 --> 00:38:49.790 browser. So the kind of rule is if you know your data is gonna
00:38:49.790 --> 00:38:53.673 be changing potentially every request or frequently, or you
00:38:53.673 --> 00:38:57.104 want to make sure that somebody's always 100% of the
00:38:57.104 --> 00:39:00.470 time without fail going to see the latest raw data.
00:39:01.170 --> 00:39:04.517 Don't use a get method as the verb because like I said
00:39:04.517 --> 00:39:08.350 earlier, the browser to the full extent that you will allow it
00:39:08.350 --> 00:39:10.480 will cache that as much as it can.
00:39:11.600 --> 00:39:15.923 And so again, there's cache control headers that we can talk
00:39:15.923 --> 00:39:17.270 about as well, but.
00:39:18.630 --> 00:39:22.249 First line of defense is if it's, if it's dynamic data, just
00:39:22.249 --> 00:39:26.046 use a post request or something along those lines. Post request
00:39:26.046 --> 00:39:28.300 is generally the one that you'll see.
00:39:29.100 --> 00:39:33.192 Umm and yeah, so that's that's kind of a nice thing to know.
00:39:33.192 --> 00:39:37.218 Get requests big for caching. Don't avoid them just so that
00:39:37.218 --> 00:39:41.310 your local development is easier because they do have value.
00:39:42.490 --> 00:39:45.253 They might be a bit of a pain in the *** sometimes, but don't
00:39:45.253 --> 00:39:47.927 avoid them just because it's like yeah, but browser caching
00:39:47.927 --> 00:39:49.620 is annoying sometimes like it is but.
00:39:50.710 --> 00:39:54.133 We need, we need the we need to take advantage of that for for
00:39:54.133 --> 00:39:55.220 site performance so.
00:39:55.730 --> 00:39:56.220 Umm.
00:39:57.770 --> 00:40:00.490 So yeah, that's kind of the that's kind of the first major
00:40:00.490 --> 00:40:03.440 line of defense for caching, for taking control of caching. And
00:40:03.440 --> 00:40:05.929 then the other is the cache control headers. And if I
00:40:05.929 --> 00:40:08.695 recall, this is not something that we typically do much and
00:40:08.695 --> 00:40:11.415 stuff a lot of this is handled automatically for us by the
00:40:11.415 --> 00:40:13.720 three or four logic that we already went through.
00:40:14.450 --> 00:40:16.450 But I believe.
00:40:18.070 --> 00:40:21.953 And let's say that there are actually used in here. Yeah, so
00:40:21.953 --> 00:40:25.773 this like Sev cache response attribute you can actually tag
00:40:25.773 --> 00:40:29.720 endpoints with this. And as far as I know this actually does.
00:40:30.450 --> 00:40:31.170 Umm.
00:40:32.590 --> 00:40:36.420 Properly set the header, so we're telling this that this can
00:40:36.420 --> 00:40:39.120 be cached for an hour 60 seconds times 60.
00:40:39.720 --> 00:40:40.450 Umm.
00:40:42.040 --> 00:40:45.413 Uh, so that gets her sets the cache expiration in seconds, is
00:40:45.413 --> 00:40:48.297 how long the cash will save inside the server before
00:40:48.297 --> 00:40:51.561 checking for the actual data again, and then the Max age is
00:40:51.561 --> 00:40:54.499 how long the browser waits before rechecking with the
00:40:54.499 --> 00:40:57.927 server. So this will actually kind of give you a little bit of
00:40:57.927 --> 00:41:00.974 customization even with get requests on how long you're
00:41:00.974 --> 00:41:03.640 letting the browser hold on to that information.
00:41:04.570 --> 00:41:05.260 Umm.
00:41:06.010 --> 00:41:11.754 So I hope that I hope that helps with some of this, hopefully
00:41:11.754 --> 00:41:12.680 everybody.
00:41:13.760 --> 00:41:15.530 Got a little bit out of the uh.
00:41:17.030 --> 00:41:17.630 Out of the.
00:41:18.280 --> 00:41:18.950 Discussion.
00:41:20.900 --> 00:41:22.560 Or like monologue, but.
00:41:23.510 --> 00:41:26.499 Yeah. Anybody have any questions on anything else with this? If
00:41:26.499 --> 00:41:27.760 not, we can just move into.
00:41:28.610 --> 00:41:33.253 Uh assist with the whatnots. Anything anybody needs help
00:41:33.253 --> 00:41:33.660 with.
00:41:35.430 --> 00:41:38.200 Would it be possible to have an app setting that just?
00:41:39.620 --> 00:41:43.270 Disables all caching for a local environment.
00:41:44.100 --> 00:41:47.630 Uh, yes. And that is something that I do want to do.
00:41:49.080 --> 00:41:51.883 I have not had time to go in and do it yet, but there's a couple
00:41:51.883 --> 00:41:53.780 of improvements that could be made in here.
00:41:54.330 --> 00:41:54.980 Umm.
00:41:56.500 --> 00:41:58.150 Like we saw earlier, there's a.
00:41:59.000 --> 00:42:01.670 You kinda have to drill down pretty far before you find.
00:42:02.330 --> 00:42:04.980 Where the actual cache result is generated and stored into the
00:42:04.980 --> 00:42:07.210 cache or read out of the cache things like that. So.
00:42:08.430 --> 00:42:10.789 I have an alternate implementation of this method
00:42:10.789 --> 00:42:12.960 that I've built, but it has some performance.
00:42:13.190 --> 00:42:19.680 Uh, implications that were not happy with yet. So I want to.
00:42:20.590 --> 00:42:24.272 Find a better way to to basically go about that specific
00:42:24.272 --> 00:42:28.407 part of it, but the end result is that uh, this method is a lot
00:42:28.407 --> 00:42:32.541 cleaner and easier to read and it gives you a lot more control.
00:42:32.541 --> 00:42:36.029 Specifically, it has a flag for just skipping caching
00:42:36.029 --> 00:42:36.740 altogether.
00:42:37.920 --> 00:42:40.846 And I think I think that does have a ton of value for a local
00:42:40.846 --> 00:42:43.913 environments where you're like, I don't care if the page takes a
00:42:43.913 --> 00:42:46.886 couple extra seconds to load. I just need to make sure that my
00:42:46.886 --> 00:42:49.340 data is working and that my back end logic is good.
00:42:50.680 --> 00:42:51.340 And so.
00:42:52.090 --> 00:42:55.137 And then it's probably it would probably be something where we
00:42:55.137 --> 00:42:58.040 we don't allow that setting to be enabled in like a release
00:42:58.040 --> 00:43:01.039 build or something just so that somebody doesn't accidentally
00:43:01.039 --> 00:43:03.990 turn it on a production site and like wreck the performance.
00:43:05.430 --> 00:43:10.389 But, but yeah, definitely something that I would like to
00:43:10.389 --> 00:43:15.869 hopefully get in before 2022.4, which we should be putting out
00:43:15.869 --> 00:43:17.870 at the end of December.
00:43:19.280 --> 00:43:21.515 So, but yeah, that's a great question and and definitely
00:43:21.515 --> 00:43:23.750 something that will that will probably do at some point.
00:43:30.830 --> 00:43:31.660 Any other?
00:43:32.360 --> 00:43:33.910 Thoughts. Questions.
00:43:34.660 --> 00:43:37.510 Fears, beliefs, creeds, even.
00:43:45.380 --> 00:43:49.190 If not, we can go on to.
00:43:50.290 --> 00:43:53.831 Uh. Assistance with stuff. So anybody have anything they're
00:43:53.831 --> 00:43:54.480 working on?
00:43:55.280 --> 00:43:59.026 Client, project, task, et cetera that they're like. Hey, could I
00:43:59.026 --> 00:44:00.640 have some questions on that?00:00:03.782 --> 00:00:06.122 That's kind of it's kind of my thing.
00:00:07.622 --> 00:00:08.742 I have some.
00:00:10.392 --> 00:00:14.822 I have a vanishing sales item bug in checkout.
00:00:16.082 --> 00:00:18.142 Well, it's not really a bug, but.
00:00:18.902 --> 00:00:22.337 I don't know if you remember a while black comedy looked at
00:00:22.337 --> 00:00:25.886 checkout and we noticed that pretty much at some point during
00:00:25.886 --> 00:00:29.606 the process the sales item gets cloned and compared and then the
00:00:29.606 --> 00:00:32.582 original gets deleted and the new one gets created.
00:00:35.312 --> 00:00:36.842 I think I do remember that.
00:00:38.042 --> 00:00:43.972 Yeah. So pretty much the refactor did for the placeholder
00:00:43.972 --> 00:00:50.617 records. It sticks the original sale item ID onto the actual job
00:00:50.617 --> 00:00:51.332 record.
00:00:51.982 --> 00:00:55.952 But since the original gets snooped somewhere along the
00:00:55.952 --> 00:01:00.062 line, it's hard to actually line them back up afterwards.
00:01:01.212 --> 00:01:02.562 Although at the end the checkouts.
00:01:03.202 --> 00:01:03.532 Umm.
00:01:05.232 --> 00:01:05.832 Uh.
00:01:07.282 --> 00:01:07.792 I.
00:01:08.632 --> 00:01:13.225 Did get some assistance from JG to attach a collection of job
00:01:13.225 --> 00:01:14.262 openings onto?
00:01:14.992 --> 00:01:16.672 The sales item itself.
00:01:17.492 --> 00:01:21.662 But I've never gotten to successfully like clone.
00:01:22.352 --> 00:01:27.023 The full collection list on to the compared sales item that is
00:01:27.023 --> 00:01:27.542 cloned.
00:01:28.712 --> 00:01:31.459 And for some reason, even though I save my unit of work, I still
00:01:31.459 --> 00:01:33.022 don't see the list show up anywhere.
00:01:35.132 --> 00:01:35.602 So.
00:01:35.342 --> 00:01:35.652 Hmm.
00:01:37.682 --> 00:01:41.287 I gotta switch over branches if you're interested, so I'd be
00:01:41.287 --> 00:01:42.232 like 10 minutes.
00:01:42.972 --> 00:01:46.522 So if anybody else has anything, then they can jump in.
00:01:52.092 --> 00:01:53.082 I have a question.
00:01:54.052 --> 00:01:54.592 What's that?
00:01:54.062 --> 00:01:58.521 Umm, how do you and I'm going to show off my my back end
00:01:58.521 --> 00:02:01.572 ignorance here, but how do you modify?
00:02:02.362 --> 00:02:05.032 84 generated endpoint.
00:02:07.282 --> 00:02:08.972 That is a fantastic question.
00:02:08.942 --> 00:02:09.422 Thank you, Matt.
00:02:11.052 --> 00:02:14.140 There are multiple options that you could choose from. Ohh you
00:02:13.922 --> 00:02:14.672 Indeed.
00:02:14.140 --> 00:02:15.022 could override it.
00:02:16.392 --> 00:02:21.402 OK, what's the most common way or the OR the simplest way, OK.
00:02:16.552 --> 00:02:17.262 I'll real quick.
00:02:19.172 --> 00:02:23.086 I'll go through. Yeah, I'll go through a couple of them real
00:02:23.086 --> 00:02:27.255 quick. So let's say that I want to override for some reason just
00:02:27.255 --> 00:02:31.361 because this is the first file and the first endpoint I went to
00:02:31.361 --> 00:02:35.402 override get account by ID to do something slightly different.
00:02:38.692 --> 00:02:42.176 So what I'm gonna do is here's my endpoint, and if I go and
00:02:42.176 --> 00:02:45.485 find you guys are probably seeing this, but like you can
00:02:45.485 --> 00:02:49.201 find the endpoint by searching for this route. Here's the class
00:02:49.201 --> 00:02:52.510 and then I can find all references on this. If you don't
00:02:52.510 --> 00:02:55.935 have the little reference viewer I people turn this off. I
00:02:55.935 --> 00:02:56.922 actually like it.
00:02:58.722 --> 00:03:01.691 But you can see that it's used. You'll find the the the method
00:03:01.691 --> 00:03:04.708 called get or the method called post or whatever that calls it.
00:03:04.708 --> 00:03:07.582 Here's the actual caller for this. However, once again, it's
00:03:07.582 --> 00:03:10.410 an at 4 generated file. You scroll up, you can see it's got
00:03:10.410 --> 00:03:13.379 the auto generated header. So the question that David's asking
00:03:13.379 --> 00:03:15.452 is what if I want to change what this does?
00:03:16.512 --> 00:03:20.676 And the answer there would be the first way is you can go into
00:03:20.676 --> 00:03:25.039 the regular in this case account service because I'm modifying an
00:03:25.039 --> 00:03:26.162 account endpoint.
00:03:27.652 --> 00:03:31.027 And uh Visual Studio, at least full Visual Studio. Does this
00:03:31.027 --> 00:03:34.180 really nice thing where you can just go in here and type
00:03:34.180 --> 00:03:37.720 override space and it will give you a list of all the stuff you
00:03:37.720 --> 00:03:41.039 can override. And in here is get account by ID. So if I tab
00:03:41.039 --> 00:03:42.422 whoopsies that's not tab.
00:03:43.302 --> 00:03:47.541 It didn't get count by ID press tab, it fills it in and now I
00:03:47.541 --> 00:03:51.644 can add custom logic for get account by ID if I wanted to I
00:03:51.644 --> 00:03:55.882 could do based result equals await base dot git configure it.
00:03:56.562 --> 00:04:00.580 Configure await falls and now I have the result of the original
00:03:59.422 --> 00:03:59.652 So.
00:04:00.580 --> 00:04:04.724 logic for this endpoint and then I can. Do you know. I don't know
00:04:04.724 --> 00:04:04.912 if.
00:04:05.512 --> 00:04:07.702 Uh quest dot?
00:04:09.102 --> 00:04:11.652 Whatever additional logic based result dot.
00:04:13.872 --> 00:04:15.032 What is this result?
00:04:14.072 --> 00:04:16.900 Like if one of the issues you're having is you're serializable
00:04:16.900 --> 00:04:19.369 attribute is making your response so big that it can't
00:04:19.369 --> 00:04:22.062 deserialize, he could null that out or something like that.
00:04:22.342 --> 00:04:25.728 Yeah, yeah. But anyway, yeah, you'd be able to do whatever you
00:04:25.728 --> 00:04:29.114 want, or if you don't even want to use the original logic, you
00:04:29.012 --> 00:04:29.192 And.
00:04:29.114 --> 00:04:32.017 can just do whatever you want and you can call it the
00:04:32.017 --> 00:04:35.403 workflows dot accounts dot my custom get my ID request dot ID.
00:04:33.322 --> 00:04:33.612 OK.
00:04:35.403 --> 00:04:38.735 However you wanna do it? That would be the first kind of step
00:04:37.062 --> 00:04:37.322 And.
00:04:38.735 --> 00:04:39.272 basically.
00:04:39.262 --> 00:04:43.209 How? How would you know like without you telling me or or I?
00:04:43.209 --> 00:04:46.898 I don't know. Maybe. Maybe that's the way. But how would
00:04:46.898 --> 00:04:49.162 you know that? Like they get here?
00:04:50.162 --> 00:04:51.952 Is what would be called.
00:04:53.222 --> 00:04:57.686 Because it's overriding the base class. So if we go back and look
00:04:57.686 --> 00:05:00.932 over here, this get is in account service base.
00:05:02.012 --> 00:05:04.858 And there's precisely one reference to this class, which
00:05:02.162 --> 00:05:03.122 Right. OK.
00:05:04.858 --> 00:05:08.052 is to set up the partial that we can do our overrides in, which
00:05:08.052 --> 00:05:10.947 is just called account service. The class that we put our
00:05:10.362 --> 00:05:10.812 OK.
00:05:10.947 --> 00:05:13.742 override in is account service. The top level the most.
00:05:14.422 --> 00:05:17.840 The most derived version of any given method signature is the
00:05:17.840 --> 00:05:19.052 one that will be used.
00:05:21.362 --> 00:05:21.752 OK.
00:05:25.492 --> 00:05:25.812 OK.
00:05:27.992 --> 00:05:32.494 Cool. I don't totally understand that, but I understand the words
00:05:32.494 --> 00:05:34.812 you said and maybe 60% of it, so.
00:05:35.712 --> 00:05:38.467 I'll ask it again when I wanna do this and then what? What are
00:05:38.467 --> 00:05:39.122 the other ways?
00:05:40.302 --> 00:05:43.555 The other way would be if the functionality of the endpoint
00:05:43.555 --> 00:05:46.754 itself was fine and you just wanted to change the workflow
00:05:46.754 --> 00:05:50.224 implementation. So then what you could do is you could find the
00:05:49.202 --> 00:05:49.982 Umm, alright.
00:05:50.224 --> 00:05:53.640 T4 generated one and see OK well this one. Not a great example
00:05:53.640 --> 00:05:56.730 because it's doing some complicated stuff. We'll go look
00:05:56.730 --> 00:05:57.272 at create.
00:05:57.972 --> 00:06:00.082 And you can see that it's calling.
00:06:02.302 --> 00:06:05.274 Workflows dot accounts dot create async. OK well, what if I
00:06:05.274 --> 00:06:06.512 wanted to go change that?
00:06:07.112 --> 00:06:11.562 Umm, I can go and see the best thing to do here would be.
00:06:13.462 --> 00:06:18.074 First you need to go into the 05 business logic accounts account
00:06:18.074 --> 00:06:22.261 and find account crowd workflow dot extended. This is a 94
00:06:22.261 --> 00:06:26.305 generated and check in here and see if there is a create
00:06:26.305 --> 00:06:26.872 already.
00:06:27.992 --> 00:06:31.633 So in this case, it looks like there's no existing overrides.
00:06:31.633 --> 00:06:35.333 Then I could just pick a place probably closer to the top, and
00:06:35.333 --> 00:06:38.680 again same deal overrides space and all the things I can
00:06:38.680 --> 00:06:42.556 override and we can go ahead and just override the one that takes
00:06:42.556 --> 00:06:45.492 when you're typically when you're overriding the.
00:06:46.182 --> 00:06:46.692 Uh.
00:06:48.352 --> 00:06:51.105 Workflows like the default crud stuff create or update or
00:06:51.105 --> 00:06:53.715 whatever. It's easier to override the one that already
00:06:53.715 --> 00:06:56.515 takes the database context because if you override the one
00:06:56.515 --> 00:06:59.505 that uses the context profile name literally all it does is it
00:06:59.505 --> 00:07:02.305 gets a database context with that context profile name and
00:07:02.305 --> 00:07:05.294 then calls this one. So there's not. I mean, you might as well
00:07:05.294 --> 00:07:08.189 just override this one and then you can do whatever you want
00:07:08.189 --> 00:07:10.989 with that model and just if you're like, oh, I need to set
00:07:10.989 --> 00:07:13.789 some specific properties on this model on this on accounts
00:07:13.789 --> 00:07:16.589 whenever they're being created just to make sure that some
00:07:16.589 --> 00:07:18.202 specific data for this client is.
00:07:18.292 --> 00:07:23.271 This respected then you can do that here. So like Oh yeah all
00:07:23.271 --> 00:07:23.592 all.
00:07:25.052 --> 00:07:27.762 Uh accounts that get created have a store.
00:07:30.782 --> 00:07:34.343 So you can add a new store model to this and you know whatever
00:07:34.343 --> 00:07:37.677 active equals true, etcetera. It's going to complain about
00:07:37.677 --> 00:07:38.242 something.
00:07:39.422 --> 00:07:42.332 Ohh yeah, OK store account model.
00:07:44.032 --> 00:07:46.712 And then it's slightly blooms new store model.
00:07:47.542 --> 00:07:48.522 It should be master.
00:07:50.982 --> 00:07:53.642 Equals new store model and you can actually true and.
00:07:54.612 --> 00:07:55.942 Blah blah blah and then you can.
00:07:56.682 --> 00:08:00.232 Return base dot create async uh and do whatever you wanna do
00:08:00.232 --> 00:08:03.898 with that. So we've modified our incoming model and then we're
00:08:03.898 --> 00:08:07.331 passing that up into create async and it'll do the regular
00:08:07.331 --> 00:08:10.590 create logic and mapping everything and blah blah blah.
00:08:10.590 --> 00:08:14.372 But we've we can kind of preempt it and attach some extra stuff.
00:08:17.922 --> 00:08:18.902 OK, cool.
00:08:23.652 --> 00:08:25.952 Are those the two most common ways you could say?
00:08:25.792 --> 00:08:29.333 Yeah, those would be the. Those would be the 95% of the time.
00:08:29.333 --> 00:08:33.045 That will be what you're doing. There could also be there's rare
00:08:33.045 --> 00:08:36.472 scenarios where you're like I need to change like customize
00:08:36.472 --> 00:08:39.784 the way something maps out in a way that like the mapping
00:08:39.784 --> 00:08:43.268 attributes up here like the force map out with listing stuff
00:08:43.268 --> 00:08:46.466 won't do. And then those scenarios you have to make the
00:08:46.466 --> 00:08:50.064 custom mapping hooks that are a little bit more complicated. I
00:08:50.064 --> 00:08:52.462 know there's one, I think it's on orders.
00:08:54.252 --> 00:08:57.002 Umm, I usually end up having to find an example of these.
00:08:58.622 --> 00:08:59.512 No, that's not the one.
00:09:01.212 --> 00:09:04.064 I usually have to try to find an example of these that already
00:09:04.064 --> 00:09:05.422 exists because it's easier to.
00:09:08.322 --> 00:09:08.912 One second.
00:09:21.782 --> 00:09:23.562 Probably find it pretty easily if you search for a hook.
00:09:25.132 --> 00:09:25.532 Yeah.
00:09:27.282 --> 00:09:28.372 I was trying to message.
00:09:36.042 --> 00:09:38.462 That doesn't help too much. I wish I could.
00:09:40.092 --> 00:09:40.452 Just.
00:09:42.222 --> 00:09:44.720 That search inside another, I guess I can if I just do it,
00:09:44.720 --> 00:09:45.862 they'll do it the hard way.
00:09:48.542 --> 00:09:51.242 Look in. Let me open up.
00:09:52.492 --> 00:09:54.062 Thing in the workflows and then.
00:09:55.522 --> 00:09:56.162 Look.
00:09:56.962 --> 00:09:59.032 Current project find all.
00:10:03.182 --> 00:10:03.672 No.
00:10:14.542 --> 00:10:14.772 Hmm.
00:10:15.602 --> 00:10:17.312 There's a lot more things in here that are.
00:10:18.742 --> 00:10:20.332 Called Hook than I expected.
00:10:22.272 --> 00:10:24.022 And I guess another question would be.
00:10:22.902 --> 00:10:25.072 Ah, here we go. Discounts.
00:10:26.092 --> 00:10:28.222 Umm, so the process. Yeah, go ahead. Go ahead.
00:10:26.322 --> 00:10:29.267 Another question before you share this, the question would
00:10:29.267 --> 00:10:31.962 be like how would you determine if you did it in the?
00:10:32.692 --> 00:10:35.192 Umm, in the service or the workflow?
00:10:36.482 --> 00:10:37.532 What would be the difference between?
00:10:36.582 --> 00:10:37.262 You could.
00:10:38.122 --> 00:10:39.982 It depends on the information that you need.
00:10:40.872 --> 00:10:41.132 OK.
00:10:41.522 --> 00:10:45.382 The service at the service layer you have access to.
00:10:46.722 --> 00:10:50.562 You've access to stuff like the current account, current user,
00:10:50.562 --> 00:10:54.219 current brand, session ID, all that kind of stuff. But once
00:10:51.212 --> 00:10:51.632 Umm.
00:10:54.219 --> 00:10:57.998 you've called into a workflow, you no longer have that stuff.
00:10:57.032 --> 00:10:57.742 OK.
00:10:57.998 --> 00:11:01.716 So if you're overwriting the behavior of an endpoint and the
00:11:01.716 --> 00:11:04.641 workflow that it's calling doesn't have all the
00:11:04.641 --> 00:11:05.372 information.
00:11:06.202 --> 00:11:06.962 Uh.
00:11:08.152 --> 00:11:11.172 In handling the in the service layer, OK.
00:11:09.582 --> 00:11:11.854 You would have to. You would handle in the service layer so
00:11:11.854 --> 00:11:14.162 you could change what you're passing down into the workflow.
00:11:14.642 --> 00:11:15.102 OK.
00:11:16.702 --> 00:11:18.492 And I guess sometimes you'll change both.
00:11:16.892 --> 00:11:17.592 Uh.
00:11:19.392 --> 00:11:23.265 Yeah, and. And so in that scenario, if you were changing
00:11:20.252 --> 00:11:20.412 Yeah.
00:11:23.265 --> 00:11:27.546 your passing down, you'd have to change both. Yeah, but that's
00:11:27.546 --> 00:11:31.962 kind of a the the a quick litmus test of like, do I need to, you
00:11:31.962 --> 00:11:35.835 probably wouldn't really typically modify at the service
00:11:35.835 --> 00:11:36.242 layer.
00:11:37.572 --> 00:11:40.519 Unless you were just doing some really quick like post
00:11:40.519 --> 00:11:42.822 processing on a result, kind of like what?
00:11:42.902 --> 00:11:43.292 The.
00:11:45.242 --> 00:11:45.582 Umm.
00:11:45.702 --> 00:11:48.655 Uh. What what Brendan was saying about like, if you were, like,
00:11:48.655 --> 00:11:51.238 stripping off some data to make the response smaller or
00:11:51.238 --> 00:11:53.960 something like that, then you could do that at the service
00:11:53.960 --> 00:11:56.912 layer. Or if you're changing the physical amount of information
00:11:56.912 --> 00:11:59.818 you're passing into a workflow, then you'd probably do service
00:11:59.818 --> 00:12:02.540 layer. And if you're just changing the output of it, you'd
00:12:02.540 --> 00:12:05.492 probably override the workflow and not touch the service layer.
00:12:06.722 --> 00:12:10.489 And then the last one, the mapping the map out hooks, you
00:12:10.489 --> 00:12:14.515 would only ever do this one if everything else is working and
00:12:14.515 --> 00:12:16.852 you just need something to map out.
00:12:18.192 --> 00:12:21.222 At a specific like mapping level that's not already there.
00:12:22.612 --> 00:12:24.122 That's like custom basically.
00:12:24.592 --> 00:12:29.933 Or you want to specifically make the the full the list or the the
00:12:24.782 --> 00:12:25.312 Umm.
00:12:29.933 --> 00:12:30.742 other one.
00:12:31.022 --> 00:12:34.192 I'm specifically different behavior.
00:12:35.292 --> 00:12:38.867 Yeah. And so a good example of this, hopefully a good example
00:12:38.867 --> 00:12:42.327 because it's the first one I found is the discount workflow
00:12:42.327 --> 00:12:45.959 has a map out hook and the way that you do this by the way you
00:12:45.959 --> 00:12:49.649 go into your, this was discount creed workflow dot extended dot
00:12:49.649 --> 00:12:49.822 CS.
00:12:51.432 --> 00:12:53.952 And you create a static constructor.
00:12:54.272 --> 00:12:55.452 Umm so.
00:12:56.362 --> 00:13:00.238 Where you do that is just the word static and then the class
00:13:00.238 --> 00:13:04.305 name, and then Brent sees. This runs only one time the the. The
00:13:04.305 --> 00:13:06.592 thing with Static Constructors Inc.
00:13:08.052 --> 00:13:10.688 And any static field initializers and anything like
00:13:10.688 --> 00:13:13.476 that is they all run the first time that this class is
00:13:13.476 --> 00:13:16.669 referenced by anything in the code, and they only ever run one
00:13:16.669 --> 00:13:19.558 time for any given application or in any given run of an
00:13:19.558 --> 00:13:22.548 application. If you restart it, then static stuff will run
00:13:22.548 --> 00:13:22.852 again.
00:13:23.482 --> 00:13:24.002 Uh.
00:13:25.012 --> 00:13:27.737 And if you're running API admin and API storefront, they're both
00:13:27.737 --> 00:13:29.959 going to run this once each because they're separate
00:13:29.959 --> 00:13:32.558 applications. But in a given run of an application, this will
00:13:32.558 --> 00:13:35.157 only ever run once, the first time discount workflows touched
00:13:35.157 --> 00:13:35.702 by something.
00:13:36.732 --> 00:13:40.611 Umm so this logic will run and it has this ensure map out hooks
00:13:40.611 --> 00:13:41.762 we go look at this.
00:13:43.162 --> 00:13:46.651 The mapping layer exposes this model mapper for and then the
00:13:46.651 --> 00:13:50.196 class like the entity type or the model type. So in this case
00:13:50.196 --> 00:13:53.742 discounts dot and then you have these hooks for list Lite and
00:13:53.742 --> 00:13:54.542 full mappings.
00:13:56.702 --> 00:14:01.084 The hook is basically a function object that receives the entity
00:14:01.084 --> 00:14:05.264 that you're mapping from the model you're mapping to, and the
00:14:05.264 --> 00:14:09.039 context profile name of the mapping. Just for unit test
00:14:09.039 --> 00:14:12.612 stuff, and it expects you to return the model and so
00:14:12.612 --> 00:14:16.388 specifically what we're doing here is we're mapping the
00:14:16.388 --> 00:14:20.230 discount type ID out, which I guess isn't isn't normally
00:14:20.230 --> 00:14:24.140 mapped out in the discount mapping layer. And then if the
00:14:24.140 --> 00:14:26.432 model doesn't already have codes.
00:14:26.532 --> 00:14:29.773 We're doing a custom way of mapping those out for discount
00:14:29.773 --> 00:14:30.102 codes.
00:14:32.422 --> 00:14:35.802 A more specific example would be something like a convenience
00:14:35.802 --> 00:14:36.292 property.
00:14:36.722 --> 00:14:37.452 UM.
00:14:38.702 --> 00:14:43.912 Which I might have actually done for a lots. Let me check.
00:14:44.762 --> 00:14:45.552 No, I didn't.
00:14:46.112 --> 00:14:49.149 Umm, but something that you might like. A good example for
00:14:49.149 --> 00:14:52.341 this for those of you that have worked on bid this this, this
00:14:52.341 --> 00:14:55.480 one will make sense to you guys if you wanted to map out the
00:14:55.480 --> 00:14:56.252 highest bidder.
00:14:57.082 --> 00:15:00.986 On a lot without having to go create a foreign key for it in
00:15:00.986 --> 00:15:04.890 the database and maintain it and update that foreign key and
00:15:04.890 --> 00:15:07.962 stuff. What you could do is you could create a.
00:15:08.062 --> 00:15:12.888 Uh, a highest bidder property just on the model, not on the
00:15:12.888 --> 00:15:17.392 database table and create a static constructor in here.
00:15:18.192 --> 00:15:21.357 Uh, we typically wrapped these in the Tri catch because there's
00:15:21.357 --> 00:15:24.373 something goes wrong inside a static static constructor like
00:15:24.373 --> 00:15:27.241 an exception gets thrown. There's there's no way to catch
00:15:27.241 --> 00:15:30.011 that, it just it just dies. So you wanna make sure that
00:15:30.011 --> 00:15:33.076 anything you're doing static constructors is wrapped in a try
00:15:33.076 --> 00:15:35.994 catch even if the catch does nothing. Although ideally the
00:15:35.994 --> 00:15:38.763 catch would be logging an error so that we can see that
00:15:38.763 --> 00:15:39.702 something happened.
00:15:41.542 --> 00:15:42.682 And then you can do.
00:15:43.482 --> 00:15:46.572 Model Mapper for lot dot.
00:15:47.232 --> 00:15:53.802 Great lot model from Indy Hooks. Uh let's say light and full.
00:15:54.772 --> 00:15:59.642 Entity model company profile name.
00:16:01.782 --> 00:16:05.303 And we have to return the model after we've made our changes and
00:16:05.303 --> 00:16:08.769 what we could do then is model dot highest bidder which doesn't
00:16:08.769 --> 00:16:11.965 actually exist. But I'm just making the point which entity
00:16:11.965 --> 00:16:12.452 dot bids.
00:16:13.502 --> 00:16:14.322 Uh.
00:16:15.542 --> 00:16:16.122 Dot.
00:16:16.402 --> 00:16:19.602 Uh order by descending.
00:16:20.982 --> 00:16:22.172 Current bid.
00:16:23.812 --> 00:16:27.172 Select the user off the bid.
00:16:28.392 --> 00:16:31.701 First or default, and then what? You'd probably actually rather
00:16:31.701 --> 00:16:33.872 than first see what you like that select.
00:16:35.252 --> 00:16:36.052 Uh.
00:16:36.962 --> 00:16:39.162 Was mapping methods are like really long names.
00:16:42.252 --> 00:16:44.162 And yeah, that's obviously going to playing there.
00:16:47.622 --> 00:16:50.992 Like first full user and map to user.
00:16:52.322 --> 00:16:54.002 Model or something like that.
00:16:55.152 --> 00:16:57.983 Umm, so it's obviously airing because this field doesn't exist
00:16:57.983 --> 00:17:00.904 and for some reason it's having a hard time finding this, but it
00:17:00.904 --> 00:17:01.892 doesn't really matter.
00:17:02.592 --> 00:17:03.142 Umm.
00:17:02.802 --> 00:17:06.851 It's because the mapper class isn't being used and they're
00:17:06.851 --> 00:17:07.262 using.
00:17:08.442 --> 00:17:10.522 I got. I think I have it here Mapper.
00:17:14.252 --> 00:17:14.742 Umm.
00:17:17.862 --> 00:17:19.202 OK, I'm not sure of that.
00:17:18.732 --> 00:17:21.012 Yeah, I don't. Yeah. Doesn't matter. You get the point.
00:17:21.292 --> 00:17:24.318 Umm, so this could be like a. This would be a user model on
00:17:24.318 --> 00:17:27.243 the on the output of the lot model and the highest bidder
00:17:27.243 --> 00:17:30.369 doesn't actually correspond to any data in the database. It's
00:17:30.369 --> 00:17:33.446 just a convenience property for the front end to use to just
00:17:33.446 --> 00:17:36.774 easily display who's the highest bidder for this lot without them
00:17:36.774 --> 00:17:39.951 having to call another endpoint to get to get that information
00:17:39.951 --> 00:17:42.825 or calculate it themselves by querying for all the bids.
00:17:42.825 --> 00:17:46.053 Whatever it is. This is just a nice way for the back end to say
00:17:46.053 --> 00:17:49.280 this is information. The front ends probably gonna use or need,
00:17:49.280 --> 00:17:50.742 so let's just give it to him.
00:17:51.722 --> 00:17:56.409 So that's the that is when you would use the map out hooks to
00:17:56.409 --> 00:17:58.072 customize an endpoint.
00:18:02.222 --> 00:18:02.752 And this is.
00:18:02.302 --> 00:18:05.632 And that's not so good. I'm just gonna say this.
00:18:03.532 --> 00:18:06.791 Sorry, go ahead. I was gonna say this is pretty rare that you're
00:18:06.791 --> 00:18:09.548 gonna do this most of the time you would. You would do
00:18:09.548 --> 00:18:12.456 customization on mapping with the attributes and the data
00:18:12.456 --> 00:18:14.812 model, which is covered in a nuclear document.
00:18:15.882 --> 00:18:19.184 Most of the time you wouldn't want to make a property like
00:18:19.184 --> 00:18:22.262 this because it's not indexed, so it would have to do.
00:18:22.382 --> 00:18:27.224 Uh, A scan over all of the bidders, which could take a
00:18:27.224 --> 00:18:31.272 while if there's a lot, but sometimes you do.
00:18:29.612 --> 00:18:30.192 Yeah.
00:18:37.662 --> 00:18:37.952 Cool.
00:18:38.642 --> 00:18:38.982 Thanks.
00:18:44.142 --> 00:18:46.112 I don't know if Richard, do you have your?
00:18:47.012 --> 00:18:48.302 You're being pulled up.
00:18:49.752 --> 00:18:52.962 Uh, my local got busted, so I don't think I'm gonna make much
00:18:52.962 --> 00:18:54.152 progress in 10 minutes.
00:18:54.822 --> 00:18:55.452 So it's fun.
00:18:56.862 --> 00:18:57.142 OK.
00:19:01.062 --> 00:19:04.280 Uh, and I had another question and again probably all the back
00:19:04.280 --> 00:19:06.272 enters in the room and know this, but.
00:19:08.422 --> 00:19:13.029 Well, how would you? When would you decide to put it in Ohh 9
00:19:13.029 --> 00:19:14.292 overrides versus?
00:19:15.002 --> 00:19:20.372 And override method and we're like the service order workflow.
00:19:20.602 --> 00:19:23.902 09 overrides is for client specific stuff.
00:19:20.952 --> 00:19:21.422 If it.
00:19:21.362 --> 00:19:21.782 Player.
00:19:24.992 --> 00:19:27.462 Uh, so if you're doing a customization that it's like.
00:19:25.832 --> 00:19:26.112 OK.
00:19:28.222 --> 00:19:31.538 You're if you're fixing like a core bug or this is something
00:19:31.538 --> 00:19:35.071 that you're like, yeah, this is. This is a core, a core specific
00:19:35.071 --> 00:19:38.495 thing, like core should always work this way for every client.
00:19:38.495 --> 00:19:40.342 Then you would do it at the core.
00:19:40.752 --> 00:19:44.817 That, like you know up in 05 workflow or in 06 services, but
00:19:44.817 --> 00:19:47.882 if it's like a very client specific endpoint.
00:19:49.782 --> 00:19:53.103 Then you just do it in like 09 overrides. If you're not sure,
00:19:53.103 --> 00:19:54.602 definitely feel free to ask.
00:19:55.822 --> 00:19:58.437 If you think that something might be worth bringing into
00:19:58.437 --> 00:20:01.144 core, it's better to. It's better to ask and us say now we
00:20:01.144 --> 00:20:03.988 probably won't need it. Then just assume we won't and then it
00:20:03.988 --> 00:20:06.052 makes it harder for us to bring it in later.
00:20:06.892 --> 00:20:07.092 OK.
00:20:07.092 --> 00:20:10.316 So if you're ever not sure, should this go in core? Should
00:20:10.316 --> 00:20:13.649 this be in an override the like a client override? Just feel
00:20:13.649 --> 00:20:17.146 free to ask like me or James or Eric and one of us can probably
00:20:17.146 --> 00:20:19.932 figure out if we want that or won't never need it.
00:20:21.102 --> 00:20:21.892 OK, cool.
00:20:30.992 --> 00:20:31.342 Hi.
00:20:33.682 --> 00:20:34.832 I've got a.
00:20:35.882 --> 00:20:37.132 Something very specific.
00:20:38.222 --> 00:20:42.032 It's nothing. Uh wide in the back end, but more.
00:20:42.832 --> 00:20:46.337 A question now that I have you in front of me, I guess I don't
00:20:46.042 --> 00:20:46.372 Sure.
00:20:46.337 --> 00:20:46.782 meeting.
00:20:49.422 --> 00:20:52.872 I have to be bid get to prove model.
00:20:54.102 --> 00:20:57.512 And they want to do credit cards per auction.
00:21:02.682 --> 00:21:05.302 So you'll have to accept your credit card.
00:21:06.582 --> 00:21:10.042 On auction one and then accept if you want to a different
00:21:10.042 --> 00:21:11.772 credit card on a auction too.
00:21:13.092 --> 00:21:15.462 How should I store?
00:21:17.372 --> 00:21:19.742 Which credit card the user has selected?
00:21:20.862 --> 00:21:23.832 And then identify that later.
00:21:25.732 --> 00:21:27.062 My question.
00:21:28.632 --> 00:21:31.835 My question there would be like obviously number one when it
00:21:31.835 --> 00:21:34.827 comes to storing any kind of like card data, we have the
00:21:34.827 --> 00:21:37.872 wallet table that would handle it's already handling like
00:21:37.872 --> 00:21:41.127 storing like a token of that wall and stuff so that we're not
00:21:41.127 --> 00:21:44.120 actually storing any card numbers or anything like that.
00:21:43.412 --> 00:21:44.032 Yeah.
00:21:44.120 --> 00:21:47.270 So it would be it would be related to something in the car,
00:21:47.270 --> 00:21:48.162 the wallet table.
00:21:50.242 --> 00:21:51.902 Yeah, I was thinking wallet ID.
00:21:50.542 --> 00:21:51.762 But my question would be.
00:21:52.602 --> 00:21:57.037 Uh, functionally, how are they? What is the UI like for that? Is
00:21:57.037 --> 00:21:59.492 it something where they're able to?
00:22:00.102 --> 00:22:04.953 Uh, like, like if I win three bids or if I win 3 auctions. Uh,
00:22:04.953 --> 00:22:09.573 am I going through and like after I win them saying I wanna
00:22:09.573 --> 00:22:14.424 pay for this one with my card number 1234 and this one with my
00:22:14.424 --> 00:22:19.429 card number. Yeah, 5678 and etc. Or is it a thing of like before
00:22:19.429 --> 00:22:24.048 I even bid? I have to say I'm bidding on this lot with card
00:22:24.048 --> 00:22:24.972 number 1234.
00:22:25.442 --> 00:22:25.852 That one.
00:22:26.432 --> 00:22:29.132 OK, I would say.
00:22:30.862 --> 00:22:34.478 If we haven't already, because if I remember correctly, there's
00:22:34.478 --> 00:22:38.150 something else with bid to where you have to like and I might be
00:22:38.150 --> 00:22:41.596 thinking of, I might be mixing up in TPG actually brand, but
00:22:41.596 --> 00:22:45.099 don't you have to like accept terms per lot to bid on them or
00:22:45.099 --> 00:22:47.132 something like that or is that TBG?
00:22:47.582 --> 00:22:51.626 Yes, that is bid I it might be them too, but yeah, bid does
00:22:49.032 --> 00:22:49.462 OK.
00:22:51.002 --> 00:22:54.928 OK, so bit as a thing where for every lot I want to bid on, I
00:22:51.626 --> 00:22:51.962 that.
00:22:54.928 --> 00:22:58.854 have to accept terms for that lot. What that sounds like then
00:22:58.854 --> 00:23:02.717 is what we we probably would want to create a lot user table
00:23:02.717 --> 00:23:06.452 if it doesn't already exist and that lot user table would.
00:23:07.692 --> 00:23:10.833 Would Mark if if a record exists in that table, it means that
00:23:10.833 --> 00:23:14.075 that user has accepted the terms for that lot and that lot user
00:23:14.075 --> 00:23:17.266 table would also have the wallet ID they chose to pay for that
00:23:17.266 --> 00:23:18.532 lot with should they win.
00:23:19.342 --> 00:23:23.524 Umm, that way we're kind of two birds, one stoning the accepting
00:23:23.524 --> 00:23:27.320 terms and the storing the storing the wallet ID they chose
00:23:27.320 --> 00:23:28.092 to pay with.
00:23:29.692 --> 00:23:31.702 Or sharks OK.
00:23:31.252 --> 00:23:35.522 Is there already a table for that for who owns the lot?
00:23:37.822 --> 00:23:41.076 That would be the the lots have an auction ID and then the
00:23:41.076 --> 00:23:44.441 auction has like auction account or or like an account ID or
00:23:44.441 --> 00:23:47.915 something and that's that's who created the account or the the
00:23:46.772 --> 00:23:47.242 OK.
00:23:47.915 --> 00:23:50.562 auctions. Sorry but yeah we can go look at the.
00:23:51.952 --> 00:23:52.622 One moment.
00:23:59.182 --> 00:24:02.635 It QA and go see exactly what kind of models we have in there
00:24:02.635 --> 00:24:03.192 right now.
00:24:05.382 --> 00:24:07.202 Auction is what I'm looking for.
00:24:08.002 --> 00:24:11.926 And we don't appear to already have a lot user table or lot
00:24:11.926 --> 00:24:15.850 account which is good. That means that we're not gonna step
00:24:15.850 --> 00:24:17.092 on anything's toes.
00:24:17.942 --> 00:24:23.147 Umm. So yeah basically then what we would want to do is we would
00:24:23.147 --> 00:24:28.351 have the lot user table and that would have the lot ID, the user
00:24:28.351 --> 00:24:30.032 ID and the wallet ID.
00:24:31.952 --> 00:24:36.957 And that table the existence of a record that matches a given
00:24:36.957 --> 00:24:41.880 lot and user implies that that user accepted those terms, or
00:24:41.880 --> 00:24:44.382 the terms for that lot and the.
00:24:44.822 --> 00:24:48.893 Umm, the wallet 80 would be the wallet they chose to pay with,
00:24:48.893 --> 00:24:52.770 and then once all is said and done you could query for that
00:24:52.770 --> 00:24:53.222 lot ID.
00:24:55.462 --> 00:24:58.615 Let's see, I want to be kind of janky because I'm gonna type it
00:24:58.615 --> 00:25:00.732 in notepad, but you'd query for that with.
00:25:01.552 --> 00:25:02.232 Uh.
00:25:05.072 --> 00:25:08.425 You would find the lot winner, so we would assume you already
00:25:08.425 --> 00:25:09.182 have like bar.
00:25:10.262 --> 00:25:12.132 When our user ID equals.
00:25:13.752 --> 00:25:14.842 Figure out who won.
00:25:15.792 --> 00:25:19.550 Somehow, right. And then so assume you already have that you
00:25:19.550 --> 00:25:20.782 go into a lot users.
00:25:21.522 --> 00:25:25.600 Uh filter by. This is probably the relationship table. She's
00:25:25.600 --> 00:25:28.942 like filter by master ID. The master ID would be.
00:25:29.462 --> 00:25:35.118 Umm the lot ID, so the lot that was one built by slave ID which
00:25:35.118 --> 00:25:37.592 would be the winner user ID.
00:25:38.592 --> 00:25:40.022 Uh, select.
00:25:40.952 --> 00:25:44.545 Like start wallet ID. Or you could just like the entire
00:25:44.545 --> 00:25:47.432 wallet if you needed to, but I'd dot single.
00:25:49.092 --> 00:25:52.704 And that would be the wallet ID of the the wallet ID. The
00:25:52.704 --> 00:25:56.502 winning user chose to pay for this lot should they win. That
00:25:56.502 --> 00:26:00.425 would be the way back in, like using the database context. How
00:26:00.425 --> 00:26:02.292 you would find that wallet ID.
00:26:03.112 --> 00:26:06.002 Umm. As you'd find a lot user record that matches the lot and
00:26:06.002 --> 00:26:08.332 the user and then grab their wallet ID off of it.
00:26:08.922 --> 00:26:12.642 Yeah, that has to happen during the payment step then.
00:26:14.792 --> 00:26:18.364 Yes, I would assume so. And I believe if I remember, bid has a
00:26:18.364 --> 00:26:21.708 task on the back end that handles like auto payment. So it
00:26:21.708 --> 00:26:24.882 would just all that whatever that auto payment logic is
00:26:24.882 --> 00:26:25.222 doing.
00:26:26.182 --> 00:26:28.938 It would just use this to determine what wallet ID to pass
00:26:28.938 --> 00:26:30.152 into the payment provider.
00:26:32.732 --> 00:26:33.662 Awesome sauce dude.
00:26:38.962 --> 00:26:41.887 Cool. Well, we're just about at time. If anybody else has any
00:26:41.887 --> 00:26:44.623 quick questions, we can go through those or we can drop a
00:26:44.623 --> 00:26:45.472 few minutes early.
00:26:51.722 --> 00:26:53.442 Cool. Sounds like we're all.
00:26:54.362 --> 00:26:55.712 Sounds like we're all good.
00:26:57.472 --> 00:27:00.422 In that case, you'll have a good weekend.
00:27:01.172 --> 00:27:05.135 And I will see you all next week or some of you, some of you are
00:27:05.135 --> 00:27:08.915 going to be off all next week, in which case have a fantastic
00:27:08.915 --> 00:27:10.012 vacation time off.
00:27:11.172 --> 00:27:12.502 And see you.
00:27:12.262 --> 00:27:12.752 You're here.
00:27:13.242 --> 00:27:15.262 See you in two weeks or week and 1/2.
00:27:14.522 --> 00:27:15.242 Happy Friday.
00:27:18.342 --> 00:27:19.522 Yeah, guys have a good.
00:27:18.682 --> 00:27:19.432 Thanks Brandon.
00:27:18.752 --> 00:27:19.362 Thanks bill.
00:27:19.242 --> 00:27:21.132 I guess hope you have a great weekend.
00:27:20.022 --> 00:27:21.052 Yeah. Thank you, man.
00:27:21.412 --> 00:27:23.432 Yeah. Thanks, Brendan, that was awesome.
00:27:21.592 --> 00:27:21.992 No problem.
00:27:21.772 --> 00:27:22.082 Oil.
00:27:24.202 --> 00:27:24.682 Yep.
00:27:25.662 --> 00:27:27.802 Thank you. Thank you. Happy Friday all.
00:27:25.732 --> 00:27:26.252 Thanks guys.
00:27:25.812 --> 00:27:26.272 Chow.
00:27:28.932 --> 00:27:29.702 Have a great weekend.
00:27:29.072 --> 00:27:30.222 Happy Friday doodles.