00:00:07.213 --> 00:00:07.923 I can give it a shot.
00:00:09.483 --> 00:00:09.893 Yeah.
00:00:09.783 --> 00:00:11.723 Sorry and and what's the?
00:00:09.903 --> 00:00:11.883 So real quick to request for the recording.
00:00:11.733 --> 00:00:11.883 Yeah.
00:00:11.893 --> 00:00:13.223 What's the question? Yeah.
00:00:13.313 --> 00:00:17.533 Yeah, we're gonna talk about client override projects today.
00:00:18.073 --> 00:00:20.983 We are gonna talk about using them in Seth.
00:00:20.993 --> 00:00:21.983 Why we use them?
00:00:22.773 --> 00:00:28.130 The first question was posed was why do we separate out client
00:00:28.130 --> 00:00:33.742 specific business logic from our core business logic when we have
00:00:33.742 --> 00:00:38.248 a client project that is branched off from a release
00:00:38.248 --> 00:00:38.843 branch?
00:00:39.763 --> 00:00:42.717 What is the purpose of keeping the client specific logic
00:00:42.717 --> 00:00:44.323 separated in a client override?
00:00:45.293 --> 00:00:48.143 Uh, and I think TMK is going to take a shot.
00:00:50.263 --> 00:00:57.550 My assumption is that when we have client specific logic or
00:00:57.550 --> 00:00:58.643 features.
00:00:59.013 --> 00:01:02.695 Uh, the reason for that is that it's not usually when we do
00:01:02.695 --> 00:01:03.983 these customizations.
00:01:05.473 --> 00:01:09.398 Uh, generally speaking, they're not necessarily applicable to
00:01:09.398 --> 00:01:10.473 our core product.
00:01:11.463 --> 00:01:15.019 Umm, So what I mean by that is if someone wants some very
00:01:15.019 --> 00:01:18.206 specific logic or a very specific implementation of
00:01:18.206 --> 00:01:22.068 something, the reason why we do an override is so that when we
00:01:22.068 --> 00:01:25.685 tweak other things with the project that do pertain to our
00:01:25.685 --> 00:01:29.424 core products that are you know, market improvements, we can
00:01:29.424 --> 00:01:33.286 still pull those back in cleanly without pulling it a bunch of
00:01:33.286 --> 00:01:33.653 logic.
00:01:33.663 --> 00:01:35.003 We don't want to pull back in.
00:01:35.473 --> 00:01:39.518 It also just helps us, you know, even in terms of development
00:01:39.518 --> 00:01:43.497 perspective for me being able to see you know the core logic
00:01:43.497 --> 00:01:46.824 that's you know relatively untouched or maybe just
00:01:46.824 --> 00:01:50.542 untouched with fixes and then having the client specific
00:01:50.542 --> 00:01:54.848 overrides on top of that it it's it just makes development easier
00:01:54.848 --> 00:01:58.958 because you know there there's a reason we use object oriented
00:01:58.958 --> 00:02:02.023 programming and we override methods and stuff.
00:02:02.033 --> 00:02:04.263 It just makes things easier to manage.
00:02:04.613 --> 00:02:07.533 And yeah, I don't know.
00:02:08.003 --> 00:02:10.763 I I I'm sure there's more reasons than that, but.
00:02:08.943 --> 00:02:11.193 There's yeah.
00:02:11.253 --> 00:02:15.963 Yeah, that, that's that is a a a good initial reason for it.
00:02:15.973 --> 00:02:19.873 And then there are other reasons that are less intentional but
00:02:19.873 --> 00:02:23.772 more functional, if that makes sense, because ultimately a lot
00:02:23.413 --> 00:02:23.653 Umm.
00:02:23.772 --> 00:02:27.424 of what we do for client work does actually come back into
00:02:27.424 --> 00:02:27.733 core.
00:02:28.333 --> 00:02:28.943 Umm.
00:02:29.723 --> 00:02:33.954 And that being the case, theoretically, having all of the
00:02:33.954 --> 00:02:38.039 client customization and overrides makes upgrading that
00:02:38.039 --> 00:02:39.133 project easier.
00:02:39.623 --> 00:02:42.859 Should a client desire to move to a new version, or should that
00:02:42.859 --> 00:02:45.993 just become something that we have to do for a client for one
00:02:45.883 --> 00:02:46.073 Umm.
00:02:45.993 --> 00:02:46.903 reason or another?
00:02:47.583 --> 00:02:48.223 Umm.
00:02:48.763 --> 00:02:53.860 And additionally, a side benefit of it is if all of your back end
00:02:53.860 --> 00:02:58.803 code lives in an override, the iteration speed is significantly
00:02:58.803 --> 00:02:59.343 higher.
00:03:00.073 --> 00:03:04.596 Umm, since the since your client override project should not be
00:03:04.596 --> 00:03:08.977 referenced by anything else in core, then when you're working
00:03:08.977 --> 00:03:13.075 on your site you can make changes to that client override
00:03:13.075 --> 00:03:17.103 and only build the client override and that works 99% of
00:03:17.103 --> 00:03:21.201 the time and building your client override takes you know
00:03:21.201 --> 00:03:25.653 depending on your CPU anywhere from 1/4 of a second to maybe a
00:03:25.653 --> 00:03:29.610 full second, whereas building the entire solution takes
00:03:29.610 --> 00:03:33.991 anywhere from a minute and 1/2 to 3 minutes depending on your
00:03:33.991 --> 00:03:34.273 CPU.
00:03:34.283 --> 00:03:39.435 So umm it it's significantly faster to keep that code in the
00:03:39.435 --> 00:03:45.009 override so that you can iterate and test and make adjustments as
00:03:45.009 --> 00:03:50.413 fast as possible and make life make life for yourself and other
00:03:50.413 --> 00:03:51.933 developers easier.
00:03:55.913 --> 00:03:59.373 Yeah, that all makes sense to me.
00:03:59.383 --> 00:04:00.983 James, is there anything you want to add?
00:04:08.233 --> 00:04:09.003 OK.
00:04:09.893 --> 00:04:10.364 I E.
00:04:09.893 --> 00:04:11.643 So hi.
00:04:12.493 --> 00:04:15.283 Umm, go ahead.
00:04:14.503 --> 00:04:16.443 He he he is correct.
00:04:17.443 --> 00:04:21.768 Umm while working it is faster while doing a the the stop it,
00:04:21.768 --> 00:04:26.023 it's easily identifiable but things are being changed if you
00:04:26.023 --> 00:04:30.348 have to pull another like you don't update from core not just
00:04:30.348 --> 00:04:34.882 to upgrade to a new version but in the same version as fixes get
00:04:34.882 --> 00:04:37.323 posted to the core release branch.
00:04:38.053 --> 00:04:42.927 Umm, everyone who's on that release should be able to pull
00:04:42.927 --> 00:04:47.801 in those things to their client projects with little to no
00:04:47.801 --> 00:04:49.783 effort is part of the I.
00:04:54.313 --> 00:04:57.688 One second, I have to be able to pull those in and then and
00:04:57.688 --> 00:05:01.231 basically that those things that are happening to that release
00:05:01.231 --> 00:05:04.886 branch should only be hot fixes and known like a new features or
00:05:04.886 --> 00:05:07.473 rearrangements of code or anything like that.
00:05:07.903 --> 00:05:11.628 Because of the way that the release structure is, so it
00:05:11.628 --> 00:05:15.752 should be safe to pull in core release updates into there and
00:05:15.752 --> 00:05:19.143 then the only thing you would need to necessarily.
00:05:20.603 --> 00:05:24.878 Modify in the override would be to double check that there isn't
00:05:24.878 --> 00:05:25.733 some new bug.
00:05:25.743 --> 00:05:28.405 Fix that might have happened in code that you're currently
00:05:28.405 --> 00:05:31.202 overwriting, that you might need to copy that bug fix over to
00:05:31.202 --> 00:05:31.833 your override.
00:05:31.923 --> 00:05:36.060 But since you know where all your overridden stuff is and
00:05:36.060 --> 00:05:40.409 exactly what it's overriding, it's easy to go check the base
00:05:40.409 --> 00:05:44.332 function or check the base property of whatever you've
00:05:44.332 --> 00:05:48.753 overridden and just double check it real fast to that kind of
00:05:48.753 --> 00:05:53.032 stuff and and then you know later on when it's time to pull
00:05:53.032 --> 00:05:55.313 the customizations down to core.
00:05:56.753 --> 00:06:00.101 A lot of what can be done with that kind of code would be ohh
00:06:00.101 --> 00:06:03.341 this is something I can put behind a a setting and you know
00:06:03.341 --> 00:06:06.743 because it modifies some data about the quote record that gets
00:06:06.743 --> 00:06:10.253 created whenever you're doing a quote, whatever The thing is, we
00:06:10.253 --> 00:06:13.601 could hide it behind a setting and then that will just become
00:06:13.601 --> 00:06:14.303 part of core.
00:06:14.353 --> 00:06:15.963 I'll copy the code out of your override.
00:06:15.973 --> 00:06:17.323 Put it down into the lower level.
00:06:17.553 --> 00:06:19.883 I'll add some settings that it relevant around it.
00:06:20.473 --> 00:06:23.557 We'll do the testing and then now we just have a core feature
00:06:23.557 --> 00:06:26.243 that is now optional and can be turned on with enter.
00:06:26.253 --> 00:06:30.161 A specific scenario to do the thing that you need to do, or it
00:06:30.161 --> 00:06:34.006 might be that this this whole feature needs to get get pulled
00:06:34.006 --> 00:06:37.727 down because it was a whole thing that we thought was gonna
00:06:37.727 --> 00:06:38.843 be unique to that.
00:06:39.783 --> 00:06:41.273 Uh to that client?
00:06:41.443 --> 00:06:44.588 We found out another client came in and said hey, I want roughly
00:06:44.588 --> 00:06:45.313 the same thing.
00:06:45.483 --> 00:06:48.541 And so now we have a proof of concept all fully functional and
00:06:48.541 --> 00:06:51.404 all gathered together over in this one override that I can
00:06:51.404 --> 00:06:54.413 then spread out where it needs to throughout the architecture
00:06:54.413 --> 00:06:55.723 of the rest of the project.
00:06:56.293 --> 00:06:56.903 Umm.
00:06:57.333 --> 00:07:00.023 A core for all that stuff.
00:07:00.033 --> 00:07:02.403 So you're right in both cases.
00:07:04.203 --> 00:07:04.433 Yeah.
00:07:04.443 --> 00:07:07.529 And I think that was an excellent expansion on it too,
00:07:07.529 --> 00:07:11.007 especially the, you know, if it's in logic that even we don't
00:07:11.007 --> 00:07:14.317 want to bring back into core, it's still wrapped up in one
00:07:14.317 --> 00:07:14.653 place.
00:07:14.663 --> 00:07:18.810 So when we come across the next project that once the same or
00:07:18.810 --> 00:07:22.956 similar logic we have one place to go get it right, you don't
00:07:22.956 --> 00:07:27.370 have to dig around in the entire set back end in different places
00:07:27.370 --> 00:07:28.573 to find it, right?
00:07:28.583 --> 00:07:30.423 Like it's gonna be in the override.
00:07:31.143 --> 00:07:35.662 Umm, so I think those are all excellent reasons to to
00:07:35.662 --> 00:07:40.013 modularize client specific code into a an override.
00:07:40.103 --> 00:07:44.402 Now the thing that I've noticed since I started here is
00:07:44.402 --> 00:07:48.932 depending on you know which things progressive change over
00:07:48.932 --> 00:07:53.461 time, but depending on what project you bounce between the
00:07:53.461 --> 00:07:58.220 structure and the layout of the client override, projects can
00:07:58.220 --> 00:08:03.133 vary greatly, even down to the naming conventions of the files.
00:08:03.453 --> 00:08:07.032 And this is even with current projects that we have in
00:08:07.032 --> 00:08:11.066 development right now, you could get on ITV C pulled up right
00:08:11.066 --> 00:08:14.904 here and this is the one I'm going to use as my face model
00:08:14.904 --> 00:08:19.003 for the standard that I want us to try to implement government
00:08:19.003 --> 00:08:19.523 forward.
00:08:19.533 --> 00:08:24.558 But you can look at PBC's client override here and hop over to
00:08:24.558 --> 00:08:29.105 10/2 active projects started about the same time and the
00:08:29.105 --> 00:08:33.970 layout and structure of their client overrides is completely
00:08:33.970 --> 00:08:36.283 different naming conventions.
00:08:36.553 --> 00:08:40.308 Just certain things are put in different places and that is
00:08:40.308 --> 00:08:44.000 something that I want to try to standardize for so that no
00:08:44.000 --> 00:08:48.005 matter what project we have to balance between as developers we
00:08:48.005 --> 00:08:51.822 know what to expect, we know what we're looking for, we know
00:08:51.822 --> 00:08:53.323 where to go and find it.
00:08:53.613 --> 00:08:54.113 Umm.
00:08:54.693 --> 00:08:55.753 And things like that.
00:08:55.763 --> 00:08:59.526 I think that we should have in all things a standard of how to
00:08:59.526 --> 00:09:00.123 do things.
00:09:00.133 --> 00:09:03.019 In most places we do, but I think this is one that's been
00:09:03.019 --> 00:09:04.163 overlooked for a while.
00:09:04.173 --> 00:09:07.688 It's kind of surprising and I'm sure that the you know, that
00:09:07.688 --> 00:09:11.433 maybe attempts have been made in the past, the standardized this
00:09:11.433 --> 00:09:14.832 and it didn't catch on or you know it's kind of put to the
00:09:13.963 --> 00:09:19.913 I think, yeah, I think most of it is not necessarily it.
00:09:14.832 --> 00:09:15.523 back burner.
00:09:20.483 --> 00:09:24.448 A lot of it is is honestly that using them correctly and using
00:09:24.448 --> 00:09:28.286 them well has only really been a thing in the last couple of
00:09:28.286 --> 00:09:28.663 years.
00:09:28.673 --> 00:09:32.316 They've been sort of sparingly used for small stuff in the
00:09:32.316 --> 00:09:36.143 past, but it feels like it feels like over the last couple of
00:09:36.143 --> 00:09:36.513 years.
00:09:36.523 --> 00:09:39.542 It's really ramped up in usage and gotten to a point where a
00:09:39.542 --> 00:09:42.510 lot of client customization lives in an override to a point
00:09:42.510 --> 00:09:44.093 where organization is necessary.
00:09:44.103 --> 00:09:47.500 And we've just never really had that much so much code in these
00:09:47.500 --> 00:09:50.791 that we needed to figure out a strategy, but we definitely do
00:09:50.791 --> 00:09:51.003 now.
00:09:52.393 --> 00:09:53.803 Yeah, and that's a good point too.
00:09:53.813 --> 00:09:59.973 When I started about a year ago, it wasn't even really enforced.
00:09:59.983 --> 00:10:03.319 At the time it was trying to be, James was trying to make it
00:10:03.319 --> 00:10:06.216 enforced that we separated client code out and I had
00:10:06.216 --> 00:10:09.552 several PR's go up and they're over the months it changed to
00:10:09.552 --> 00:10:13.105 where, like, hey, this needs to be moved into a client override,
00:10:13.105 --> 00:10:13.433 right?
00:10:13.603 --> 00:10:14.033 Right.
00:10:14.043 --> 00:10:16.053 Like this does not need to be in court logic.
00:10:15.293 --> 00:10:15.543 Umm.
00:10:16.063 --> 00:10:19.197 If you look at Tasco, there's a ton of stuff that should have
00:10:19.197 --> 00:10:20.713 been done in overrides, right?
00:10:20.723 --> 00:10:24.796 But it's it's all brought into core or well into the core on
00:10:24.796 --> 00:10:25.663 that project.
00:10:26.083 --> 00:10:30.515 Umm, but I think AI structure will will help us because we are
00:10:30.515 --> 00:10:34.876 getting to the point where we are putting quite a bit of code
00:10:34.876 --> 00:10:36.493 into a client override.
00:10:36.503 --> 00:10:39.493 It's now it's as we should be here.
00:10:39.623 --> 00:10:44.356 So after a little bit of communication that you guys have
00:10:44.356 --> 00:10:45.743 about the layout?
00:10:46.143 --> 00:10:51.563 Umm this is what I wanna kinda try to start going for going
00:10:51.563 --> 00:10:57.343 forward as in layout and naming conventions of files and how we
00:10:57.343 --> 00:11:02.853 separate out things in the in the override project itself so
00:11:02.853 --> 00:11:08.362 you know when we create a new override the the naming of the
00:11:08.362 --> 00:11:13.782 project needs to be clarity dot clients dot project acronym
00:11:13.782 --> 00:11:14.323 right?
00:11:14.573 --> 00:11:16.113 So that is pretty universal.
00:11:16.123 --> 00:11:17.903 That's that's on all of them.
00:11:18.193 --> 00:11:19.543 But that just for the recording.
00:11:19.553 --> 00:11:22.553 That is what the project needs to be named.
00:11:22.613 --> 00:11:26.840 This will live in the 09 overrides folder and then going
00:11:26.840 --> 00:11:31.141 forward from there every override needs a registry and it
00:11:31.141 --> 00:11:33.143 needs most likely a config.
00:11:33.153 --> 00:11:36.486 Some of them may not need a config file, but the registry
00:11:36.486 --> 00:11:37.003 for sure.
00:11:37.013 --> 00:11:41.621 It will require the registry needs to be placed at the base
00:11:41.621 --> 00:11:43.233 level of the project.
00:11:43.903 --> 00:11:51.892 The root of the project and this is going to be where we define
00:11:51.892 --> 00:11:54.513 our workflows, right?
00:11:54.523 --> 00:11:56.853 This is where we're going to register our workflows for the.
00:11:58.413 --> 00:12:00.383 Dependency inject right?
00:12:01.173 --> 00:12:07.233 How we utilize the Prince injection as set as we register
00:12:07.233 --> 00:12:10.993 our concretes to a registry, right?
00:12:11.533 --> 00:12:16.252 This Is Us registering each overridden workflow to our
00:12:16.252 --> 00:12:18.053 dependency container.
00:12:18.703 --> 00:12:24.023 The real quick while we're on this topic, Umm.
00:12:20.533 --> 00:12:20.733 Sure.
00:12:25.313 --> 00:12:29.988 Can anybody explain why we use dependency injection and
00:12:29.988 --> 00:12:33.243 mechanically what it's actually doing?
00:12:38.173 --> 00:12:42.816 So it dependency injection is so that we can have multiple like
00:12:42.816 --> 00:12:47.458 overall the in the broad sense dependency injections so that we
00:12:47.458 --> 00:12:51.448 can have multiple concrete implementations of the same
00:12:51.448 --> 00:12:56.090 interface and at runtime decide what concrete implementation we
00:12:56.090 --> 00:12:57.323 wanna use, right?
00:12:58.943 --> 00:13:01.453 That's 95% correct.
00:13:02.583 --> 00:13:08.413 The the most basic answer to what we're using this for is to.
00:13:09.713 --> 00:13:14.542 And more or less dynamically determine which concrete to use
00:13:14.542 --> 00:13:16.283 for a given interface.
00:13:16.923 --> 00:13:20.135 And like you alluded to, it could also be which concretes
00:13:20.135 --> 00:13:22.183 plural to use for a given interface.
00:13:22.193 --> 00:13:23.583 For example, which shipping providers?
00:13:24.373 --> 00:13:28.117 What that does for us is it makes the rest of the code more
00:13:28.117 --> 00:13:32.173 nimble because we don't have to write code that knows to go call
00:13:32.173 --> 00:13:35.043 ups and knows to go call FedEx and et cetera.
00:13:35.433 --> 00:13:39.418 It can just call the shipping providers generally by using the
00:13:39.418 --> 00:13:43.466 interface and we can rely on our dependency injection system to
00:13:43.466 --> 00:13:47.388 tell us or to determine for us in those places which ones are
00:13:47.388 --> 00:13:50.993 enabled by whatever logic we want to use to enable them.
00:13:51.563 --> 00:13:53.473 And this four and use syntax.
00:13:53.483 --> 00:13:56.929 That's the structure map specific I'm set up there, but
00:13:56.929 --> 00:14:00.804 what we're doing there is we're telling it that when something
00:14:00.804 --> 00:14:04.495 asks for eye product workflow, the concrete we want to give
00:14:04.495 --> 00:14:05.233 back is PBC.
00:14:05.243 --> 00:14:06.133 Product workflow.
00:14:06.983 --> 00:14:09.963 So this is literally mapping an interface to a concrete.
00:14:10.823 --> 00:14:13.743 Umm, so that's that's the.
00:14:13.503 --> 00:14:17.439 And because this is in the client project which is which
00:14:17.439 --> 00:14:21.582 it's registry is loaded last, it's things win over the fact
00:14:21.582 --> 00:14:25.794 the original product workflow that was in the business logic
00:14:25.794 --> 00:14:30.075 workflows project, this one is going to win and take over the
00:14:30.075 --> 00:14:34.217 position of where the original concrete was doing it, which
00:14:34.217 --> 00:14:37.393 allows you to have that dynamically injected.
00:14:37.403 --> 00:14:40.645 So that no matter where else in the code that was looking for a
00:14:40.645 --> 00:14:43.633 product workflow, it's not gonna get this PBC one instead.
00:14:45.173 --> 00:14:45.433 Umm.
00:14:47.533 --> 00:14:49.063 Yeah. Umm.
00:14:52.233 --> 00:14:59.202 So yeah, every client override needs to position their registry
00:14:59.202 --> 00:15:03.883 at the root of the client over at project.
00:15:04.013 --> 00:15:08.271 Now when it comes to naming conventions, I think that this
00:15:08.271 --> 00:15:10.003 naming convention works.
00:15:10.103 --> 00:15:15.188 I think it is the most obvious for our pattern of naming
00:15:15.188 --> 00:15:17.953 conventions, so we're going to.
00:15:19.533 --> 00:15:23.997 Prefix the name of each file with the client acronym so PBC
00:15:23.997 --> 00:15:28.684 Registry PBC config and this is gonna be the same pattern that
00:15:28.684 --> 00:15:33.296 we use throughout the name even of all the different files in
00:15:33.296 --> 00:15:34.263 the override.
00:15:35.693 --> 00:15:39.363 So the registry's gonna live in the root level of the project,
00:15:39.363 --> 00:15:40.353 as is the config.
00:15:40.363 --> 00:15:45.455 The confidence is going to hold any app settings that are
00:15:45.455 --> 00:15:48.263 specific to the client override.
00:15:50.213 --> 00:15:55.153 Umm Logic project with somebody say something.
00:15:58.003 --> 00:16:00.713 Ohk OK, I the my Kelly and that's overseeing that's.
00:16:00.923 --> 00:16:04.669 But yeah, so this will hold any app settings that are specific
00:16:04.669 --> 00:16:08.118 to the logic that is contained within the client override
00:16:08.118 --> 00:16:08.593 project.
00:16:09.443 --> 00:16:15.697 It will live at the root of the project as well, and then from
00:16:15.697 --> 00:16:17.483 there I prefer to.
00:16:18.223 --> 00:16:23.793 Organize our different services or a different layers rather in
00:16:23.793 --> 00:16:29.276 folders we'll have a folder that has models, a folder that has
00:16:29.276 --> 00:16:30.233 interfaces.
00:16:30.243 --> 00:16:35.892 These can contain dtos that are used for endpoints or for
00:16:35.892 --> 00:16:41.931 returns to the front end, but they'll live in a folder called
00:16:41.931 --> 00:16:47.872 models and again they'll be prefixed with the client acronym
00:16:47.872 --> 00:16:51.183 at the beginning of the file now.
00:16:53.513 --> 00:16:57.071 We'll start with workflows or I guess we could start with
00:16:57.071 --> 00:16:57.623 services.
00:16:57.683 --> 00:17:02.797 So inside the services folder there will be a PBC service or
00:17:02.797 --> 00:17:08.245 client acronym service file and this file will be used to define
00:17:08.245 --> 00:17:10.173 the getters for the uh.
00:17:10.603 --> 00:17:12.313 So this one doesn't have the changes.
00:17:12.923 --> 00:17:17.996 This one will be used to define the getters for the workflows
00:17:17.996 --> 00:17:20.613 after the workflows are defined.
00:17:21.993 --> 00:17:26.351 So once we create a new workflow, we need to register
00:17:26.351 --> 00:17:31.515 that workflow in the workflow or in the client registry and the
00:17:31.515 --> 00:17:33.613 overhead project registry.
00:17:33.993 --> 00:17:38.281 And then we also need to define a getter so that we're not
00:17:38.281 --> 00:17:42.859 newing up an instance of that workflow every time that we need
00:17:42.859 --> 00:17:44.893 it, or any of the workflows.
00:17:44.273 --> 00:17:48.580 Uh, one piece you were missing in that regard is if you go back
00:17:48.383 --> 00:17:48.623 Sure.
00:17:48.580 --> 00:17:49.993 over to the registry.
00:17:50.863 --> 00:17:51.063 Yep.
00:17:53.693 --> 00:17:58.743 Uh, before the use, put a dot? Umm.
00:18:00.273 --> 00:18:04.323 Uh, it's it's life cycle.
00:18:04.333 --> 00:18:07.553 I care which way it's called it a Singleton.
00:18:05.853 --> 00:18:08.013 Oh, yeah, right here.
00:18:07.193 --> 00:18:07.963 I think you.
00:18:08.143 --> 00:18:13.273 Yeah, you can also pass the life cycle thing into the uh, you can
00:18:10.783 --> 00:18:11.443 Yes, Singleton.
00:18:13.273 --> 00:18:17.703 like do new Singleton lifecycle inside the four I think.
00:18:19.523 --> 00:18:19.763 Right.
00:18:19.543 --> 00:18:20.163 Right here.
00:18:21.033 --> 00:18:23.593 To the yeah, I think it's like new Singleton life cycle.
00:18:27.103 --> 00:18:27.403 Yeah.
00:18:27.473 --> 00:18:30.523 And that's gonna define this as a Singleton, correct?
00:18:30.483 --> 00:18:31.453 Yep, yeah.
00:18:30.923 --> 00:18:34.437 Yeah, so, so we all knew it up in memory ones and then it will
00:18:32.393 --> 00:18:32.783 It's fine.
00:18:34.437 --> 00:18:36.333 always return that same instance.
00:18:37.543 --> 00:18:37.733 Yep.
00:18:37.693 --> 00:18:39.533 Kind of like a static instance of it.
00:18:40.063 --> 00:18:40.613 Yes.
00:18:40.583 --> 00:18:40.783 Yeah.
00:18:40.943 --> 00:18:41.143 Yep.
00:18:42.993 --> 00:18:47.620 Yeah, in generally speaking with most dependency injection
00:18:47.620 --> 00:18:52.638 services, there are three life cycles for something that's read
00:18:52.638 --> 00:18:55.303 out in practice with with cefaly.
00:18:53.473 --> 00:18:53.603 Yeah.
00:18:55.313 --> 00:18:59.840 Generally, we generally just use 2 umm and the two that we
00:18:59.840 --> 00:19:04.519 typically use are transient and Singleton singletons like we
00:19:04.519 --> 00:19:05.823 were just saying.
00:19:05.833 --> 00:19:09.764 Those are there's only one copy of that in memory at any given
00:19:09.764 --> 00:19:13.695 time, and any time you ask for that interface, you're going to
00:19:13.695 --> 00:19:17.750 get the same implementation back every time the same instance of
00:19:17.750 --> 00:19:19.933 that implementation, I should say.
00:19:21.773 --> 00:19:24.362 So that's got the best performance and memory
00:19:24.362 --> 00:19:27.738 characteristics, but it also it's a Singleton, it shares it
00:19:27.738 --> 00:19:29.763 shares the same instance over time.
00:19:29.773 --> 00:19:32.550 So if you need it to be unique each time, you wouldn't want a
00:19:32.550 --> 00:19:32.863 single.
00:19:33.433 --> 00:19:35.913 The other one that we typically use is transient.
00:19:33.513 --> 00:19:35.303 And the the all.
00:19:35.313 --> 00:19:37.473 I one more thing to the Singleton thing.
00:19:37.773 --> 00:19:41.806 The reason that we are allowing Singleton in these cases is
00:19:41.806 --> 00:19:45.436 because with interfaces like workflows, the workflows
00:19:45.436 --> 00:19:48.863 themselves never contain any stateful information.
00:19:49.293 --> 00:19:52.793 They are all meant to be black box processors.
00:19:52.803 --> 00:19:54.923 You call a function, you get a result.
00:19:55.293 --> 00:19:58.463 It never stores any information in memory or anything.
00:19:58.853 --> 00:20:01.387 When you store state information, you then lock
00:20:01.387 --> 00:20:04.500 yourself out of other workflows that could be trying to do
00:20:04.500 --> 00:20:05.133 concurrency.
00:20:20.503 --> 00:20:21.113 Yep.
00:20:21.203 --> 00:20:25.264 So then a transient resource is every time you ask for it, you
00:20:25.264 --> 00:20:27.133 get a new different instance.
00:20:28.103 --> 00:20:30.233 So we use that for stuff like models.
00:20:31.003 --> 00:20:34.086 There's a few places you'll probably see if you look around
00:20:34.086 --> 00:20:37.221 where it's like registry loader wrapper dot git, instance of
00:20:37.221 --> 00:20:38.813 sales order model or something.
00:20:37.343 --> 00:20:37.543 Yeah.
00:20:39.623 --> 00:20:42.887 We do that so we don't have to new up a sales model directly
00:20:42.887 --> 00:20:46.204 that way if they're for unit tests and things like that, that
00:20:46.204 --> 00:20:48.879 may have different implementations of sales order
00:20:48.879 --> 00:20:51.393 of that sales order model interface that week.
00:20:52.683 --> 00:20:54.603 You can utilize our dependency injection.
00:20:54.873 --> 00:20:57.323 Yeah, I think we lost him for a second.
00:20:55.623 --> 00:20:55.803 Yeah.
00:20:59.343 --> 00:20:59.963 Yeah.
00:21:00.043 --> 00:21:02.884 And I noticed you, you're actually doing this once here
00:21:02.884 --> 00:21:04.253 with the interfaces in PBC.
00:21:04.263 --> 00:21:07.073 You've got a PBC account model.
00:21:07.743 --> 00:21:10.767 I don't know if it's inheriting the irregular account model, but
00:21:10.767 --> 00:21:13.744 if it if it is, that would be an instance where you would write
00:21:13.744 --> 00:21:16.674 into the registry that you were inheriting the regular account
00:21:16.674 --> 00:21:16.953 model.
00:21:17.083 --> 00:21:19.291 It looks like it is a separate thing though, so this that's not
00:21:19.291 --> 00:21:19.773 the case here.
00:21:19.293 --> 00:21:19.533 Yeah.
00:21:20.463 --> 00:21:25.673 Yeah, but yeah, you're good.
00:21:21.923 --> 00:21:23.193 Yeah, I timed out for a minute.
00:21:23.203 --> 00:21:24.333 So about that guys, I'm back.
00:21:24.723 --> 00:21:24.923 Yeah.
00:21:26.143 --> 00:21:31.060 But yeah, that's so we can utilize the dependency injection
00:21:31.060 --> 00:21:35.894 right by using the like get instance uh to get a transient
00:21:32.393 --> 00:21:32.573 Yeah.
00:21:35.803 --> 00:21:36.053 Umm.
00:21:35.894 --> 00:21:40.073 of whatever concrete right is provided at runtime.
00:21:40.573 --> 00:21:42.963 So what about scope to why don't we use scope?
00:21:42.973 --> 00:21:45.363 Since we're talking about the lifecycles.
00:21:45.123 --> 00:21:45.513 Yeah.
00:21:45.523 --> 00:21:46.993 So that's a good question.
00:21:47.003 --> 00:21:50.133 So the third life cycle I meant I mentioned there are three and
00:21:50.133 --> 00:21:52.773 we really only use transient and Singleton and stuff.
00:21:52.863 --> 00:21:56.871 The third life cycle is scoped, and it's sort of an in between
00:21:56.871 --> 00:21:58.143 for a Singleton and.
00:21:59.963 --> 00:22:06.167 Transient a scoped resource implies that you have to define
00:22:06.167 --> 00:22:11.233 a scope and then inside of that scope each into.
00:22:11.243 --> 00:22:14.888 Each time you request an an interface or an implementation
00:22:14.888 --> 00:22:18.779 of an interface, you'll get back the same instance inside that
00:22:18.779 --> 00:22:19.643 same scope in.
00:22:19.483 --> 00:22:19.703 Umm.
00:22:19.653 --> 00:22:23.183 In net core scopes are automatically created at the
00:22:23.183 --> 00:22:24.133 request level.
00:22:25.453 --> 00:22:29.448 And so in net core scope resource will be the same inside
00:22:29.448 --> 00:22:30.343 of a request.
00:22:30.573 --> 00:22:35.571 However, we don't really have an an analog to that and just in
00:22:35.571 --> 00:22:40.252 NET Framework and it's not something that we really use or
00:22:36.213 --> 00:22:36.513 Umm.
00:22:40.252 --> 00:22:41.203 need to use.
00:22:41.213 --> 00:22:42.633 The way that things are structured right now.
00:22:41.773 --> 00:22:45.911 Well, we do, but I've I've never needed to implement it in inside
00:22:45.911 --> 00:22:48.543 current Seth because like I, yeah, I can.
00:22:46.673 --> 00:22:47.903 Right, I figure, yeah.
00:22:47.913 --> 00:22:50.023 Structure might probably allows you to define a scope.
00:22:48.713 --> 00:22:48.993 I can.
00:22:50.913 --> 00:22:51.553 It's it's.
00:22:51.563 --> 00:22:55.186 I can define the scope with the UM request level using service
00:22:52.703 --> 00:22:54.003 You're right, fired.
00:22:55.186 --> 00:22:58.233 stack, so I can make it interrupt where basically it
00:22:57.333 --> 00:22:57.563 Umm.
00:22:58.233 --> 00:23:01.798 would say like as the request comes in, it gets automatically
00:23:01.798 --> 00:23:05.363 assigned like a quid and that could use that GUID as like the
00:23:05.363 --> 00:23:08.698 context profile name, the context profile name then being
00:23:08.698 --> 00:23:12.378 passed around with that GUID in actively means that it would be
00:23:12.378 --> 00:23:15.828 looking for a container that would that had a scope of that
00:23:15.828 --> 00:23:19.163 GUID and anything that we had put into the scope for that
00:23:19.163 --> 00:23:21.923 registered into the scope with that life cycle.
00:23:21.933 --> 00:23:25.895 It would then give back appropriately depending on if
00:23:25.895 --> 00:23:29.343 the scope is defined for that particular type.
00:23:29.353 --> 00:23:32.910 So like if I had a special product workflow that was
00:23:32.910 --> 00:23:36.870 supposed to hold state of some kind of information, then I
00:23:36.870 --> 00:23:40.695 would inject that product workflow with that information
00:23:40.695 --> 00:23:44.856 into the registry and it could in a sub container of the main
00:23:44.856 --> 00:23:49.084 one using that request ID and then I would have a scoped thing
00:23:49.084 --> 00:23:52.843 the nearest actual like real world equipment that we're
00:23:52.843 --> 00:23:57.003 actually doing though is the tests you'll notice in the test.
00:23:56.503 --> 00:23:56.743 Umm.
00:23:57.013 --> 00:23:59.429 You'll have that using child container and then we have a
00:23:59.429 --> 00:24:01.803 context profile name and that's what gets passed around.
00:24:02.053 --> 00:24:05.581 That is the scoped thing so that we could scope it per test
00:24:05.581 --> 00:24:06.403 through stuff.
00:24:06.413 --> 00:24:09.102 But then when you're actually regularly running it, we never
00:24:09.102 --> 00:24:09.763 create a scope.
00:24:09.773 --> 00:24:12.023 Everything just in the root and you just get.
00:24:12.033 --> 00:24:15.615 Everybody gets the new apps and the OR the singletons as as we
00:24:15.615 --> 00:24:19.026 were really defined them in our registries and then we just
00:24:19.026 --> 00:24:20.163 utilize it that way.
00:24:20.173 --> 00:24:22.970 I don't do anything more specific where I try to make it
00:24:22.970 --> 00:24:25.913 so that like a specific tax provider or something like that
00:24:25.913 --> 00:24:27.973 has to come in with this particular data.
00:24:29.403 --> 00:24:33.048 The the nearest things that we would be getting to that point
00:24:33.048 --> 00:24:36.869 as because we've been trying to transition and closer to this is
00:24:36.869 --> 00:24:40.691 the the pricing factory context and the user context that's been
00:24:40.691 --> 00:24:44.394 added especially after the CSR emulation stuff was added where
00:24:44.394 --> 00:24:48.098 you could say that the logically user versus the physical user
00:24:48.098 --> 00:24:51.742 kind that info that would be example of data that that should
00:24:51.742 --> 00:24:55.328 be scoped. So that when the request comes in, it understands
00:24:55.328 --> 00:24:58.738 who it is and would put that into there and we would pass
00:24:58.738 --> 00:24:59.443 that around.
00:24:59.573 --> 00:25:02.993 However, at the moment we would just pass that data through the
00:25:02.993 --> 00:25:06.467 functions on our interfaces and on our classes as we're pressing
00:25:06.467 --> 00:25:09.673 it stuff around manually so that it can go through the meat
00:25:09.673 --> 00:25:12.933 grinder and come out on the other side as the ground meat as
00:25:12.933 --> 00:25:13.413 intended.
00:25:14.963 --> 00:25:18.484 We will be doing more of that scope stuff in .net core like he
00:25:18.484 --> 00:25:21.948 said, we we've already got it set up to where we're basically
00:25:21.948 --> 00:25:25.357 gonna start from that procedure of having scoped information
00:25:25.357 --> 00:25:27.033 like what's your session info.
00:25:27.963 --> 00:25:30.536 So that information can be shared and not have to be
00:25:30.536 --> 00:25:32.623 repelled from the database multiple times.
00:25:32.643 --> 00:25:35.643 That kind of stuff in there and try to be more efficient.
00:25:36.913 --> 00:25:37.363 Yeah.
00:25:37.443 --> 00:25:40.493 And really increase the efficiency and performance of
00:25:40.493 --> 00:25:42.243 the application as a whole. Uh.
00:25:44.673 --> 00:25:49.706 So yeah, the PBC or client acronym service file will use
00:25:49.706 --> 00:25:55.269 that to I define our getters so that we can use the dependency
00:25:55.269 --> 00:26:01.008 injector to grant us a Singleton life cycle of the workflow that
00:26:01.008 --> 00:26:06.305 we've defined in our registry or registered in our registry
00:26:06.305 --> 00:26:06.923 rather.
00:26:10.113 --> 00:26:15.391 And I like to create the public partial class of the service
00:26:15.391 --> 00:26:20.235 here this is gonna be the one that's gonna inherit from
00:26:20.235 --> 00:26:25.599 clarity ecommerce service base and use this file the the root
00:26:25.599 --> 00:26:31.309 service layer to define just the ginners and have all the getters
00:26:31.309 --> 00:26:32.433 defined here.
00:26:32.613 --> 00:26:37.724 That way, in all the various workflows I don't have to define
00:26:37.724 --> 00:26:43.000 a getter in anywhere else and I can just use it here, right and
00:26:43.000 --> 00:26:44.483 use the getter to.
00:26:46.683 --> 00:26:50.941 Hand me that love Singleton instance of the workflow and not
00:26:50.941 --> 00:26:55.409 new up one, and I've seen that in some client projects recently
00:26:55.409 --> 00:26:59.527 where this wasn't even being utilized right, like uh, this
00:26:59.527 --> 00:27:04.065 portion of registering a getter and calling the getter when they
00:27:04.065 --> 00:27:08.532 needed to access the workflow in like the service layer instead
00:27:08.532 --> 00:27:11.533 of newing up an instance of that workflow.
00:27:12.113 --> 00:27:14.313 Uh, so we'll.
00:27:13.623 --> 00:27:17.765 So real quick though, something that you something that might be
00:27:17.765 --> 00:27:21.014 worth answering while we're looking at these is if
00:27:20.143 --> 00:27:20.383 Sure.
00:27:21.014 --> 00:27:24.964 anybody's, uh, if anybody is curious why we do these or maybe
00:27:24.964 --> 00:27:28.723 if anyone wants to try to to answer that now, does anybody
00:27:28.723 --> 00:27:31.653 know why we do this or why this is necessary?
00:27:37.843 --> 00:27:42.452 If not, I will happily explain, because we've already we've
00:27:42.452 --> 00:27:46.753 already stated that we are replacing with the registry.
00:27:46.763 --> 00:27:51.296 We're saying that I product workflow for example is already
00:27:51.296 --> 00:27:53.033 a PBC product workflow.
00:27:53.043 --> 00:27:54.533 So what do we need this method for?
00:27:54.543 --> 00:27:55.423 What's the point of this?
00:27:55.433 --> 00:27:56.503 What does this do for us?
00:27:59.233 --> 00:28:00.633 And the answer is.
00:28:00.393 --> 00:28:02.583 Ohm I'm.
00:28:02.653 --> 00:28:02.943 This.
00:28:02.743 --> 00:28:07.352 I'm guessing this is like where you wanna reference stuff, so
00:28:07.352 --> 00:28:11.663 you're not like moving up crap everywhere or where thick.
00:28:11.363 --> 00:28:11.833 Special.
00:28:11.933 --> 00:28:17.319 Exactly what we're doing here is we're casting the eye product
00:28:17.319 --> 00:28:22.363 workflow interface to the concrete and the question there.
00:28:17.973 --> 00:28:21.403 Yeah, that's what I thought, yeah.
00:28:18.973 --> 00:28:20.533 Ohh yeah.
00:28:22.373 --> 00:28:24.283 The question is why do we do that?
00:28:24.293 --> 00:28:28.116 The answer is so we don't have to go define custom workflow
00:28:28.116 --> 00:28:31.876 methods all the way up at the interface level and then and
00:28:31.733 --> 00:28:32.163 Umm.
00:28:31.876 --> 00:28:35.061 then put a stub out implementation in 05 business
00:28:32.033 --> 00:28:32.283 Umm.
00:28:35.061 --> 00:28:38.183 logic so that we can come down here and call it.
00:28:37.163 --> 00:28:37.463 Yeah.
00:28:38.263 --> 00:28:41.856 We just cast to our actual concrete that lives in just this
00:28:41.856 --> 00:28:45.569 layer, so that endpoints in this layer can call directly into
00:28:45.569 --> 00:28:48.323 those without having to go back up into core.
00:28:48.333 --> 00:28:52.579 So again, it's just keeping keeping client level code in the
00:28:52.579 --> 00:28:53.483 client level.
00:28:54.183 --> 00:28:54.753 Umm.
00:28:54.943 --> 00:28:57.003 Rather than having to go up and.
00:28:57.003 --> 00:29:01.566 Right, because without this we would have to go into the
00:28:57.883 --> 00:28:59.343 Bury that stuff in the core.
00:29:01.566 --> 00:29:06.609 interfaces into the workflows, the fine, add a method here and
00:29:02.593 --> 00:29:02.733 Yeah.
00:29:03.993 --> 00:29:05.583 And add a method onto those. Yep.
00:29:06.609 --> 00:29:11.652 then put a virtual version of that method in the core workflow
00:29:11.652 --> 00:29:13.493 and override it, right?
00:29:13.493 --> 00:29:13.803 Umm.
00:29:15.533 --> 00:29:16.103 Yeah.
00:29:16.753 --> 00:29:21.168 So that again, it's just keeping in keeping in pattern in lock
00:29:21.168 --> 00:29:25.372 step with with keeping our client specific code confined to
00:29:25.372 --> 00:29:27.333 the client override project.
00:29:29.603 --> 00:29:31.313 Now it doesn't have to be.
00:29:31.323 --> 00:29:34.813 These don't have to be all defined in this one file.
00:29:35.653 --> 00:29:37.213 You can define them in.
00:29:37.383 --> 00:29:42.046 You know their own separate like some some client projects here
00:29:42.046 --> 00:29:46.636 like PBC product service would have the product getter defined
00:29:46.636 --> 00:29:51.445 in this file and invoice service would have the getter defined in
00:29:51.445 --> 00:29:52.173 this file.
00:29:52.473 --> 00:29:56.664 I like putting them in one using it, kind of like the registry
00:29:56.664 --> 00:30:00.788 and just having a single place where you add this for all and
00:30:00.788 --> 00:30:02.783 then you have clean workflows.
00:30:01.863 --> 00:30:05.202 And you're not limited to to just ones that are overriding
00:30:05.202 --> 00:30:07.013 like a regular product workflow.
00:30:07.083 --> 00:30:10.613 If you have a completely custom thing in here to talk to, you
00:30:10.613 --> 00:30:14.313 know good hire or some or badge or some third party service, and
00:30:14.313 --> 00:30:18.013 it's an entirely custom workflow that you got going on in there.
00:30:18.183 --> 00:30:20.713 You can new up and register them there as well.
00:30:22.803 --> 00:30:23.123 Right.
00:30:23.283 --> 00:30:24.323 From from core.
00:30:25.253 --> 00:30:27.123 Yeah, that's a that's an excellent caveat.
00:30:27.663 --> 00:30:28.003 Umm.
00:30:29.913 --> 00:30:33.245 Then the this way, once we get into the actual separating out
00:30:33.245 --> 00:30:36.630 and this is another part of the format of how these need to be
00:30:36.630 --> 00:30:37.113 laid out.
00:30:37.883 --> 00:30:43.013 If I need a new end point for the accounts right?
00:30:43.763 --> 00:30:47.402 Or products will say in this ones like the product will open
00:30:47.402 --> 00:30:50.563 product products, a gift card restrictions ID right?
00:30:50.573 --> 00:30:56.889 This endpoint if I want to register this endpoint class I
00:30:56.889 --> 00:31:00.373 need to create a public product.
00:31:00.413 --> 00:31:04.736 Or sorry PBC product service file to separate these out.
00:31:04.736 --> 00:31:08.831 These different services. Instead of combining all of
00:31:08.831 --> 00:31:13.837 these into a single file instead of having all these endpoints in
00:31:13.837 --> 00:31:16.263 their handlers in a single file.
00:31:16.273 --> 00:31:19.013 We need to separate them out, so that hey, I need to.
00:31:19.813 --> 00:31:21.663 Work in the account service.
00:31:21.673 --> 00:31:24.053 Then I just going through the OR the account update service
00:31:24.053 --> 00:31:26.313 rather I just go into the account update service, right?
00:31:27.143 --> 00:31:28.593 Or the invoice service.
00:31:28.603 --> 00:31:33.073 I don't go into PBC service and scroll through 300 lines looking
00:31:33.073 --> 00:31:36.717 for the account service, so separate them out in the
00:31:36.717 --> 00:31:40.223 services folder into the each individual services.
00:31:42.163 --> 00:31:47.833 Define your getters for your workflows in the service class.
00:31:47.903 --> 00:31:51.576 The acronym service class that inherits clarity Commerce
00:31:51.576 --> 00:31:52.413 service base.
00:31:52.423 --> 00:31:56.788 This is partial, and then all these files here where the
00:31:56.788 --> 00:32:01.153 handlers are defined are partials and we just define our
00:32:01.153 --> 00:32:05.825 handler for the the end point that it's defined and this was
00:32:05.825 --> 00:32:10.190 kind of after looking through several ways of this being
00:32:10.190 --> 00:32:12.563 implemented, I think that this.
00:32:13.653 --> 00:32:18.381 Separates concerns out, you know, single responsibility, and
00:32:18.381 --> 00:32:22.953 it's a good way for organizing and structuring our client.
00:32:22.963 --> 00:32:26.483 Override projects and the same applies to the workflows.
00:32:26.933 --> 00:32:31.957 We have individual workflows so we need individual files and of
00:32:31.957 --> 00:32:36.273 course we're not gonna put multiple classes in a file.
00:32:36.283 --> 00:32:39.341 This is not something that's common in the workflow section,
00:32:39.341 --> 00:32:42.650 but it is common in the services to have individual or to have it
00:32:42.650 --> 00:32:44.003 all combined into one file.
00:32:44.273 --> 00:32:45.613 Let's keep it separated out.
00:32:46.493 --> 00:32:46.893 Umm.
00:32:47.143 --> 00:32:51.650 In the workflows we follow the naming convention for the names
00:32:51.650 --> 00:32:56.084 of the Files Client acronym and then whatever workflow you're
00:32:56.084 --> 00:33:00.304 overriding client acronym, workflow and then inherits from
00:33:00.304 --> 00:33:04.238 the workflow that you're overriding and you can add in
00:33:04.238 --> 00:33:07.313 your custom or overridden logic into here.
00:33:09.233 --> 00:33:09.613 Umm.
00:33:11.183 --> 00:33:12.393 Models and interfaces.
00:33:12.403 --> 00:33:14.533 Again, folders at the base levels, ETC.
00:33:14.543 --> 00:33:19.188 Separate these things out like these are gonna be DTO's most
00:33:19.188 --> 00:33:21.243 likely and email templates.
00:33:21.253 --> 00:33:23.413 You know, this was one that was just kind of thrown in here.
00:33:23.423 --> 00:33:26.666 We might have some more to do with that, but for the basic
00:33:26.666 --> 00:33:29.963 workflow services, models and interfaces keep it like this.
00:33:34.283 --> 00:33:35.483 And let's see.
00:33:34.723 --> 00:33:37.937 And then and and that is effectively recreating the the
00:33:37.937 --> 00:33:41.609 what the outer tiers look like if you're not using the numbers,
00:33:41.023 --> 00:33:41.523 That's right.
00:33:41.609 --> 00:33:45.166 that's totally fine, but you're just trying to make sure that
00:33:45.166 --> 00:33:47.633 it's reasonably organized into this stuff.
00:33:47.643 --> 00:33:48.593 It doesn't have to be exact.
00:33:48.603 --> 00:33:52.138 It doesn't have to be perfect as long as it's as long as it's
00:33:52.138 --> 00:33:55.444 good enough that if Greg has been working on this for six
00:33:55.444 --> 00:33:59.035 months and now Jim needs to jump in and work on it, Jim is not
00:33:59.035 --> 00:34:02.683 going to be lost for six hours trying to find something in, you
00:34:02.583 --> 00:34:03.063 That's right.
00:34:02.683 --> 00:34:06.274 know, wherever it is, it's gonna be reasonably intuitive as to
00:34:06.274 --> 00:34:07.243 where stuff went.
00:34:09.703 --> 00:34:10.453 Let's see.
00:34:11.203 --> 00:34:14.553 I don't know how much more I could talk about this.
00:34:14.663 --> 00:34:17.133 We could talk about more about overrides.
00:34:17.143 --> 00:34:18.823 Let me look at our training sheet.
00:34:18.833 --> 00:34:20.663 We might be throw something else into this one.
00:34:22.363 --> 00:34:22.593 One.
00:34:24.053 --> 00:34:28.259 Is there anything you guys want to add on to client overrides or
00:34:28.259 --> 00:34:32.205 anything about this topic or anything we've talked about and
00:34:32.205 --> 00:34:33.563 dependency injection?
00:34:35.823 --> 00:34:38.113 Ah, anything.
00:34:38.903 --> 00:34:39.893 Life cycles.
00:34:39.903 --> 00:34:43.063 Anything while I'm looking for another fiddler.
00:34:47.353 --> 00:34:51.679 Should we mention when it's when we shouldn't do something in the
00:34:51.679 --> 00:34:55.283 client override like some examples with that might be?
00:34:55.313 --> 00:34:56.243 Sure.
00:34:57.013 --> 00:35:01.953 So I would not put core bug fixes.
00:34:57.563 --> 00:35:02.453 Four bug fixes is a big one, yeah.
00:35:01.433 --> 00:35:01.613 Yeah.
00:35:01.963 --> 00:35:08.563 Yeah, third party providers, most likely most of the time.
00:35:08.573 --> 00:35:11.198 If it is a third party integration, we're gonna bring
00:35:11.198 --> 00:35:12.073 it back into core.
00:35:13.793 --> 00:35:15.473 Yeah, we're going to want to reuse that later.
00:35:15.483 --> 00:35:18.337 So yeah, if you're building new payment providers, shipping
00:35:16.413 --> 00:35:20.093 Yeah, put all that into.
00:35:16.663 --> 00:35:16.953 It.
00:35:18.337 --> 00:35:21.191 providers, that kind of thing, those should be in an actual
00:35:20.213 --> 00:35:20.333 Yeah.
00:35:21.191 --> 00:35:22.713 provider, not a client override.
00:35:22.283 --> 00:35:23.743 That's right, yeah.
00:35:23.393 --> 00:35:25.713 And you're saying like, if you're extending an.
00:35:25.723 --> 00:35:26.283 I was gonna.
00:35:26.293 --> 00:35:28.694 I was gonna make a silly joke, and that's something that
00:35:28.694 --> 00:35:29.073 happened.
00:35:29.083 --> 00:35:32.663 But yeah, there was a let's just say we the someone had done a
00:35:32.663 --> 00:35:36.073 little bit of work on a payment provider but then added the
00:35:36.073 --> 00:35:39.539 extra functionality into an override and I I don't even know
00:35:38.183 --> 00:35:41.633 Yes, that's a that's an exact one, like a nube.
00:35:38.983 --> 00:35:39.183 Yeah.
00:35:39.539 --> 00:35:41.073 how that would have worked.
00:35:41.903 --> 00:35:44.873 Yeah, you know exactly what you talk.
00:35:42.303 --> 00:35:44.103 Yeah, I was like ohh OK.
00:35:43.543 --> 00:35:44.043 So.
00:35:43.893 --> 00:35:47.573 Yeah, if if you're doing something, yeah.
00:35:44.083 --> 00:35:46.383 So yeah, generally, let's not do that.
00:35:47.583 --> 00:35:50.656 If if you're modifying a payment provider to do something that
00:35:50.656 --> 00:35:53.484 only that client would ever do, because it's because what
00:35:53.484 --> 00:35:56.410 they're doing is crazy and dumb and stupid, and we all know
00:35:56.410 --> 00:35:58.263 clients, that's what they like to do.
00:35:58.923 --> 00:36:02.176 Uh, you know, if you need to override that functionality or
00:36:02.176 --> 00:36:05.538 you need to create like a really good example is the combined
00:36:05.538 --> 00:36:06.513 shipping provider.
00:36:07.163 --> 00:36:11.395 It has really weird custom logic that I particular client needed
00:36:11.395 --> 00:36:15.496 to specifically choose whether to show UPS or FedEx results or
00:36:15.496 --> 00:36:17.123 specific subsets of them.
00:36:17.543 --> 00:36:21.067 Well, the only real way to do that was to make a client custom
00:36:18.133 --> 00:36:18.363 Umm.
00:36:21.067 --> 00:36:21.793 specific one.
00:36:21.943 --> 00:36:26.070 So in that case, if you need to make a PBC combined shipping
00:36:26.070 --> 00:36:29.723 provider and throw it inside that thing, that's fine.
00:36:30.033 --> 00:36:34.009 We also have cases where like it's the the tiered pricing with
00:36:34.009 --> 00:36:37.732 fall back to flat type of thing we that one we put in as a
00:36:37.732 --> 00:36:41.393 regular one because all it's really trying to do is if it
00:36:41.393 --> 00:36:45.368 didn't arrive at a valid result using tiered pricing, it would
00:36:45.368 --> 00:36:49.218 fall back and just use regular flat pricing which we're both
00:36:49.218 --> 00:36:51.363 totally normal out of box things.
00:36:51.373 --> 00:36:55.082 So in that one, that's a really good one to keep inside the
00:36:55.082 --> 00:36:58.543 regular providers layer and inside the pricing project.
00:36:59.433 --> 00:37:03.040 So if you've got stuff like that, it it's some of it's gonna
00:37:03.040 --> 00:37:06.528 depend and and you have to figure out is this really going
00:37:06.528 --> 00:37:09.898 to be super custom that is or and super specific to this
00:37:09.898 --> 00:37:13.504 client is something that we might be able to reuse can maybe
00:37:13.504 --> 00:37:17.229 I threw it up the flagpole and say hey Eric, Brandon, James BL
00:37:17.229 --> 00:37:18.943 umm you know any of you guys.
00:37:18.953 --> 00:37:21.878 Hey, do you guys do you think that this would be good to throw
00:37:21.878 --> 00:37:24.709 in this spot or this spot if I'm confused about which one or
00:37:24.709 --> 00:37:25.683 where it needs to go?
00:37:26.183 --> 00:37:26.673 Yep.
00:37:27.163 --> 00:37:30.461 And that's yeah, generally speaking, that's the case for
00:37:30.461 --> 00:37:31.733 just about everything.
00:37:32.523 --> 00:37:35.922 And this is mostly for the recording in case a new person
00:37:35.922 --> 00:37:39.203 for some reason is watching this, which would be great.
00:37:39.213 --> 00:37:39.343 Yeah.
00:37:39.353 --> 00:37:43.294 We should teach them this, but if you're new and you're ever
00:37:41.103 --> 00:37:41.363 Yeah.
00:37:41.493 --> 00:37:42.553 And there's going to be like the.
00:37:43.294 --> 00:37:47.299 confused and you're wondering, should I make a judgment call,
00:37:47.299 --> 00:37:48.913 or should I ask somebody?
00:37:49.203 --> 00:37:52.870 Maybe it's going to be annoying if I ask it's way more annoying
00:37:49.823 --> 00:37:50.093 Because.
00:37:52.870 --> 00:37:55.963 when your judgment call is wrong, so please just ask.
00:37:59.063 --> 00:38:01.353 And when it comes to the go ahead.
00:37:59.403 --> 00:37:59.853 Yeah.
00:37:59.893 --> 00:38:03.869 And then the other situation that you'll run into is, yes,
00:38:03.869 --> 00:38:07.103 you've got the core bug fixes that we want you.
00:38:07.113 --> 00:38:08.413 We want you to fix core bugs.
00:38:08.423 --> 00:38:08.893 Absolutely.
00:38:08.903 --> 00:38:12.363 So we can bring those back over from your client project into
00:38:12.363 --> 00:38:15.822 the release as well as porting and cherry picking that to the
00:38:15.822 --> 00:38:19.393 releases that come after it and further on down the line to the
00:38:19.393 --> 00:38:20.843 latest Bleeding Edge code.
00:38:21.443 --> 00:38:26.235 Umm, if what you're doing is a really small tiny thing that is
00:38:26.235 --> 00:38:30.493 literally just, I need you to do $5 versus $6 as a fee.
00:38:30.503 --> 00:38:32.493 That's hard coded into the code somewhere.
00:38:32.583 --> 00:38:36.231 I'm just using really crappy example and you just need to
00:38:36.231 --> 00:38:40.130 hide it behind a setting and it it's the term like a one line
00:38:40.130 --> 00:38:43.777 into what five or six lines for because it it's now an if
00:38:43.777 --> 00:38:47.362 statement that has an if body and an else body or it's a
00:38:47.362 --> 00:38:51.072 ternary for a particular value, whatever those tiny little
00:38:51.072 --> 00:38:54.657 changes that are really small and that can be especially
00:38:54.657 --> 00:38:56.103 hidden behind settings.
00:38:56.513 --> 00:39:00.088 I'm perfectly OK with your first run going in and putting that
00:39:00.088 --> 00:39:03.549 into the core code, because it's gonna be shareable and it's
00:39:03.549 --> 00:39:06.783 gonna be repeatable and that will make it easier than me
00:39:06.783 --> 00:39:10.073 having to go over, pull it down from your override later.
00:39:11.253 --> 00:39:12.813 But again, that's a judgment call.
00:39:12.823 --> 00:39:14.613 So, you know, keep it small.
00:39:14.623 --> 00:39:15.263 Keep it light.
00:39:15.323 --> 00:39:16.663 Ask the question if you're unsure.
00:39:17.873 --> 00:39:18.093 Yep.
00:39:19.543 --> 00:39:23.870 And in a in say something like, we've got a core payment
00:39:23.870 --> 00:39:24.553 provider.
00:39:25.923 --> 00:39:30.226 Say that is that is in core but ACH is not implemented for that
00:39:30.226 --> 00:39:32.713 core payment provider and we have a.
00:39:32.763 --> 00:39:36.037 The first client rolls along and says hey I wanna use this
00:39:36.037 --> 00:39:39.476 payment provider and I wanna implement ACH with it that needs
00:39:39.476 --> 00:39:41.473 to go in the providers layer right?
00:39:41.443 --> 00:39:43.803 Absolutely, absolutely.
00:39:41.533 --> 00:39:44.273 That does not need to go into a client override.
00:39:43.063 --> 00:39:51.133 Yep, yeah, 100% and yeah, there's all.
00:39:45.963 --> 00:39:46.203 Right.
00:39:51.143 --> 00:39:54.712 I can't think of a single reason why it wouldn't, unless again,
00:39:54.712 --> 00:39:57.500 as James said, it was some totally whacky, insane
00:39:57.500 --> 00:40:01.013 implementation that no one would ever, ever use against. Yeah.
00:39:57.743 --> 00:40:04.113 Yeah, super specific custom logic or something. Uh.
00:39:59.163 --> 00:39:59.323 Yeah.
00:40:03.333 --> 00:40:04.003 Like I like.
00:40:04.073 --> 00:40:09.981 I just yesterday I literally wrote a new payment process that
00:40:09.981 --> 00:40:13.983 is specific to taking donations for CMMC.
00:40:14.353 --> 00:40:18.736 I basically like I'm having to have one button click take in an
00:40:18.736 --> 00:40:22.982 address from the UI, a credit card from the UI and a donation
00:40:22.982 --> 00:40:26.953 amount from the UI, run it through the processor and then
00:40:26.953 --> 00:40:31.062 create a dummy order off of it with a sales item that isn't
00:40:31.062 --> 00:40:33.253 even actually tied to a product.
00:40:33.313 --> 00:40:37.271 And to put into the the system because it an anonymous person
00:40:37.271 --> 00:40:39.313 is allowed to come to this form.
00:40:39.683 --> 00:40:43.726 Just putting credit card and address info and pay and giving
00:40:43.726 --> 00:40:45.183 and giving a donation.
00:40:45.373 --> 00:40:49.590 That's a weird custom situation that is not gonna happen very
00:40:49.590 --> 00:40:54.010 often, and it needs to build the order in a specific way so that
00:40:54.010 --> 00:40:58.023 they know that it's a donation and get an email alert that
00:40:58.023 --> 00:41:02.103 about that donation to their admins and all that stuff that
00:41:02.103 --> 00:41:04.143 is going right into a regular.
00:41:04.763 --> 00:41:07.966 Uh, you know project override position with its own custom
00:41:07.966 --> 00:41:10.733 endpoint and everything for submitting a donation.
00:41:11.663 --> 00:41:15.015 That would, and if I have another client down the road
00:41:15.015 --> 00:41:17.573 that wants to do the same thing, I'll go.
00:41:17.583 --> 00:41:19.453 Hey CMMC, did that.
00:41:19.463 --> 00:41:22.599 Let me go grab that code and see how close it is to what these
00:41:22.599 --> 00:41:25.287 guys want and if I can reimplement using that to save
00:41:25.287 --> 00:41:26.133 myself some time.
00:41:32.793 --> 00:41:36.943 Umm, so we got about 45 minutes.
00:41:36.953 --> 00:41:40.703 Do you think we could squeeze in some Redis sauce into this?
00:41:41.763 --> 00:41:42.343 Uh.
00:41:42.903 --> 00:41:44.753 Or do you wanna save that for its own?
00:41:43.683 --> 00:41:45.793 Saying rest or Redis.
00:41:46.383 --> 00:41:49.643 Read as I call it Redis, Redis umm.
00:41:47.813 --> 00:41:49.583 OK OK.
00:41:52.023 --> 00:41:55.433 I've got one training topic for Redis caching.
00:41:55.883 --> 00:41:58.693 How it works 304 logic etcetera.
00:41:59.243 --> 00:42:01.573 Is that something we can squeeze in in 45 minutes?
00:42:01.583 --> 00:42:02.083 To you then.
00:42:03.723 --> 00:42:07.523 Previous is not not complicated, so I I I say we go for.
00:42:06.883 --> 00:42:07.183 Sure.
00:42:08.403 --> 00:42:11.023 Alright. So.
00:42:10.603 --> 00:42:12.323 Ice is not complicated, but.
00:42:14.603 --> 00:42:14.733 Yeah.
00:42:14.703 --> 00:42:19.243 Can we can we admit it can be annoying alright?
00:42:15.733 --> 00:42:15.993 I.
00:42:17.333 --> 00:42:20.723 Ohh yeah, yeah uh so.
00:42:19.903 --> 00:42:22.851 Obviously the only annoying thing is pulling back deep like
00:42:22.851 --> 00:42:24.373 a pre deflated content from it.
00:42:24.383 --> 00:42:27.493 That's the thing that ****** me off because that's where most of
00:42:27.493 --> 00:42:28.593 our failures come from.
00:42:30.143 --> 00:42:30.383 Yeah.
00:42:30.933 --> 00:42:34.483 Actually, I shouldn't say it like in and of itself.
00:42:34.493 --> 00:42:35.563 It's annoying sometimes.
00:42:36.623 --> 00:42:39.843 Uh, it's not Even so much.
00:42:38.383 --> 00:42:40.303 The caching logic is some point.
00:42:40.393 --> 00:42:43.825 Yeah, it's not Even so much the the greatest part is, like
00:42:43.825 --> 00:42:47.024 sometimes people don't like update, you know, like the
00:42:47.024 --> 00:42:49.583 updated day or whatever and blah blah blah.
00:42:49.593 --> 00:42:51.583 And they just like neglect it.
00:42:51.593 --> 00:42:54.333 So that ends up causing issues elsewhere. Uh.
00:42:56.323 --> 00:42:57.323 That's where it gets annoying.
00:42:59.063 --> 00:42:59.513 So you're like.
00:42:59.093 --> 00:43:02.504 So should I pause the recording or stop the recording and start
00:43:02.504 --> 00:43:02.983 it again?
00:43:03.653 --> 00:43:05.043 Yes, we're changing topics.
00:43:03.753 --> 00:43:04.743 So this is separated.
00:43:05.053 --> 00:43:06.743 Yeah, he hit a stop and start on it.
00:43:05.203 --> 00:43:05.383 Yeah.
00:43:05.603 --> 00:43:06.243 Yeah. OK.00:00:08.669 --> 00:00:12.004 We should make sure that these are being like, memorialized
00:00:12.004 --> 00:00:12.449 somehow.
00:00:12.459 --> 00:00:17.699 Otherwise, uh, a good chunk of this is all for not right so.
00:00:17.229 --> 00:00:20.356 What I'm hearing is that you're volunteering to do that and
00:00:20.356 --> 00:00:22.909 ensure that they get taken and listed somewhere.
00:00:22.409 --> 00:00:26.173 If I had, if I had access to like, I mean, I guess I could
00:00:26.173 --> 00:00:30.065 just scroll up, but I assume there's an easier place to find
00:00:28.239 --> 00:00:28.479 Yeah.
00:00:29.039 --> 00:00:30.419 Get with UM.
00:00:30.065 --> 00:00:30.639 them all.
00:00:31.609 --> 00:00:32.419 Ask Caroline.
00:00:31.959 --> 00:00:32.909 I've been.
00:00:32.959 --> 00:00:36.547 I've been uploading these all into new Cleo and also saving at
00:00:35.979 --> 00:00:36.379 Uh.
00:00:36.547 --> 00:00:40.249 least these series of reportings because I know we've been doing
00:00:39.789 --> 00:00:39.999 Umm.
00:00:40.249 --> 00:00:43.724 these as like a hey, let's get all of our training materials
00:00:43.724 --> 00:00:47.255 updated for potential new devs, so I've been saving all these
00:00:47.255 --> 00:00:50.729 recordings in a folder and like editing them as I have time.
00:00:50.739 --> 00:00:54.841 I just haven't been able to like build out the LMS courses just
00:00:54.841 --> 00:00:57.469 yet because again, I am not a developer.
00:00:56.629 --> 00:00:56.869 Sure.
00:00:57.479 --> 00:00:58.829 But yeah, we are.
00:00:59.219 --> 00:01:02.389 These are getting saved and nuclino and been saved.
00:01:01.729 --> 00:01:05.639 Caroline deserves an entirely consensual giant bear hug.
00:01:03.919 --> 00:01:04.099 Yeah.
00:01:06.629 --> 00:01:06.799 Yeah.
00:01:09.269 --> 00:01:09.509 Yeah.
00:01:09.409 --> 00:01:10.919 They are being saved.
00:01:09.749 --> 00:01:10.969 Yeah, that's that's awesome.
00:01:11.349 --> 00:01:15.142 I wish that I knew more so that I could actually just create the
00:01:15.142 --> 00:01:18.059 courses for you guys, but I am not that smart so.
00:01:17.279 --> 00:01:21.716 I honestly, I honestly think the recordings themselves, even
00:01:21.716 --> 00:01:26.444 without any clipping or editing like our, I think they're pretty
00:01:23.429 --> 00:01:24.589 Just going straight is enough.
00:01:26.444 --> 00:01:27.099 valuable.
00:01:27.329 --> 00:01:28.699 Yeah, it's a lot to sit through.
00:01:28.709 --> 00:01:33.489 But like uh, at the same time, there's a lot to cover, right?
00:01:33.499 --> 00:01:37.412 So like, I don't even think necessarily like trying to like
00:01:33.869 --> 00:01:34.149 Yeah.
00:01:36.709 --> 00:01:37.099 Yeah.
00:01:37.109 --> 00:01:40.617 If Caroline, do you know how many videos that you have saved
00:01:37.412 --> 00:01:39.629 clip out 15 minutes a crap, yeah.
00:01:40.617 --> 00:01:41.709 up there right now?
00:01:42.509 --> 00:01:46.499 In Nuclino a lot.
00:01:44.279 --> 00:01:44.559 Yeah.
00:01:46.589 --> 00:01:47.379 A lot.
00:01:47.389 --> 00:01:49.839 Lot UM like here.
00:01:49.849 --> 00:01:52.829 Let me get the actual collection because it's in.
00:01:52.119 --> 00:01:52.489 Is it?
00:01:52.489 --> 00:01:56.340 And I'm assuming they have reasonable topic relevant
00:01:52.819 --> 00:01:53.219 Is it?
00:01:56.340 --> 00:01:56.849 titles.
00:01:57.749 --> 00:01:58.929 Oh yeah, I see all of them. Yeah.
00:01:58.139 --> 00:02:00.209 Uh, whenever I can.
00:02:00.219 --> 00:02:03.486 I put topic relevant titles sometimes if I'm not like in the
00:02:03.486 --> 00:02:05.789 training right don't know what's going on.
00:02:05.799 --> 00:02:08.839 I'm not able to put those in, but that's the collection.
00:02:09.639 --> 00:02:12.871 Umm, I've been trying to add them if I like no so it's like
00:02:12.871 --> 00:02:15.349 OK, the one I was like, I think I was in one.
00:02:15.359 --> 00:02:19.229 I was like, OK, I know for sure this one unit test, so I put
00:02:19.229 --> 00:02:22.781 that in or if I also have the schedule that Tim created
00:02:22.781 --> 00:02:25.889 forever ago and I kind of followed that as well.
00:02:26.159 --> 00:02:29.719 So I tried to add it in where I can but there are times where I
00:02:29.719 --> 00:02:31.999 don't actually know what's going on. So.
00:02:33.989 --> 00:02:34.529 What's going on?
00:02:34.089 --> 00:02:34.259 Yeah.
00:02:34.269 --> 00:02:37.789 And eventually somebody can come in and transcribe these, right?
00:02:38.329 --> 00:02:40.129 She want to walk in the sunshine a little bit longer.
00:02:41.369 --> 00:02:43.629 Yeah, well, they're automatically transcribed.
00:02:43.639 --> 00:02:44.319 It might just you know.
00:02:44.359 --> 00:02:50.002 Well, I mean, uh, like put them into like a like a Word
00:02:50.002 --> 00:02:50.909 document.
00:02:50.919 --> 00:02:53.139 Like that outlines the training.
00:02:52.189 --> 00:02:53.029 I can.
00:02:53.999 --> 00:02:57.099 Can we this?
00:02:57.109 --> 00:02:59.730 This feels like a really good because we have the transcripts
00:02:59.730 --> 00:03:00.829 there with the timestamps.
00:03:01.589 --> 00:03:06.436 Umm, we can create the the SRT files and everything and put all
00:03:01.639 --> 00:03:01.869 Umm.
00:03:06.436 --> 00:03:08.329 of those videos together.
00:03:09.289 --> 00:03:14.585 Umm, this feels a really good candidate to train an AI to
00:03:14.179 --> 00:03:15.209 Yeah, I was gonna say like.
00:03:14.349 --> 00:03:15.809 Does. Yeah.
00:03:14.585 --> 00:03:17.689 generate US output documentation.
00:03:18.419 --> 00:03:22.949 That is, a is an excellent, excellent suggestion, no.
00:03:22.529 --> 00:03:27.174 So if anyone wants to do that, I'm sure we could get some buy
00:03:27.174 --> 00:03:31.669 out from the the the heads to spend some time on converting
00:03:28.729 --> 00:03:28.909 Yeah.
00:03:31.669 --> 00:03:36.389 that information into something that can spit that out for us.
00:03:36.759 --> 00:03:40.623 And then give back reference points to like go to this video
00:03:40.623 --> 00:03:44.678 at this timestamp to learn more type of thing because one of my
00:03:44.139 --> 00:03:45.369 That is an extra.
00:03:44.678 --> 00:03:48.795 fields with the with the videos I had before was that especially
00:03:48.795 --> 00:03:49.809 those long ones.
00:03:50.189 --> 00:03:53.425 Some of that information gets a bit scatterbrained, where like
00:03:53.425 --> 00:03:56.301 I'm talking about installing things in like 5 different
00:03:56.301 --> 00:03:59.229 points of the video, and it's not really organized well.
00:03:59.539 --> 00:04:03.196 So if we can organize it into, you know, information that came
00:04:03.196 --> 00:04:06.969 up during some other video that was about Reedus and we're about
00:04:06.969 --> 00:04:10.278 to talk about Redis now, then compiling that information
00:04:10.278 --> 00:04:13.935 together because they're both talking about Reedus would allow
00:04:13.935 --> 00:04:17.650 cross referencing and other, you know, in important information
00:04:17.650 --> 00:04:20.669 that makes training documentation that much better.
00:04:21.719 --> 00:04:24.329 Umm, so if we can get that done, that would be awesome.
00:04:26.719 --> 00:04:30.243 Yeah, I think we need to put a proposal together about the
00:04:30.243 --> 00:04:31.199 doing just that.
00:04:30.529 --> 00:04:37.699 I I am bookmarking this damn uh because.
00:04:37.269 --> 00:04:37.509 Yeah.
00:04:37.519 --> 00:04:37.909 There you go.
00:04:39.109 --> 00:04:39.279 Yeah.
00:04:39.579 --> 00:04:40.969 Ohh so this one.
00:04:40.979 --> 00:04:43.139 This little clip was gonna be about ritus.
00:04:43.299 --> 00:04:50.672 Ritis is the software or the I guess service that we use for
00:04:50.672 --> 00:04:53.089 server side caching.
00:04:54.039 --> 00:04:57.109 This allows us to fetch.
00:05:00.389 --> 00:05:05.213 You know, query a database, get the results, store those results
00:05:05.213 --> 00:05:09.815 in Redis, and then when another request comes in for the same
00:05:09.815 --> 00:05:11.299 with the same query.
00:05:12.029 --> 00:05:14.805 If those results have not changed, we're just gonna serve
00:05:14.805 --> 00:05:16.959 up the ones we already have cached in Redis.
00:05:18.009 --> 00:05:18.499 Umm.
00:05:18.689 --> 00:05:23.519 If the results have changed, we're going to reach back out to
00:05:23.519 --> 00:05:28.272 the database, update Redis cache and return the new results,
00:05:28.272 --> 00:05:28.739 right?
00:05:28.749 --> 00:05:29.499 Basically that's.
00:05:29.509 --> 00:05:30.739 That's how it works in a nutshell.
00:05:35.429 --> 00:05:40.679 This is extremely common development server side caching.
00:05:40.689 --> 00:05:47.409 This is something that you know, extremely streamlines our app.
00:05:47.599 --> 00:05:50.309 I think it makes us more efficient.
00:05:50.619 --> 00:05:55.197 It, you know, reduces query time, things like that, right
00:05:55.197 --> 00:05:59.776 makes us more efficient and able to provide a better user
00:05:59.776 --> 00:06:03.959 experience when we can just serve up cached results.
00:06:07.479 --> 00:06:14.569 We do have some custom logic that we have implemented that
00:06:14.569 --> 00:06:22.259 handles updating and determining if we need to pull new results
00:06:22.259 --> 00:06:29.349 from the database and this is wrapped up in our 304 logic.
00:06:29.539 --> 00:06:31.869 The last or the?
00:06:31.919 --> 00:06:35.230 Sorry the the logic with the longest method names in the
00:06:35.230 --> 00:06:35.579 world.
00:06:37.819 --> 00:06:38.399 You're welcome.
00:06:38.259 --> 00:06:41.519 This OK, this is this is how we.
00:06:42.949 --> 00:06:44.139 Implement service like caching.
00:06:47.479 --> 00:06:49.559 To roll through this world where we start at.
00:06:49.569 --> 00:06:50.659 Yeah, is where would you want to start?
00:06:51.359 --> 00:06:55.634 Do do the pricing provider cash of its prices cause that's the
00:06:55.634 --> 00:06:59.706 most simplistic 1 compared to doing the whole like endpoint
00:06:59.706 --> 00:07:00.249 caching.
00:07:01.019 --> 00:07:01.609 OK.
00:07:02.419 --> 00:07:04.179 Pricing providers, which one?
00:07:05.329 --> 00:07:08.109 Uh, the pricing provider or the pricing factory?
00:07:08.959 --> 00:07:09.309 OK.
00:07:10.689 --> 00:07:13.691 For the factory itself is the one that would communicate that
00:07:13.691 --> 00:07:16.693 it needs to store the store the data in the cache and pull it
00:07:16.693 --> 00:07:17.129 back out.
00:07:19.349 --> 00:07:20.789 And has direct calls to do that.
00:07:24.459 --> 00:07:25.339 OK.
00:07:25.789 --> 00:07:27.899 Well, there's the for forced new cache there.
00:07:30.939 --> 00:07:31.749 Where you see that at.
00:07:33.849 --> 00:07:36.779 Uh, scroll back down their line 77.
00:07:35.209 --> 00:07:38.029 Ohh OK yeah, yeah.
00:07:37.609 --> 00:07:39.109 You'll see that in a few places in the file.
00:07:39.869 --> 00:07:40.829 And what does this do?
00:07:42.399 --> 00:07:44.947 Though forced, no cash means basically just bypass the cash
00:07:44.947 --> 00:07:45.329 entirely.
00:07:45.339 --> 00:07:48.765 For what it's gonna do, but if you follow the functions to
00:07:48.765 --> 00:07:52.364 where the four inch snow cache is in use, then you'll see the
00:07:52.364 --> 00:07:55.558 the, the the part that's actually calling the cache to
00:07:55.558 --> 00:07:57.009 actually store something.
00:07:58.259 --> 00:07:58.819 OK.
00:07:59.959 --> 00:08:05.463 So we take our calculate price async takes in our four snow
00:08:05.463 --> 00:08:06.289 cash and.
00:08:09.449 --> 00:08:09.819 Let's see.
00:08:15.869 --> 00:08:20.080 So the pricing factory context is part of the key in memory for
00:08:20.080 --> 00:08:23.896 where you know, what's the difference of this information
00:08:23.896 --> 00:08:28.041 versus another request that came in to do stuff and it figures
00:08:28.041 --> 00:08:31.593 out like if you've got some selected stores selected,
00:08:31.593 --> 00:08:35.409 franchise related brand type stuff, it will apply them to
00:08:35.409 --> 00:08:39.620 your factory context beforehand and then it will pass it off to
00:08:39.620 --> 00:08:43.699 the pricing providers instance of getting a price key for it.
00:08:44.209 --> 00:08:47.585 Not all pricing providers develop keys in the same way,
00:08:47.585 --> 00:08:51.443 because the information that it might be relevant to one is not
00:08:51.443 --> 00:08:52.649 relevant to another.
00:08:53.039 --> 00:08:57.066 For instance, the basic plain Jane flat pricing provider uses
00:08:57.066 --> 00:09:01.223 almost nothing inside of its key besides the product ID itself,
00:09:01.223 --> 00:09:04.926 because flat pricing doesn't care if you're in different
00:09:04.926 --> 00:09:09.213 brands or in different stores or anything like that, because flat
00:09:09.213 --> 00:09:13.240 pricing just reads the one data point from the product itself
00:09:13.240 --> 00:09:14.149 and that's it.
00:09:14.559 --> 00:09:19.719 It doesn't do anything else, so it's pricing key will come back
00:09:19.719 --> 00:09:24.960 with basically just the info of uh, you know the the the pricing
00:09:24.960 --> 00:09:26.089 provider name.
00:09:26.099 --> 00:09:30.067 So we will be flat pricing provider colon P for product
00:09:30.067 --> 00:09:34.107 colon the product that E on it and if you go to the flat
00:09:34.107 --> 00:09:38.713 pricing provider itself go ahead and expand that flat folder and
00:09:38.713 --> 00:09:42.823 then double click on the provider itself the find the git
00:09:42.823 --> 00:09:44.169 price key function.
00:09:44.179 --> 00:09:49.571 There you can see that it Yep, there goes a replies back with a
00:09:49.571 --> 00:09:50.329 P Eagles.
00:09:50.339 --> 00:09:50.669 I'm sorry.
00:09:50.679 --> 00:09:50.869 It was.
00:09:50.879 --> 00:09:55.023 It equals not a colon, so the Cohen is like a direct is like
00:09:55.023 --> 00:09:58.759 the slash of a directory structure for the Redis keys.
00:09:58.949 --> 00:10:01.852 It tells us that this is a folder of stuff, so they'll get
00:10:01.852 --> 00:10:02.689 grouped together.
00:10:03.249 --> 00:10:06.498 Umm So what happens in front that there is it takes the name
00:10:06.498 --> 00:10:09.375 of flat pricing provider so you'll get that part as a
00:10:09.375 --> 00:10:12.837 string, colon P equals and then you'll get the product ID off of
00:10:12.837 --> 00:10:15.979 the product and that's all the flat pricing provider cares
00:10:15.979 --> 00:10:16.299 about.
00:10:17.289 --> 00:10:21.786 If you look at the price rules, get price key async, you'll
00:10:21.786 --> 00:10:23.959 notice it's way more complex.
00:10:23.969 --> 00:10:25.379 There's a lot more to it.
00:10:25.789 --> 00:10:29.611 We're adding in data about categories, about vendor IDs,
00:10:29.611 --> 00:10:33.903 user roles, all kinds of stuff, because all of those things are
00:10:33.903 --> 00:10:37.658 relevant to provide different information and different
00:10:37.658 --> 00:10:39.469 results out of price rules.
00:10:40.349 --> 00:10:44.783 And so it builds this huge key that has a whole ton of stuff on
00:10:44.783 --> 00:10:49.078 it, including today's date and on to that information so that
00:10:49.078 --> 00:10:53.234 it can pass it through as the key for this particular price
00:10:53.234 --> 00:10:57.737 point or price value that we've that we've come up with whatever
00:10:57.737 --> 00:11:02.240 it is and and tiered is the same thing, tiered with fall back is
00:11:02.240 --> 00:11:03.279 the same thing.
00:11:03.289 --> 00:11:03.739 It's it's.
00:11:03.749 --> 00:11:07.686 It's each one has its own relevant information that gets
00:11:07.686 --> 00:11:12.246 put into the key to say this, if the information matches from the
00:11:12.246 --> 00:11:16.252 request, then give back the same result without having to
00:11:16.252 --> 00:11:20.328 calculate it anew, because calculating prices on as tiered
00:11:20.328 --> 00:11:24.058 or price rules can get very computationally expensive
00:11:24.058 --> 00:11:28.133 considering how many different things there are to try and
00:11:28.133 --> 00:11:32.209 arrive at who's supposed to get what, where, when and how.
00:11:32.519 --> 00:11:35.850 Because some of its time base, some of this you know what date
00:11:35.850 --> 00:11:36.749 is it related to?
00:11:36.759 --> 00:11:38.589 Some of it's like are these types of stuff.
00:11:38.599 --> 00:11:42.193 Some of it is like there's a 10% off everyone who has this
00:11:42.193 --> 00:11:43.289 particular vendor.
00:11:43.879 --> 00:11:46.660 So if the product has that vendor ID on it, then it needs
00:11:46.660 --> 00:11:49.633 to get that 10% down and it it's kind of like a discount, but
00:11:49.633 --> 00:11:52.365 really it's factored directly into the main price of the
00:11:52.365 --> 00:11:52.749 product.
00:11:53.059 --> 00:11:56.163 It may all kinds of crazy stuff can happen, so we have these
00:11:56.163 --> 00:11:58.809 keys that build up and they do that stuff in there.
00:11:58.899 --> 00:12:00.669 So let's go ahead and go back to the pricing factory.
00:12:03.119 --> 00:12:04.949 And just to be clear, this works.
00:12:04.959 --> 00:12:07.229 This is how all of Redis works right?
00:12:07.279 --> 00:12:10.459 Like there is a key that is attached to every request.
00:12:08.069 --> 00:12:09.489 Yeah, at.
00:12:12.079 --> 00:12:15.169 Yes, Redis is a is is a no SQL system.
00:12:15.179 --> 00:12:16.289 It is a literally.
00:12:16.299 --> 00:12:18.449 It's like having a giant dictionary.
00:12:18.779 --> 00:12:20.829 The dictionary is a string string.
00:12:21.259 --> 00:12:23.329 It is a string for a key and a string for a value.
00:12:23.339 --> 00:12:24.719 That's all it does.
00:12:25.159 --> 00:12:29.282 Every value that you put into it must have a key that is unique,
00:12:29.282 --> 00:12:32.009 and it must have a value that is a string.
00:12:32.259 --> 00:12:34.531 Or technically it's a byte array, but they're internal
00:12:34.531 --> 00:12:37.175 systems will convert the string into the binary for you, so you
00:12:37.175 --> 00:12:39.529 don't have to actually do convert the bytes to yourself.
00:12:40.129 --> 00:12:43.623 Umm, the advantage to that is that because it is so simple,
00:12:43.623 --> 00:12:47.233 the only thing you have to do to get something back out is to
00:12:47.233 --> 00:12:48.339 know the key of it.
00:12:48.639 --> 00:12:52.051 So by getting the key together and saying give me what value
00:12:52.051 --> 00:12:55.406 you have for this key and it gets back whatever that might,
00:12:55.406 --> 00:12:57.699 array gets converted back into a string.
00:12:57.849 --> 00:13:00.819 Or you could tell it to automatically deserialize into a
00:13:00.819 --> 00:13:03.632 particular class if it's supposed to be like Jason or
00:13:03.632 --> 00:13:06.810 serialized data of a particular class, you could supply that
00:13:06.810 --> 00:13:10.145 information to the cache and say and it will just come back and
00:13:10.145 --> 00:13:13.323 give that to you in memory in the format that you needed for
00:13:13.323 --> 00:13:15.459 what you what you sent and what you got.
00:13:16.079 --> 00:13:19.985 And if it doesn't have a value, it can throw back a null and
00:13:19.985 --> 00:13:21.009 then you can go.
00:13:21.019 --> 00:13:23.349 Ohh, how do I just give a null back?
00:13:23.359 --> 00:13:25.009 Or do I need to go calculate what?
00:13:25.019 --> 00:13:27.990 More info and that will depend on what you're using the cache
00:13:27.990 --> 00:13:30.769 for and how you're calling it and the pricing cache case.
00:13:30.779 --> 00:13:33.706 If it's got, it comes back with a null, then it knows that it
00:13:33.706 --> 00:13:35.689 needs to calculate the price, so it will.
00:13:35.699 --> 00:13:38.579 It will move on and just calculate the price, store it
00:13:38.579 --> 00:13:41.565 and read this and then reply with the result that it has
00:13:41.565 --> 00:13:42.769 already made in memory.
00:13:43.559 --> 00:13:47.629 Umm, the uh, let's go back over to the pricing factory.
00:13:48.119 --> 00:13:50.339 It's one file to your right of the one you've already got open.
00:13:53.279 --> 00:13:56.139 So you can see there the the price provider key.
00:13:56.319 --> 00:14:00.430 It asks the pricing provider to to make a key off of the
00:14:00.430 --> 00:14:04.829 information of the context and the product and the price key
00:14:04.829 --> 00:14:05.839 must be valid.
00:14:05.849 --> 00:14:10.102 When it came back, it must have a caching timeout time span that
00:14:10.102 --> 00:14:14.094 is greater than zero, meaning that it can't be permanent and
00:14:14.094 --> 00:14:17.889 it must not have prevented with a force snow cache on it.
00:14:18.269 --> 00:14:22.659 And in that case it will say it will then use the price cache to
00:14:22.659 --> 00:14:26.914 physically ask the cache for the information so it goes online
00:14:26.914 --> 00:14:31.102 280 there it says get cached price, it passes in that key and
00:14:31.102 --> 00:14:35.424 then it replies with the default class that we have that stores
00:14:35.424 --> 00:14:39.274 information about resulting prices like calculated price
00:14:39.274 --> 00:14:42.989 which inside of itself has multiple data points on it.
00:14:42.999 --> 00:14:46.064 Because it's a because we have the best price, the MSRP, the
00:14:46.064 --> 00:14:49.330 the sale price and the reduction price, all four of those things
00:14:49.330 --> 00:14:52.395 are are available and we'll store all four of them onto that
00:14:52.395 --> 00:14:53.249 calculated price.
00:14:54.259 --> 00:14:58.124 In there, depending on what your project has set up, if you go
00:14:58.124 --> 00:15:02.050 and look at the get cashed price async, we'll click on that and
00:15:02.050 --> 00:15:02.909 then go to it.
00:15:12.429 --> 00:15:13.329 Her F-12.
00:15:13.339 --> 00:15:15.499 8 or or double click on the on the little window.
00:15:15.509 --> 00:15:17.089 What are you gonna do to go over to it?
00:15:20.399 --> 00:15:21.009 There you go.
00:15:21.279 --> 00:15:26.469 You can see here it's pulling a client out of Redis.
00:15:26.659 --> 00:15:30.055 I'm sorry out of the registry, the structure map registry and
00:15:30.055 --> 00:15:33.614 the client, it's going to get is going to be the reddest 1 cause
00:15:33.614 --> 00:15:36.681 the only one in there we originally did have memory one
00:15:36.681 --> 00:15:40.077 as well, but if the app pool dies the memory is lost in every
00:15:40.077 --> 00:15:43.308 key that was in it is lost, which means that if the server
00:15:43.308 --> 00:15:46.375 goes down, everyone's sessions gone, all the previously
00:15:46.375 --> 00:15:47.689 calculated data is gone.
00:15:47.699 --> 00:15:49.249 Everything, so that's not a good thing.
00:15:51.809 --> 00:15:54.860 But So what we have at talking to Rita so that it can be a
00:15:54.860 --> 00:15:56.929 permanent store in a separate location.
00:15:57.579 --> 00:16:01.689 Umm for stuff it does a client dot git async and it we're
00:16:01.689 --> 00:16:06.153 providing it with an alligator clips of a type of a calculated
00:16:06.153 --> 00:16:10.475 price that's nullable, so that with that key if it can get a
00:16:10.475 --> 00:16:14.868 result back then it will give back the results in that format
00:16:14.868 --> 00:16:15.789 as the class.
00:16:16.059 --> 00:16:18.711 That way you don't have to worry about deserializing yourself,
00:16:18.711 --> 00:16:21.236 it's just all handled right there conveniently for you, and
00:16:21.236 --> 00:16:23.720 if an exception occurs, then we're returning a null at the
00:16:23.720 --> 00:16:25.319 bottom there after logging the error.
00:16:26.099 --> 00:16:29.855 Uh on it and and in the case of the pricing factory, it's gonna
00:16:29.855 --> 00:16:32.906 just go on and, like, recalculate the price for you
00:16:32.906 --> 00:16:35.019 and try to store it again on there.
00:16:36.449 --> 00:16:39.734 So if you hit back so that we're back over where the function
00:16:39.734 --> 00:16:43.073 was, which looks like it's just right below it, so we can just
00:16:43.073 --> 00:16:45.669 scroll right back up since we had a price cache.
00:16:45.709 --> 00:16:50.253 And if the base price was not equal to -, 1 negative one is a
00:16:50.253 --> 00:16:52.159 known known known failure.
00:16:52.509 --> 00:16:56.109 If somehow a known failure got stored inside the inside Redis,
00:16:56.109 --> 00:16:57.709 then we won't try to use it.
00:16:58.169 --> 00:16:59.999 We'll go on and we'll try to recalculate it again.
00:17:00.289 --> 00:17:03.613 But if we don't have a known bad, then we'll return the
00:17:03.613 --> 00:17:06.759 calculated price because it should be it known good.
00:17:06.769 --> 00:17:08.249 At that point, it's not Knoll.
00:17:08.319 --> 00:17:10.975 It doesn't have a -, 1, which means it must have some kind of
00:17:10.975 --> 00:17:11.489 valid price.
00:17:11.719 --> 00:17:15.109 That was in the cache for the within the time frame of the
00:17:15.109 --> 00:17:18.843 cache of being allowed to exist and should reply with that value
00:17:18.843 --> 00:17:20.969 and outside of that it will go down.
00:17:21.119 --> 00:17:24.163 It'll calculate the price online 287, which it will just do
00:17:24.163 --> 00:17:25.989 inside of each of pricing provider.
00:17:26.079 --> 00:17:27.529 Take that calculated price.
00:17:27.979 --> 00:17:30.249 Double check, you know, is this not null?
00:17:30.759 --> 00:17:32.479 Does it have a pricing provider name on it?
00:17:32.879 --> 00:17:36.339 If it doesn't, then give it a, give it the name because we know
00:17:36.339 --> 00:17:38.069 what the name is supposed to be.
00:17:38.759 --> 00:17:41.919 We double check another validation state on it and then
00:17:41.919 --> 00:17:45.417 if it is supposed to use the price cache then it will say add
00:17:45.417 --> 00:17:48.633 cached price async which is going to put that price with
00:17:48.633 --> 00:17:52.357 that key into the cache which is going to automatically serialize
00:17:52.357 --> 00:17:56.081 that calculator price into Jason and throw it in there so that we
00:17:56.081 --> 00:17:57.209 can recall it later.
00:17:58.199 --> 00:18:03.128 If you want to look at the git or the ad cached price async
00:18:03.128 --> 00:18:05.099 then you could see here.
00:18:05.109 --> 00:18:08.295 All it does is we pull the the cache client out of the the
00:18:08.295 --> 00:18:11.750 registry and then we really just call it client add, we give it
00:18:11.750 --> 00:18:15.098 the key, we give it the object, we tell it to use the prefix,
00:18:15.098 --> 00:18:18.445 which is means that it needs to use like the websites info so
00:18:18.445 --> 00:18:21.631 that we could have multiple websites inside the same Redis
00:18:21.631 --> 00:18:25.194 instance, but they won't step on each others toes to try to write
00:18:25.194 --> 00:18:28.758 to each other as brace cache and then we give it the time to live
00:18:28.758 --> 00:18:31.997 which is the caching timeout time span which by default out
00:18:31.997 --> 00:18:32.969 of box is 2 hours.
00:18:33.679 --> 00:18:36.355 So for two hours this will live inside the Redis cache and I'm
00:18:36.355 --> 00:18:37.799 sorry it's one hour in this case.
00:18:39.629 --> 00:18:43.593 So for an hour, unless the the setting is overridden, the the
00:18:43.593 --> 00:18:47.748 data will stay inside Redis and Redis automatically pulls itself
00:18:47.748 --> 00:18:48.579 every second.
00:18:48.869 --> 00:18:53.055 So at the end of the number of seconds that for that time to
00:18:53.055 --> 00:18:57.035 live have occurred, it will delete that value out of its,
00:18:57.035 --> 00:19:00.329 uh, out of itself in Redis and clean itself up.
00:19:00.859 --> 00:19:04.376 And by doing that, that allows the cache to become invalid and
00:19:04.376 --> 00:19:07.782 therefore forcibly you have to go recreate the value because
00:19:07.782 --> 00:19:10.629 it's not there to be called anymore on that stuff.
00:19:10.849 --> 00:19:14.559 All of Reedus functions that way no matter what we put in there
00:19:14.559 --> 00:19:18.211 is going to be going in with a time to live a key and a string
00:19:18.211 --> 00:19:21.979 or byte array value of whatever it is, and convenience functions
00:19:21.979 --> 00:19:24.994 allow us to automatically serialize and deserialize
00:19:24.994 --> 00:19:28.646 particular object types for for that information, so that it's
00:19:28.646 --> 00:19:29.689 really convenient.
00:19:35.669 --> 00:19:36.169 Questions.
00:19:36.179 --> 00:19:36.729 Comments. Concerns.
00:19:38.229 --> 00:19:39.919 Cause the other stuff is a lot more complicated.
00:19:40.729 --> 00:19:41.049 In.
00:19:41.209 --> 00:19:43.669 Yeah, that's uh, no.
00:19:50.349 --> 00:19:54.950 It's interesting, like I didn't realize how it worked really
00:19:54.950 --> 00:19:56.609 under the hood, right?
00:19:58.249 --> 00:19:58.809 Yeah.
00:19:58.899 --> 00:20:02.031 And then the so like the read is can be on your local or it can
00:20:02.031 --> 00:20:03.059 be on another server.
00:20:03.319 --> 00:20:07.462 The Redis cache client that we have set up is gonna read the
00:20:07.462 --> 00:20:11.741 excuse me, read the settings and determine where is radius and
00:20:11.741 --> 00:20:15.952 how do we talk to it and then just it just communicates to it
00:20:15.952 --> 00:20:20.230 over port 6379 by default for that information and Redis is is
00:20:20.230 --> 00:20:21.249 extremely fast.
00:20:21.259 --> 00:20:23.579 Extremely simple.
00:20:23.669 --> 00:20:27.676 It was originally written for Linux, and it's continued to be
00:20:27.676 --> 00:20:31.619 written for Linux this today, but what we use primarily is a
00:20:31.619 --> 00:20:35.755 Windows port of it that someone made and actually posted to the
00:20:35.755 --> 00:20:39.892 Microsoft GitHub so that we can have a Windows installer for it
00:20:39.892 --> 00:20:43.899 and not have to, like set up a Linux box specifically for it.
00:20:44.329 --> 00:20:48.962 Ben, however, is also setting up and starting to work with Docker
00:20:48.962 --> 00:20:53.454 images that are Linux based so that we can just run the regular
00:20:53.454 --> 00:20:55.419 latest version of of Reedus.
00:20:55.649 --> 00:20:58.405 Uh, where, you know, they they've optimized the algorithms
00:20:58.405 --> 00:21:01.162 and things for like pulling different kinds of data in and
00:21:01.162 --> 00:21:01.629 out of it.
00:21:02.019 --> 00:21:06.096 Umm, you know, structured data that's coming in a certain way,
00:21:06.096 --> 00:21:09.655 storing information with different kinds of values and
00:21:09.655 --> 00:21:13.408 tags and other stuff that's beyond just the straight, you
00:21:13.408 --> 00:21:17.161 know, key value setup in there and then you know all that
00:21:17.161 --> 00:21:17.549 stuff.
00:21:17.559 --> 00:21:20.859 So we can theoretically talk to newer versions of Redis and they
00:21:20.859 --> 00:21:23.549 work great because they're faster and more reliable.
00:21:24.509 --> 00:21:28.490 You know, fewer, fewer places where where the read is code
00:21:28.490 --> 00:21:32.336 itself breaks on their end in that stuff, but that's the
00:21:32.336 --> 00:21:36.519 simplified version of of talking to Rita storing information.
00:21:36.529 --> 00:21:39.977 If you ever need to storage formation yourself, all you
00:21:39.977 --> 00:21:43.486 gotta do is just create a consistent key to use, push it
00:21:43.486 --> 00:21:47.426 into the cache client, and then you can call it out later up to
00:21:47.426 --> 00:21:50.319 the point where the cache time to live occurs.
00:21:51.029 --> 00:21:55.693 We do this several times inside of CMMC because we have some
00:21:55.693 --> 00:22:00.662 access tokens that are that have like a 10 hour time to live for
00:22:00.662 --> 00:22:05.479 communicating with some of the third party services for Oauth.
00:22:06.349 --> 00:22:09.724 So we'll we'll send out a request, we'll get an access
00:22:09.724 --> 00:22:10.399 token back.
00:22:10.889 --> 00:22:14.448 We'll store that access token and Redis for 10 hours and then
00:22:14.448 --> 00:22:18.006 all of our other requests to the API will include that access
00:22:18.006 --> 00:22:21.508 token as a header by calling it out a Redis for 10 hours and
00:22:21.508 --> 00:22:25.009 then suddenly the token will disappear from Redis and go oh,
00:22:25.009 --> 00:22:28.453 I need a new token and I'm actually ask for a new token and
00:22:28.453 --> 00:22:31.839 start again and the cycle continues on that kind of thing.
00:22:31.849 --> 00:22:35.175 So we have that in several places since I've CMMC and
00:22:35.175 --> 00:22:37.269 that's a very common thing to do.
00:22:37.279 --> 00:22:39.329 It's just throw a little bit of data in there.
00:22:39.479 --> 00:22:42.852 One of the other locations that we might do that kind of thing
00:22:42.852 --> 00:22:45.529 would be like the ID resolver that Brendan built.
00:22:46.019 --> 00:22:48.842 Instead of storing that information in memory, we could
00:22:46.369 --> 00:22:46.549 Yeah.
00:22:48.842 --> 00:22:51.817 actually push it into Redis and then read it in and out of
00:22:51.817 --> 00:22:52.119 Redis.
00:22:52.299 --> 00:22:56.137 However, I believe the overhead cost of that might be a little
00:22:56.137 --> 00:23:00.036 more than it would probably be worth, just because we're trying
00:23:00.036 --> 00:23:03.570 to, we're trying to store is a number and that number can
00:23:03.570 --> 00:23:07.225 easily be recovered the next time the app will restarts and
00:23:07.225 --> 00:23:10.880 it's not affecting anything other than the initial call for
00:23:10.880 --> 00:23:12.769 that information on that stuff.
00:23:12.779 --> 00:23:16.056 So it's generally speaking, you know, probably pretty simple to
00:23:16.056 --> 00:23:19.281 just leave that on storing those memory values in a dictionary
00:23:19.281 --> 00:23:22.148 and memory inside the ID resolver versus trying to turn
00:23:22.148 --> 00:23:23.889 it all into Reedus communication.
00:23:24.059 --> 00:23:27.423 But if we were having a problem with that and we needed to do
00:23:27.423 --> 00:23:30.408 something that was more consistent, like maybe we were
00:23:30.408 --> 00:23:33.447 behind a load balancer, there were two separate servers
00:23:33.447 --> 00:23:36.757 physically processing requests for us, Redis being the third
00:23:36.757 --> 00:23:40.067 party separate instance where both of those in both of those
00:23:40.067 --> 00:23:42.509 SEF instances are talking to the same Redis.
00:23:42.939 --> 00:23:46.844 They now are aware of the same session info, the same prices,
00:23:46.844 --> 00:23:47.789 all that stuff.
00:23:47.799 --> 00:23:51.214 They don't have to recalculate them because they were stored in
00:23:51.214 --> 00:23:54.469 that Redis state machine of storing all of that information.
00:23:59.559 --> 00:23:59.719 Yeah.
00:24:00.139 --> 00:24:07.619 Umm, So what is the 304 lodge and what?
00:24:06.029 --> 00:24:06.399 Oh God.
00:24:07.629 --> 00:24:08.959 What just.
00:24:08.439 --> 00:24:08.789 Oh God.
00:24:09.609 --> 00:24:10.769 Umm, OK.
00:24:10.959 --> 00:24:13.493 So three or four, believe it or not, actually has nothing to do
00:24:13.493 --> 00:24:13.929 with Redis.
00:24:13.939 --> 00:24:15.689 It actually has to do with browser caching.
00:24:15.789 --> 00:24:19.319 There's actually a layer before that that is the Redis cache.
00:24:16.249 --> 00:24:16.729 OK.
00:24:19.439 --> 00:24:25.203 So what the Redis cache does on an endpoint is let's go over to
00:24:25.203 --> 00:24:30.877 the like Git product by SEO URL endpoint because that's a good
00:24:30.877 --> 00:24:33.939 one that's overridden that I can.
00:24:34.029 --> 00:24:37.089 We can look at directly and control T is your friend.
00:24:42.909 --> 00:24:44.869 You had mask case and I don't think it matches that case.
00:24:45.699 --> 00:24:49.829 Yeah, I don't the control TI don't have that hockey set up.
00:24:49.899 --> 00:24:50.969 We ran into that before.
00:24:52.309 --> 00:24:52.679 Uh.
00:24:52.689 --> 00:24:55.977 Then in the search menu where it's got the control queue type,
00:24:55.977 --> 00:24:56.499 go to all.
00:24:59.049 --> 00:24:59.479 At the top.
00:25:01.909 --> 00:25:02.579 Top center.
00:25:03.189 --> 00:25:04.859 Yep, the type go to all.
00:25:03.349 --> 00:25:03.529 Yeah.
00:25:05.029 --> 00:25:05.559 There it is.
00:25:05.779 --> 00:25:11.331 You do have control to on it as the hot key, but yeah, and so
00:25:07.779 --> 00:25:09.269 It says that, but it doesn't work.
00:25:11.331 --> 00:25:15.629 inside inside Dara type Git product by SEO URL.
00:25:18.549 --> 00:25:19.179 There it goes.
00:25:19.839 --> 00:25:20.779 And there's our to the class.
00:25:24.559 --> 00:25:25.869 That is the implementation you want.
00:25:25.879 --> 00:25:27.839 The usage is or references.
00:25:32.729 --> 00:25:34.149 So you want the second one there?
00:25:38.569 --> 00:25:39.489 Uh, we don't want.
00:25:38.889 --> 00:25:40.589 And with this one right.
00:25:39.499 --> 00:25:40.299 We don't care about that one.
00:25:41.649 --> 00:25:42.359 Uh, yeah.
00:25:42.369 --> 00:25:42.709 OK.
00:25:42.889 --> 00:25:49.849 So umm, the layer in between.
00:25:49.859 --> 00:25:54.866 So before I hit it implemented the 304 logic so that browsers
00:25:54.866 --> 00:25:59.711 could cache information we just had it where every time you
00:25:59.711 --> 00:26:04.234 wanted to make a request to the server on, you know get
00:26:04.234 --> 00:26:09.079 endpoints or or whatever the like, you went to the project.
00:26:09.089 --> 00:26:10.970 Let's say you went to the product details page in the
00:26:10.970 --> 00:26:11.249 browser.
00:26:12.039 --> 00:26:15.715 The party just page is gonna figure out what the SEO URL of
00:26:15.715 --> 00:26:19.759 the product is from the from out of the URL and send a request to
00:26:19.759 --> 00:26:22.149 the server asking who is this product.
00:26:22.219 --> 00:26:22.949 Does this?
00:26:22.959 --> 00:26:27.175 Does this URL actually exist or was it a typo that somebody made
00:26:27.175 --> 00:26:30.613 so that I should give a 404 instead if it comes back
00:26:30.613 --> 00:26:34.699 successfully that and gives an ID number back the server that.
00:26:35.079 --> 00:26:37.209 Sorry, the browser will then reply.
00:26:38.089 --> 00:26:41.729 Uh, with I'm sorry we let me back this up a little bit.
00:26:43.079 --> 00:26:47.289 You open the bridge inside a browser like Chrome.
00:26:48.279 --> 00:26:53.125 The browsers JavaScript is going to figure out the SEO URL of the
00:26:53.125 --> 00:26:57.531 product and then ask the server if this SEO URL is valid by
00:26:57.531 --> 00:27:02.009 saying check exists by SEO URL under the product section the
00:27:02.009 --> 00:27:06.415 server internally if it had not had this request within the
00:27:06.415 --> 00:27:10.820 caching time to live is going to calculate this information
00:27:10.820 --> 00:27:15.079 determine an ID number, store their body of the response.
00:27:16.049 --> 00:27:22.439 Umm into Redis and give it a key that is basically the equivalent
00:27:22.439 --> 00:27:24.279 of the request URL.
00:27:24.339 --> 00:27:28.515 Well, possibly with query string parameters and type type stuff
00:27:28.515 --> 00:27:32.429 kind of serialized into the key so that it can rearrange at
00:27:32.429 --> 00:27:35.039 that, sending me information each time.
00:27:35.539 --> 00:27:35.769 Uh.
00:27:36.869 --> 00:27:43.102 Uh, for for the response and the body of the request being
00:27:43.102 --> 00:27:45.849 serialized into that read.
00:27:45.859 --> 00:27:48.848 This value will happen in a couple of different ways, so you
00:27:48.848 --> 00:27:51.886 will actually end up with like 3 or 4 keys depending on which
00:27:51.886 --> 00:27:53.209 version of stuff you're on.
00:27:54.379 --> 00:27:58.271 The first boost basic key is just the same thing that you
00:27:58.271 --> 00:27:59.949 would see in the browser.
00:27:59.959 --> 00:28:03.411 You would see the serialized body of the response with it,
00:28:03.411 --> 00:28:05.459 with the with the ID number in it.
00:28:06.049 --> 00:28:07.839 Umm, uh.
00:28:07.949 --> 00:28:09.899 And you would see the same thing inside Redis.
00:28:10.319 --> 00:28:14.899 There would also be a dot JSON key.
00:28:15.449 --> 00:28:16.319 That's basically it's.
00:28:16.329 --> 00:28:21.062 It's identical key, but don't say dot Jason at the end and
00:28:21.062 --> 00:28:25.714 then the body of that one is that thing wrapped as a JSON
00:28:25.714 --> 00:28:27.719 element in there as well.
00:28:28.329 --> 00:28:32.697 Then there will be another one that says dot Jason dot deflate
00:28:32.697 --> 00:28:36.787 deflate is the compression algorithm that service desk has
00:28:36.787 --> 00:28:38.659 access to as well as G zip.
00:28:38.729 --> 00:28:41.536 It is not have access to broadly unfortunately, because it's too
00:28:41.536 --> 00:28:41.709 old.
00:28:43.039 --> 00:28:46.478 The newest versions of service Tech that are on net core do
00:28:46.478 --> 00:28:50.203 have access to broadly, and that DEFLATE is going to look insane
00:28:50.203 --> 00:28:51.349 when you look at it.
00:28:51.359 --> 00:28:55.288 It's like did cathulu enter my brain when you're looking at it
00:28:55.288 --> 00:28:58.594 because it's got a bunch of diamonds and squares and
00:28:58.594 --> 00:28:59.529 question marks.
00:28:59.539 --> 00:29:01.869 And who knows what other characters inside of it?
00:29:02.039 --> 00:29:03.199 It will just look insane.
00:29:03.829 --> 00:29:07.396 Uh, when you're looking at it, that is because the byte array
00:29:07.396 --> 00:29:10.561 is what it got put into there, but it's the compressed
00:29:10.561 --> 00:29:13.956 characters of what your final response would be, no matter
00:29:13.956 --> 00:29:17.638 what the response was supposed to originally be, it will do the
00:29:17.638 --> 00:29:20.688 deflated, which is the compressed version of it, and
00:29:20.688 --> 00:29:22.759 store that inside of Redis as well.
00:29:23.149 --> 00:29:27.319 The goal being that compression itself has a CPU cost to it, so
00:29:27.319 --> 00:29:31.358 when you're sending information back out and you're trying to
00:29:31.358 --> 00:29:34.681 provide that that that information, Reed is having
00:29:34.681 --> 00:29:38.786 saved the the already compressed means that he doesn't have to
00:29:38.786 --> 00:29:42.239 recompress the response every time and reply to you.
00:29:43.089 --> 00:29:43.899 It's already got it.
00:29:43.949 --> 00:29:46.152 The the byte array that it would send, and so it literally just
00:29:46.152 --> 00:29:48.149 streams it right out of Redis and sends it over the wire.
00:29:48.959 --> 00:29:49.489 Umm.
00:29:49.589 --> 00:29:50.599 And saves you that time.
00:29:50.609 --> 00:29:54.478 So that's why you're gonna see that now the double deflate
00:29:54.478 --> 00:29:58.675 thing that you're showing right there open that in a Mac or iOS
00:29:58.675 --> 00:30:02.741 Safari browser and you'll see the crazy deflate stuff because
00:30:02.741 --> 00:30:04.839 of the the problem exists there.
00:30:05.709 --> 00:30:09.803 If you wanna try to log into Lambda test and open a Mac
00:30:09.803 --> 00:30:11.119 instance in there.
00:30:11.939 --> 00:30:15.151 Umm you should be able to replicate that, that same spot
00:30:15.151 --> 00:30:16.109 and see it there.
00:30:16.419 --> 00:30:19.136 It doesn't do it every time because the way that it is, it's
00:30:19.136 --> 00:30:21.897 inconsistent with the problem, but that it's a bug that we've
00:30:21.897 --> 00:30:24.702 been working on trying to fix and make sure that it doesn't do
00:30:24.702 --> 00:30:26.439 that anymore with the latest versions.
00:30:26.739 --> 00:30:29.529 I've actually now backported it all the way to BOP.
00:30:29.599 --> 00:30:30.779 Who was on 4.7?
00:30:31.569 --> 00:30:36.156 You know, before the 2018 renumbering of stuff, we have an
00:30:36.156 --> 00:30:38.099 actual account with them.
00:30:39.329 --> 00:30:43.609 Umm that is paid and it's that Craig one right there.
00:30:43.679 --> 00:30:46.229 So if you click, it's behind your Gray menu.
00:30:46.269 --> 00:30:48.079 It's on in the LastPass is getting it to you.
00:30:48.089 --> 00:30:48.209 There.
00:30:49.509 --> 00:30:49.899 There you go.
00:30:52.609 --> 00:30:53.059 Yeah.
00:30:53.069 --> 00:30:53.849 So then go into.
00:30:54.689 --> 00:30:58.769 Umm, real time I think.
00:31:04.169 --> 00:31:08.287 Uh Yep, browser testing and then you need to pick Safari and then
00:31:04.369 --> 00:31:05.509 Those your testing.
00:31:08.287 --> 00:31:11.906 you gotta Mac and then you doesn't matter what the screen
00:31:11.906 --> 00:31:13.279 res is and then start.
00:31:14.039 --> 00:31:15.199 I'm sorry, I think you do have to.
00:31:16.849 --> 00:31:20.038 Would you get in there going to put the URL in here and that
00:31:20.038 --> 00:31:21.449 actually has the URL twice?
00:31:21.459 --> 00:31:25.267 So you want to remove the second one because the second URL is
00:31:25.267 --> 00:31:25.509 bad.
00:31:27.699 --> 00:31:28.289 Yeah.
00:31:28.299 --> 00:31:29.769 So I am scared.
00:31:28.409 --> 00:31:31.564 At SEO URL is 3 characters to the right of where your cursor
00:31:31.564 --> 00:31:31.719 is.
00:31:33.469 --> 00:31:33.839 But here.
00:31:34.969 --> 00:31:35.379 Yeah.
00:31:35.419 --> 00:31:36.139 So starting right.
00:31:37.449 --> 00:31:40.532 Yeah, go the other direction to go and get rid of the present
00:31:40.532 --> 00:31:41.029 and enter.
00:31:48.519 --> 00:31:50.069 I don't think the control a worked.
00:31:50.669 --> 00:31:54.579 Ohh and did not later on this again.
00:32:03.069 --> 00:32:04.099 Then get your dev tools open.
00:32:06.729 --> 00:32:08.219 Right click on the page and inspect, yeah.
00:32:12.349 --> 00:32:14.891 And then I think you have to refresh the page because you're
00:32:14.891 --> 00:32:15.599 not gonna see it.
00:32:15.979 --> 00:32:18.239 It doesn't record unless the thing's there.
00:32:19.689 --> 00:32:21.079 Yeah, it's in the bar on the right side.
00:32:28.019 --> 00:32:32.340 So instead of all on that little drop down next to the filter
00:32:32.269 --> 00:32:32.649 Because.
00:32:32.340 --> 00:32:34.709 bar, you can say fetch extent TR.
00:32:38.009 --> 00:32:39.849 Umm, go ahead and refresh again.
00:32:42.289 --> 00:32:42.959 So I don't see.
00:32:47.609 --> 00:32:49.988 Uh, looks like you've actually just got straight up like errors
00:32:49.988 --> 00:32:51.549 like click on the click on the stop sign.
00:32:56.769 --> 00:32:57.189 Not fair.
00:32:57.479 --> 00:32:58.789 Invalid regular expression.
00:32:58.799 --> 00:32:59.409 Invalid group.
00:32:59.419 --> 00:33:00.279 Specify our name.
00:33:01.119 --> 00:33:04.419 Click on the CEF store dot JS colon one over there.
00:33:06.409 --> 00:33:09.529 Hopefully we can see where that regex is done.
00:33:10.859 --> 00:33:12.279 So this is one of the problems with with.
00:33:12.289 --> 00:33:15.287 This is with Safari is they have a crappier invitation of the
00:33:15.287 --> 00:33:17.269 regex engine that does not work as well.
00:33:17.499 --> 00:33:20.784 So if there's a custom regex that's been written, umm, in
00:33:20.784 --> 00:33:22.709 something, it may not work right?
00:33:23.739 --> 00:33:27.243 And you have to replace all of the the all of them with the
00:33:27.243 --> 00:33:30.863 version that you type in as a new regex, and then you pass in
00:33:30.863 --> 00:33:33.549 the thing as a string to it to make it happy.
00:33:34.679 --> 00:33:36.389 And it looks like a couple of those.
00:33:35.309 --> 00:33:38.002 And I don't know how we're gonna find it in this minified
00:33:38.002 --> 00:33:38.699 version, right?
00:33:38.959 --> 00:33:40.209 Yeah, I don't know either.
00:33:40.219 --> 00:33:42.999 So you'll someone will have someone on the front end.
00:33:43.009 --> 00:33:44.149 Team will have to worry about that.
00:33:44.519 --> 00:33:47.203 We can't get what we need out of this right now, so it's just
00:33:45.969 --> 00:33:46.189 Yeah.
00:33:47.203 --> 00:33:47.939 exit out of this.
00:33:49.989 --> 00:33:52.459 Go back to the yeah.
00:33:52.729 --> 00:33:53.119 OK.
00:33:53.209 --> 00:33:55.259 So it's the store.
00:33:55.269 --> 00:33:57.615 Those three set three, maybe four separate keys in there
00:33:57.615 --> 00:33:59.879 depending on which version of stuff you're looking at.
00:34:00.299 --> 00:34:03.129 Umm, of that information into Redis?
00:34:03.299 --> 00:34:04.149 And then what?
00:34:04.159 --> 00:34:06.709 Our server was doing was going.
00:34:06.719 --> 00:34:09.329 Do you have valid Redis cache value?
00:34:09.399 --> 00:34:14.446 And if you do serve that back as the reply that's part of why all
00:34:14.446 --> 00:34:19.034 of the endpoints have a reply type of task object nullable,
00:34:19.034 --> 00:34:22.169 not the type that is the actually there.
00:34:22.619 --> 00:34:26.928 Because when you do a, the Redis reply out of the Redis cache, it
00:34:26.928 --> 00:34:30.780 is not the same object type because it's gonna reply where
00:34:30.780 --> 00:34:34.109 they with a quote unquote compressed result class.
00:34:35.079 --> 00:34:36.799 That service stack provides?
00:34:37.649 --> 00:34:40.489 Umm, so it's gonna do all that stuff.
00:34:40.499 --> 00:34:42.179 That's that instead of the original one.
00:34:42.189 --> 00:34:44.219 That's why you have the task object and not the original.
00:34:44.339 --> 00:34:48.039 If you don't do that, you can't reply correctly because it'll
00:34:48.039 --> 00:34:51.858 throw that it's the wrong type on what trying to reply with, or
00:34:49.849 --> 00:34:50.709 Umm can you go?
00:34:51.858 --> 00:34:55.199 it won't even compile saying that it's gonna freak out.
00:34:55.329 --> 00:34:56.499 So that's why that's there.
00:34:57.169 --> 00:35:01.344 Now all of that part behaves the same way that we've talked about
00:35:01.344 --> 00:35:05.203 with the price cash, it's going to build a key that a key is
00:35:05.203 --> 00:35:09.062 gonna be relevant information off of the URL off of possibly
00:35:09.062 --> 00:35:12.921 the user roles or some other things about their cookies that
00:35:12.921 --> 00:35:14.629 are for their session data.
00:35:15.179 --> 00:35:19.565 It depends on the endpoint and what was told to be built to
00:35:19.565 --> 00:35:24.097 vary the responses on umm for it and then it will it will ask
00:35:24.097 --> 00:35:28.702 Redis for that for that key and if it can supply a result then
00:35:28.702 --> 00:35:32.576 it will just stream that information directly out of
00:35:32.576 --> 00:35:36.889 Reedus through service stack over the wire to the browser.
00:35:37.929 --> 00:35:40.879 It it possible and if not, it's no big deal.
00:35:40.969 --> 00:35:41.679 It goes in.
00:35:41.689 --> 00:35:45.900 It calculates the information, stores that information as a
00:35:45.900 --> 00:35:50.181 response into Redis with that key, and then replies with the
00:35:50.181 --> 00:35:53.199 information that is already got in memory.
00:35:53.729 --> 00:35:57.109 It doesn't store it and then reply with reason.
00:35:57.119 --> 00:36:00.019 It just uses what it already has a memory for performance
00:36:00.019 --> 00:36:00.419 reasons.
00:36:03.079 --> 00:36:07.776 Now, in 20 late 2019, early 2020, I believe is when I
00:36:07.776 --> 00:36:12.995 implemented the three oh fours, 30 fours is another step of
00:36:12.995 --> 00:36:16.039 caching that I added on top of it.
00:36:16.429 --> 00:36:20.804 The goal being that every time you load this page and it has to
00:36:20.804 --> 00:36:23.539 ask the server does this SEO URL exist?
00:36:24.639 --> 00:36:30.153 Umm well, that that's everyone's browser asking this every time
00:36:30.153 --> 00:36:31.359 three or four.
00:36:31.369 --> 00:36:35.468 Caching allows the browser to know that it has asked this
00:36:35.468 --> 00:36:36.599 question before.
00:36:36.969 --> 00:36:41.118 If it has and say I already know that what that this information
00:36:41.118 --> 00:36:45.202 is valid because I got it from you within the last five minutes
00:36:45.202 --> 00:36:48.649 and I don't even have to ask the server for it again.
00:36:49.819 --> 00:36:53.816 So I'm going to cast the information locally using the
00:36:53.816 --> 00:36:56.359 last modified date or the E ID on.
00:36:56.369 --> 00:36:59.680 In our case, we use the last modified date on everything, so
00:36:59.680 --> 00:37:02.938 you see how it's got the last modified right before vary on
00:37:02.938 --> 00:37:06.032 those on the response headers there, and it's gonna data
00:37:06.032 --> 00:37:07.769 Saturday the 12th November 2022.
00:37:08.259 --> 00:37:13.579 Right above the very the bottom of the response headers, yeah.
00:37:11.209 --> 00:37:12.179 Down, down, down.
00:37:12.189 --> 00:37:12.549 There you go.
00:37:13.719 --> 00:37:17.739 So that last modified that number, that date stamp is a is
00:37:17.739 --> 00:37:22.099 basically a time stamp and then it asks the server if I were to
00:37:22.099 --> 00:37:26.527 ask you this information, would you have data that is newer than
00:37:26.527 --> 00:37:27.549 this timestamp?
00:37:27.609 --> 00:37:30.049 Yes or no, the server will go.
00:37:30.139 --> 00:37:36.046 Yeah, I would have new info and so I will give you the new info
00:37:36.046 --> 00:37:41.308 and otherwise it will reply 304304 says I don't have new
00:37:41.308 --> 00:37:41.769 info.
00:37:41.779 --> 00:37:43.669 What you have should be correct.
00:37:43.679 --> 00:37:45.219 Just use what you already have.
00:37:46.669 --> 00:37:50.578 So what's going to happen is within 5 minutes, because that's
00:37:50.578 --> 00:37:53.919 the allowed Max age that I have set on the requests.
00:37:54.429 --> 00:37:58.134 It doesn't even ask the server for new info, it just uses what
00:37:58.134 --> 00:38:01.427 it already has and to get a legally split uh page loads
00:38:01.427 --> 00:38:05.074 because it's already got data that is just repeating the same
00:38:05.074 --> 00:38:06.779 requests for after 5 minutes.
00:38:06.789 --> 00:38:10.743 It then says to the server I have this URL with this
00:38:10.743 --> 00:38:11.489 timestamp.
00:38:12.709 --> 00:38:15.498 The server goes, your timestamp is still good because I checked
00:38:15.498 --> 00:38:17.939 my last modified dates and I don't have anything newer.
00:38:18.449 --> 00:38:21.241 I don't even gonna bother building a new request because
00:38:21.241 --> 00:38:22.269 the date is the same.
00:38:23.039 --> 00:38:23.289 Uh.
00:38:23.339 --> 00:38:26.670 Or older and I'm going to and and I'll tell you to use the
00:38:26.670 --> 00:38:30.227 data that you've already got and then the and then the browser
00:38:30.227 --> 00:38:30.509 goes.
00:38:30.519 --> 00:38:33.872 OK, I'm not gonna even bother trying to read a further
00:38:33.872 --> 00:38:34.969 response from you.
00:38:35.099 --> 00:38:36.009 I'll use what I've got.
00:38:36.019 --> 00:38:36.649 Great K.
00:38:36.659 --> 00:38:36.949 Thanks.
00:38:36.959 --> 00:38:37.489 Bye.
00:38:38.099 --> 00:38:40.755 That way the server has saved the processing time of all that
00:38:40.755 --> 00:38:41.269 information.
00:38:41.599 --> 00:38:44.671 Now obviously if the cache is expired or there is a newer
00:38:44.671 --> 00:38:47.849 updated date, it will then go on to process the rest of the
00:38:47.849 --> 00:38:51.186 information of your request of loading the rest of the product
00:38:51.186 --> 00:38:54.682 data or whatever it was supposed to do, and then reply and do all
00:38:54.682 --> 00:38:56.589 the the the standard serialization.
00:38:56.739 --> 00:39:00.069 And now there's a news time stamp to work against that and
00:39:00.069 --> 00:39:02.439 stored inside ritus for this information.
00:39:03.069 --> 00:39:05.733 Also, Tim, the reason you're only seeing full two hundreds as
00:39:05.733 --> 00:39:08.397 you've got the disabled cache box checked up there know if we
00:39:08.397 --> 00:39:09.729 were talking about that or not.
00:39:08.659 --> 00:39:11.699 Umm, I was like, hmm, yeah.
00:39:10.139 --> 00:39:10.299 Yeah.
00:39:11.459 --> 00:39:15.032 And I would preserve log off because that's just gonna make a
00:39:11.609 --> 00:39:12.539 Yeah, that's yeah.
00:39:11.709 --> 00:39:12.909 I was trying to demonstrate it.
00:39:15.032 --> 00:39:17.279 huge log to stuff that you don't need.
00:39:16.669 --> 00:39:17.239 Yeah.
00:39:17.879 --> 00:39:22.433 Yeah, so now you can see over there it says disk cache on some
00:39:22.433 --> 00:39:25.179 of those requests in the size column.
00:39:23.159 --> 00:39:23.299 Yes.
00:39:25.409 --> 00:39:29.107 That's saying that the browser did not actually ask the server
00:39:25.599 --> 00:39:26.029 Here we go.
00:39:29.107 --> 00:39:30.339 for that information.
00:39:30.349 --> 00:39:34.390 It pulled it from its cache and you can see the time that took
00:39:34.390 --> 00:39:37.790 is between zero and one millisecond, which is just a
00:39:37.409 --> 00:39:37.619 Yeah.
00:39:37.790 --> 00:39:40.099 little bit faster, just a tiny bit.
00:39:38.019 --> 00:39:44.059 Yes, just a scosche for that stuff.
00:39:42.209 --> 00:39:43.049 Yeah, so.
00:39:44.329 --> 00:39:48.184 Now, if you were to wait 5 minutes, which I'm not gonna do,
00:39:48.184 --> 00:39:52.104 it would then ask the server at the next time you did a page
00:39:52.104 --> 00:39:55.959 refresh without the disable cache on and after 5 minutes it
00:39:55.959 --> 00:39:59.685 will then ask the server including that last updated date
00:39:59.685 --> 00:40:01.099 or last modified date.
00:40:01.269 --> 00:40:02.219 The server is going to go.
00:40:02.229 --> 00:40:03.379 I don't have anything new.
00:40:03.449 --> 00:40:04.279 Use what you got.
00:40:04.319 --> 00:40:07.411 You'll see your 304 is the response and then the disk cache
00:40:07.411 --> 00:40:09.369 will be the one who serves the reply.
00:40:10.819 --> 00:40:13.856 By loading it up from there again, that saves bits over the
00:40:13.856 --> 00:40:14.109 wire.
00:40:14.119 --> 00:40:18.456 It saves page load time all that stuff for us, and you'll notice
00:40:18.456 --> 00:40:22.193 that generally speaking, all of that automatically gets
00:40:22.193 --> 00:40:25.929 converted to Greenwich Mountain time that you know GMT.
00:40:26.019 --> 00:40:29.631 Your UTC because browsers could be anywhere, it has to
00:40:29.631 --> 00:40:33.310 understand that these are different time zones, that it
00:40:33.310 --> 00:40:37.119 doesn't matter what the time zone is converted to the you
00:40:37.119 --> 00:40:41.060 know plus zero time zone and then compare from that instead
00:40:41.060 --> 00:40:45.066 of trying to figure out you know, other information on stuff
00:40:43.169 --> 00:40:43.399 Yeah.
00:40:44.389 --> 00:40:49.757 As a side note, something that, uh, something that I want to
00:40:45.066 --> 00:40:45.329 now.
00:40:49.757 --> 00:40:51.869 enforce in net core and.
00:40:53.949 --> 00:40:59.547 There has been a pain in the past is I want to get to a point
00:40:59.547 --> 00:41:03.339 where the back end only functions in UTC.
00:41:03.609 --> 00:41:06.479 We only accept UTC timestamps.
00:41:06.489 --> 00:41:09.079 We assume incoming timestamps are UTC.
00:41:09.209 --> 00:41:14.301 We only emit UTC timestamps and the browser side the side that's
00:41:14.301 --> 00:41:19.394 actually knows what time zone a user is in handles conversion to
00:41:19.394 --> 00:41:20.099 and from.
00:41:20.429 --> 00:41:24.228 The reason for that is on every project that actually wants it,
00:41:24.228 --> 00:41:27.374 because we don't do that by default, we assume we by
00:41:27.374 --> 00:41:30.579 enabling the UTC setting, we kind of sort of do that.
00:41:30.589 --> 00:41:32.632 But none of our front end code has been built with that
00:41:32.632 --> 00:41:33.289 assumption, right?
00:41:33.299 --> 00:41:37.310 So front end code will send the users local time zone timestamp
00:41:37.310 --> 00:41:41.446 to the back end and the back end will assume it's UTC because the
00:41:41.446 --> 00:41:45.457 there's no way for the back end to know what time zone users in
00:41:45.457 --> 00:41:49.092 unless we send that information along which is, you know,
00:41:49.092 --> 00:41:50.659 tedious and inconvenient.
00:41:51.079 --> 00:41:54.937 And so I want to get to a point where the back end is time zone
00:41:54.937 --> 00:41:55.479 agnostic.
00:41:55.529 --> 00:41:59.665 It just it takes plus zero times zones for everything and it
00:41:59.665 --> 00:42:03.936 emits plus zero time zones and the client is the one in charge
00:42:03.936 --> 00:42:08.140 of displaying those time stamps in the user's local time zone
00:42:08.140 --> 00:42:12.344 and converting local times back to that plus zero to that UTC
00:42:12.344 --> 00:42:15.259 time stamp when it sends that information.
00:42:15.269 --> 00:42:20.369 Because the back end is going to assume it was, and that's just
00:42:20.369 --> 00:42:25.151 the way that it's going to work because it makes everything
00:42:24.839 --> 00:42:27.644 And we don't have to deal with the time conversion stuff we've
00:42:25.151 --> 00:42:28.179 much, much, much easier when exactly?
00:42:27.644 --> 00:42:29.069 dealt with on multiple projects.
00:42:28.769 --> 00:42:29.249 Yeah.
00:42:29.309 --> 00:42:33.052 Well, we'll we'll have to deal with it, but it will be dealt
00:42:30.309 --> 00:42:30.449 Yeah.
00:42:33.052 --> 00:42:36.917 with in my hope, and my intent is that I'm going to write some
00:42:36.917 --> 00:42:40.721 code on the umm on the front end for Phoenix stuff that we'll
00:42:40.721 --> 00:42:44.464 just handle that conversion for you to and from UTC. And you
00:42:44.464 --> 00:42:45.139 just don't.
00:42:45.149 --> 00:42:48.263 All you have to do is call those methods in the browser, or maybe
00:42:48.263 --> 00:42:48.499 even.
00:42:48.509 --> 00:42:51.453 There's a piece of middle end that tries to do it for you as
00:42:49.919 --> 00:42:50.229 Yeah.
00:42:50.239 --> 00:42:53.568 So so like in the back end where we have data extensions that Gen
00:42:51.453 --> 00:42:52.129 automatically.
00:42:53.568 --> 00:42:56.039 date time, there will be a front end equivalent.
00:42:55.089 --> 00:42:55.249 Yeah.
00:42:56.549 --> 00:42:57.589 Yeah, pretty much, yeah.
00:42:56.699 --> 00:42:57.099 Uh.
00:42:57.509 --> 00:43:00.784 And the and that front end equivalent will always be used,
00:43:00.784 --> 00:43:04.059 no matter where you're touching a date, so that it's safe.
00:43:04.069 --> 00:43:05.769 And we know that it's being converted properly.
00:43:06.109 --> 00:43:06.589 Yeah.
00:43:06.649 --> 00:43:10.038 And then same deal for whenever you receive a date from from the
00:43:10.038 --> 00:43:13.270 back end, there would be one method you can call to pass in a
00:43:13.270 --> 00:43:16.503 known UTC timestamp from the back end and get back a definite
00:43:16.503 --> 00:43:19.579 time stamp in the current users in the browsers time zone.
00:43:20.249 --> 00:43:20.899 Umm.
00:43:21.429 --> 00:43:25.112 And the idea there is that having those utilities as first
00:43:25.112 --> 00:43:28.858 class citizens as something we do everywhere and having the
00:43:28.858 --> 00:43:32.853 back end sort of built with the the the hard and fast rule that
00:43:32.853 --> 00:43:36.911 it's UTC only means that when we get a client like for example I
00:43:36.911 --> 00:43:40.719 believe it's been like PCs bid probably tin bids most of our
00:43:40.719 --> 00:43:44.652 auction clients where time down to the relative minute is very
00:43:44.652 --> 00:43:47.399 important even down to the relative second.
00:43:48.249 --> 00:43:50.129 Umm, we no longer have to go.
00:43:50.139 --> 00:43:52.936 Uh, it's actually kind of a pain to do that and we have to go
00:43:52.936 --> 00:43:55.642 like cherry pick these, you know, tons of different changes
00:43:54.869 --> 00:43:55.089 Yeah.
00:43:55.642 --> 00:43:58.529 from different places and hope that everything works correctly.
00:43:58.819 --> 00:44:01.129 It's not that it's not a problem anymore.
00:44:01.339 --> 00:44:01.989 We can.
00:44:02.299 --> 00:44:05.199 It's just something that it's the way we've always handled
00:44:05.199 --> 00:44:08.149 time in the code base, and it just natively works that way.
00:44:08.159 --> 00:44:09.449 Unless you're doing something though.
00:44:10.229 --> 00:44:10.879 Yeah.
00:44:11.049 --> 00:44:14.862 Now an alternative to the last modified date that the browser
00:44:14.862 --> 00:44:17.199 standard supports is called an E tag.
00:44:17.329 --> 00:44:19.529 An etag is an arbitrary value.
00:44:20.539 --> 00:44:25.364 Umm it you put in like kumquat or you can put in a number or
00:44:25.364 --> 00:44:28.369 you can put in a a series of letters.
00:44:27.569 --> 00:44:29.049 A GUID or even yeah.
00:44:28.379 --> 00:44:31.425 Whatever you need to put into the E tag, as long as that E tag
00:44:31.425 --> 00:44:31.909 is unique.
00:44:31.979 --> 00:44:35.281 Anyone who sees a different value than what that as an E tag
00:44:35.281 --> 00:44:38.311 and stores it and replies with that instead of the last
00:44:38.311 --> 00:44:39.069 modified date.
00:44:39.839 --> 00:44:40.949 The server's gonna go.
00:44:40.959 --> 00:44:43.749 I don't have that E tag or I do have that E tag.
00:44:43.759 --> 00:44:47.479 You're good to go if you don't have the same etag, then you've
00:44:47.479 --> 00:44:49.309 got to get the results out now.
00:44:49.379 --> 00:44:52.329 Generally speaking, the for for convenience.
00:44:52.339 --> 00:44:56.239 What most people do with those E tags is as they change like a
00:44:56.239 --> 00:45:00.138 it's like contents of the the page for the product editor, not
00:45:00.138 --> 00:45:03.914 the product editor, but the party just page when they change
00:45:03.914 --> 00:45:07.443 the template for it, they might update the etag value by
00:45:07.443 --> 00:45:10.909 incrementing it to a new number or something like that.
00:45:10.999 --> 00:45:14.614 That's the common use case, but it's honestly, it's just a lot
00:45:14.614 --> 00:45:18.114 simpler to just use the last modified date, although that is
00:45:18.114 --> 00:45:21.728 a greater number of bytes over the wire to physically transfer
00:45:21.728 --> 00:45:25.286 the entirety of a time stamps versus A versus etec cause your
00:45:22.689 --> 00:45:23.609 A date string, yeah.
00:45:25.286 --> 00:45:28.269 tech could be like as little as three letters. Umm.
00:45:27.689 --> 00:45:32.777 There is also, umm, and we don't really do this, but there's also
00:45:32.777 --> 00:45:37.171 uh cache and validation or caching strategies that don't
00:45:37.171 --> 00:45:40.949 involve intentional and validation, for example.
00:45:40.959 --> 00:45:44.247 It's just saying the browser's allowed to cache this for 10
00:45:44.247 --> 00:45:45.069 minutes period.
00:45:45.459 --> 00:45:46.709 Don't ask if it's fresh.
00:45:46.719 --> 00:45:50.409 Don't care every 10 after 10 minutes, it's stale.
00:45:50.419 --> 00:45:53.516 It's known stale and you can send things like stale while
00:45:53.516 --> 00:45:56.560 revalidating, which means that the browser is allowed to
00:45:56.560 --> 00:45:59.765 present you a stale version of that resource in the browser
00:45:59.765 --> 00:46:00.619 until it's done.
00:46:01.389 --> 00:46:05.019 We can't regaining a revalidated source from the server, but
00:46:05.019 --> 00:46:07.399 otherwise the browser doesn't even ask.
00:46:07.409 --> 00:46:10.639 The server is my copy of this up to date.
00:46:10.989 --> 00:46:12.659 It's just you're telling the browser.
00:46:12.669 --> 00:46:15.029 Yes, it's always gonna be up to date for the next 10 minutes.
00:46:15.039 --> 00:46:19.258 You can freely serve this one up for the next minute, 10 minutes,
00:46:19.258 --> 00:46:22.965 hour, 24 hours, whatever it is, and the browser will just
00:46:22.965 --> 00:46:26.545 continue to serve that original response it got without
00:46:26.545 --> 00:46:30.316 revalidating until, obviously, until that user like clears
00:46:30.316 --> 00:46:33.129 their cache, or until the time has elapsed.
00:46:34.079 --> 00:46:35.959 Umm so that's.
00:46:35.419 --> 00:46:39.214 And one of the advantages of that is no matter how many
00:46:39.214 --> 00:46:43.349 different users are trying to talk to the website server. If
00:46:43.349 --> 00:46:47.822 that cache is the same or in the validation is the same then only
00:46:47.822 --> 00:46:51.481 probably the first couple of them depending? How many
00:46:51.481 --> 00:46:52.769 milliseconds apart.
00:46:52.779 --> 00:46:57.242 They were are going to have to actually cost the server CPU
00:46:57.242 --> 00:47:00.589 cycles and generating that kind of response.
00:47:00.909 --> 00:47:03.119 Everyone else is gonna get served the cache.
00:47:03.129 --> 00:47:06.000 It's gonna go into the browser and it's gonna repeat and all of
00:47:03.319 --> 00:47:03.639 Cash.
00:47:06.000 --> 00:47:08.019 their other browsers until 10 minutes is up.
00:47:07.339 --> 00:47:08.939 Yep. Yeah.
00:47:08.989 --> 00:47:14.464 So that's great for things like uh, uh, very, very static data
00:47:14.464 --> 00:47:17.419 that doesn't change often at all.
00:47:17.429 --> 00:47:19.759 For example, maybe a content page in a CMS.
00:47:20.229 --> 00:47:23.299 You might change that once every several months.
00:47:20.739 --> 00:47:20.919 Yeah.
00:47:23.609 --> 00:47:24.919 You could set a.
00:47:25.169 --> 00:47:29.789 You could set a 24 hour cache expiration on that and you know
00:47:29.789 --> 00:47:34.185 and basically just throw a disclaimer in the UI that these
00:47:34.185 --> 00:47:39.029 changes may take up to 24 hours to to be visible to all users or
00:47:39.029 --> 00:47:40.519 something like that.
00:47:41.169 --> 00:47:41.739 Umm.
00:47:42.129 --> 00:47:46.014 And now you've got a page that the first time somebody loads
00:47:46.014 --> 00:47:48.689 it, they're good for the rest of the day.
00:47:48.699 --> 00:47:50.789 If they're refreshing that page and that kind of thing.
00:47:50.799 --> 00:47:54.619 So, umm, there's a lot of really good ways to.
00:47:54.629 --> 00:47:59.594 There's a lot of different ways to handle browser caching, and
00:47:59.594 --> 00:48:04.166 every one of those ways use cases and different different
00:48:03.929 --> 00:48:09.319 OK, so we are a couple of minutes past the hour.
00:48:04.166 --> 00:48:05.269 pros and cons.
00:48:10.679 --> 00:48:13.890 I'm sure the next question that needs to be answered to everyone
00:48:13.890 --> 00:48:16.409 for the video is how do we get around the caching?
00:48:16.419 --> 00:48:19.437 And I'm gonna go over like, two or three different things really
00:48:19.437 --> 00:48:21.109 fast and just literally state them.
00:48:21.279 --> 00:48:25.470 Number one, open your dev tools and check disable cache and then
00:48:25.470 --> 00:48:29.274 refresh the page because the disable cache means that it's
00:48:29.274 --> 00:48:33.078 not allowed to use any 304 caching whatsoever, it must ask
00:48:33.078 --> 00:48:37.204 the server for a results and so it will do that number two with
00:48:37.204 --> 00:48:40.299 your dev tools open in virtually every browser.
00:48:40.309 --> 00:48:43.808 I don't know about Safari because Safari sucks if you have
00:48:43.808 --> 00:48:47.247 the dev tools open, you should be able to right click the
00:48:47.247 --> 00:48:50.923 refresh button and you be given more options about how do you
00:48:50.923 --> 00:48:54.600 refresh so you'll have normal reload which is control R or F5
00:48:54.600 --> 00:48:58.099 and you'll have hard reload which is control shift R which
00:48:58.099 --> 00:49:01.597 means ask the server for new info on stuff and then you'll
00:49:01.597 --> 00:49:03.969 have the nuclear option which is empty.
00:49:03.979 --> 00:49:07.657 All of my local caches for this page, so that there can't even
00:49:07.657 --> 00:49:11.510 be a physical cache for my local stuff and reload so that there's
00:49:11.510 --> 00:49:15.188 no way a local cache could be served up because you've emptied
00:49:15.188 --> 00:49:16.939 it on that page load on there.
00:49:18.019 --> 00:49:20.489 Umm for individual requests.
00:49:20.679 --> 00:49:24.129 If you're stuck on something you can like, let's say you wanted
00:49:24.129 --> 00:49:25.639 to right click that product.
00:49:25.879 --> 00:49:27.679 Uh, uh.
00:49:27.689 --> 00:49:29.779 Part of images active, true and open a new tab.
00:49:33.589 --> 00:49:35.459 Let's say you didn't have your dev tools open.
00:49:35.469 --> 00:49:38.379 You can add an argument to your URL.
00:49:39.659 --> 00:49:40.389 Uh, right there.
00:49:40.399 --> 00:49:41.689 There's the there's that one.
00:49:42.459 --> 00:49:45.014 Brendan Lyon implemented a server version that allows some
00:49:45.014 --> 00:49:46.529 of that caching to like increment.
00:49:46.539 --> 00:49:52.091 There you could add ampersand, no cache and then equal like
00:49:52.091 --> 00:49:53.109 underscore.
00:49:53.529 --> 00:49:55.049 It doesn't matter what value you give you give.
00:49:55.079 --> 00:49:57.088 It's just, it's just the presence of the tag that
00:49:57.088 --> 00:49:57.409 matters.
00:49:57.939 --> 00:50:00.799 When you do that, uh.
00:49:59.869 --> 00:50:02.490 I think it might need to be a number the the binder ones it to
00:50:02.490 --> 00:50:02.989 be a number.
00:50:04.059 --> 00:50:04.739 OK, straight.
00:50:04.679 --> 00:50:05.569 Just feel like it does.
00:50:04.749 --> 00:50:06.089 Yeah, try, try and one.
00:50:05.579 --> 00:50:06.889 It can be any number, but yeah.
00:50:07.709 --> 00:50:07.939 Yeah.
00:50:07.949 --> 00:50:08.399 There you go.
00:50:08.749 --> 00:50:10.069 Now you have.
00:50:10.079 --> 00:50:13.791 Well, now the no cat, the no cache argument itself doesn't
00:50:13.791 --> 00:50:15.679 matter what value you give it.
00:50:15.989 --> 00:50:19.783 The no cache tells the server that when it comes time to the
00:50:19.783 --> 00:50:21.649 caching stuff, don't allow it.
00:50:22.419 --> 00:50:25.612 You must give me new fresh info every time, even if there's no
00:50:25.612 --> 00:50:28.906 cash value is the same, because I I didn't want it to be tied to
00:50:28.906 --> 00:50:29.869 a particular stamp.
00:50:29.879 --> 00:50:32.389 I wanted it to be just a global flat.
00:50:32.539 --> 00:50:34.869 Don't give me anything that came out of any cache anywhere.
00:50:35.239 --> 00:50:38.798 You must give me fresh info value and that should work on
00:50:35.549 --> 00:50:35.729 Yep.
00:50:38.798 --> 00:50:40.209 virtually any endpoint.
00:50:41.529 --> 00:50:44.208 There might be a couple of custom ones, one out there that
00:50:44.208 --> 00:50:45.479 that doesn't work on if the.
00:50:45.489 --> 00:50:48.233 If that happens to you, let me know and I can work walk through
00:50:48.233 --> 00:50:50.119 it so that we can find out what went wrong.
00:50:50.449 --> 00:50:54.671 But that should be the case for any endpoint and it and it's
00:50:54.671 --> 00:50:59.031 actually on the like the base model and the base search model,
00:50:59.031 --> 00:51:03.529 so that that stuff is available as as as everywhere as possible.
00:51:03.719 --> 00:51:06.067 It does not work on like the product like going to the
00:51:06.067 --> 00:51:08.756 product details page and adding it there because it doesn't do
00:51:08.479 --> 00:51:09.809 That's coming to the DNN.
00:51:08.756 --> 00:51:10.549 it to like all of its children and stuff.
00:51:10.559 --> 00:51:14.660 Yeah, that's that page is coming out of DNN and DNN may or may
00:51:14.660 --> 00:51:17.979 not handle the no cache like also James mentioned.
00:51:17.989 --> 00:51:19.609 The underscore equals one.
00:51:19.619 --> 00:51:23.392 You can see that on that user name call and any other get
00:51:23.392 --> 00:51:25.279 requests that are being sent.
00:51:26.149 --> 00:51:27.819 Those are populated by the counter.
00:51:27.829 --> 00:51:30.169 Call that first post request all the way at the top.
00:51:30.209 --> 00:51:34.564 If you scroll up and there's just very quickly reads a number
00:51:34.564 --> 00:51:38.849 out of Redis and returns it, and that number is prefer is is
00:51:38.849 --> 00:51:43.344 suffixed to every get request as an additional unnamed argument
00:51:43.344 --> 00:51:47.629 that is to break browser caches for, mostly for QA purposes.
00:51:49.139 --> 00:51:52.753 However, it is actually it's come in handy for a couple of a
00:51:49.229 --> 00:51:49.389 Yeah.
00:51:52.753 --> 00:51:56.070 couple of things on some projects where, for example on
00:51:56.070 --> 00:51:59.625 PCs we have it set up where whenever they index products it
00:51:59.625 --> 00:52:02.883 automatically increments that number so that the those
00:52:02.883 --> 00:52:05.549 products immediately show up in the catalog.
00:52:05.559 --> 00:52:07.499 For people that have that have it browser cache.
00:52:08.659 --> 00:52:11.995 But yeah, I was going to have you go in and show in the admin
00:52:11.995 --> 00:52:15.009 where you can click the button to increment that cache.
00:52:16.219 --> 00:52:20.273 And then as well, there's another one that is in the skin
00:52:20.273 --> 00:52:22.789 file and the header and the footer.
00:52:24.299 --> 00:52:26.841 If you can bring that up, it doesn't matter which one, just
00:52:26.841 --> 00:52:27.349 one of them.
00:52:28.719 --> 00:52:29.709 Oh yeah, that one.
00:52:29.719 --> 00:52:33.599 That one does it for the files like server.
00:52:32.459 --> 00:52:33.109 Yeah, that one.
00:52:33.119 --> 00:52:35.166 Yeah, I'm gonna show that so that it's cause it's important
00:52:33.689 --> 00:52:33.959 Uh.
00:52:35.166 --> 00:52:35.439 to know.
00:52:35.369 --> 00:52:36.119 Yep, Yep.
00:52:36.779 --> 00:52:40.961 And so if you go to the skin and then look in the includes folder
00:52:40.961 --> 00:52:44.129 and then grab oh either the header or the footer.
00:52:46.949 --> 00:52:47.319 OK.
00:52:47.329 --> 00:52:50.485 And then scroll through this until you find where we're like,
00:52:50.485 --> 00:52:53.589 we're we're doing script links over to our our CSS and such.
00:52:54.159 --> 00:52:55.459 There it is build number.
00:52:54.369 --> 00:52:56.669 OK, there, see line 79.
00:52:57.689 --> 00:53:01.403 You see how it says, uh jQuery dot min dot JS and there's an
00:53:01.403 --> 00:53:05.300 underscore equal and then that's a server side tag that's gonna
00:53:05.300 --> 00:53:05.909 render A1.
00:53:06.369 --> 00:53:09.514 You can change that with the part that's coming out called
00:53:09.514 --> 00:53:11.379 called Datetime Dot now dot ticks.
00:53:11.589 --> 00:53:14.964 That means it will be a new number to every single time it
00:53:14.964 --> 00:53:18.568 refreshes, and then there's also the build number, which is to
00:53:18.568 --> 00:53:22.229 tie to the DNN caching number, which you could change it inside
00:53:22.229 --> 00:53:24.689 the DNN admin menu of the server settings.
00:53:25.489 --> 00:53:28.819 The goal of that being to cache bust against.
00:53:30.899 --> 00:53:37.074 The extreme caching system that is that one DNS service provider
00:53:37.074 --> 00:53:38.309 called FLARE.
00:53:38.319 --> 00:53:39.469 That's what I'm thinking of.
00:53:38.889 --> 00:53:39.589 Out flare, yeah.
00:53:39.879 --> 00:53:45.190 Cloud flare will cache the full body reply results of the files
00:53:45.190 --> 00:53:46.269 on their end.
00:53:46.279 --> 00:53:48.988 Replicate it through their servers for regional
00:53:48.988 --> 00:53:52.261 performance, and then you'll be stuck looking at the same
00:53:52.261 --> 00:53:55.647 version of it, even though you're trying to like modify the
00:53:55.647 --> 00:53:58.751 skin files or modify the templates and stuff and build
00:53:58.751 --> 00:54:01.799 new ones and it won't replace them until you do that.
00:54:01.949 --> 00:54:05.265 So this allows you to get past and around that because cloud
00:54:05.265 --> 00:54:08.799 flare, so cache heavy you can't get around it for all the files.
00:54:09.289 --> 00:54:12.714 This allows you to get around it every time and then basically
00:54:12.714 --> 00:54:16.085 you wanna put it back to where it's like a regular number and
00:54:16.085 --> 00:54:19.184 after you finish, you know, making your modifications so
00:54:19.184 --> 00:54:22.663 that the the cache busting stops happening because the wise you
00:54:22.663 --> 00:54:24.729 are impacting like production values.
00:54:25.139 --> 00:54:28.113 If you leave them with the daytime.net out of ticks or or
00:54:28.113 --> 00:54:31.395 something like that on it, but that's another one that needs to
00:54:31.395 --> 00:54:31.549 do.
00:54:31.559 --> 00:54:34.733 That's there for cache posting that one is mostly for front end
00:54:34.733 --> 00:54:37.659 cache busting, not data calls to the server cache busting.
00:54:40.319 --> 00:54:40.709 That's that.
00:54:40.719 --> 00:54:43.872 Would that would bust the cache of like cash, client side
00:54:43.872 --> 00:54:44.959 JavaScript and HTML.
00:54:46.399 --> 00:54:49.296 Yes, and the server side rendered DNN modules that are
00:54:49.296 --> 00:54:52.404 that came up on the page versus versus what we wrote up in
00:54:52.404 --> 00:54:53.299 Angular or react.
00:55:07.419 --> 00:55:10.329 Take the random site to use.
00:55:11.999 --> 00:55:16.859 Just uh dude developer or like 2020 or 2023-1 or something?
00:55:12.389 --> 00:55:12.779 I don't know.
00:55:15.349 --> 00:55:21.059 GFS is also a lot older, even though it get some updates.
00:55:19.359 --> 00:55:19.579 Yep.
00:55:19.359 --> 00:55:19.579 Yeah.
00:55:23.239 --> 00:55:24.869 The but you say TFs.
00:55:23.449 --> 00:55:23.679 Uh.
00:55:26.579 --> 00:55:26.759 Yeah.
00:55:27.149 --> 00:55:29.609 I haven't heard that name in years.
00:55:29.949 --> 00:55:31.459 Ah, OK, we got here.
00:55:31.469 --> 00:55:35.159 So we will go to fight maintenance. Uh.
00:55:34.929 --> 00:55:35.419 Yep.
00:55:35.429 --> 00:55:37.819 And then it's in other tasks.
00:55:38.599 --> 00:55:39.109 No.
00:55:39.119 --> 00:55:42.729 So it's the other tasks increment cache counter.
00:55:40.929 --> 00:55:41.929 And then try to at the bottom.
00:55:42.869 --> 00:55:43.199 Yep.
00:55:43.119 --> 00:55:47.408 So if I click this increment cache, counter cash counter
00:55:43.209 --> 00:55:46.574 So when you click that, click that button and then pull up the
00:55:46.574 --> 00:55:49.619 store front because it's not wired up in the admin. Yep.
00:55:47.408 --> 00:55:51.922 value is now too and then I go here and I should be able to
00:55:51.922 --> 00:55:54.029 just refresh the page right?
00:55:53.809 --> 00:55:54.999 But you're on GFS still.
00:55:55.009 --> 00:55:57.869 You're or or did you do that on GFS?
00:55:58.759 --> 00:56:00.949 Underscore 2 underscore equals two.
00:56:01.459 --> 00:56:02.469 I see on GFS.
00:56:02.369 --> 00:56:07.266 So now we have literally forced a bus cash for everybody that
00:56:07.266 --> 00:56:10.189 had the fronting code cache correct.
00:56:10.159 --> 00:56:11.549 Yep, Yep.
00:56:11.639 --> 00:56:14.869 And you'll see that it doesn't break absolutely every cache.
00:56:14.879 --> 00:56:17.709 You can see that, like the The JSON file for the translations.
00:56:17.719 --> 00:56:20.592 It doesn't get that right now and obviously post requests
00:56:20.592 --> 00:56:23.365 aren't cached at all, so you won't even see it prefixed
00:56:23.365 --> 00:56:26.436 prefixed on those, because it doesn't matter post requests or
00:56:26.436 --> 00:56:29.458 live every time live to the server, the server can choose to
00:56:28.349 --> 00:56:28.479 Yes.
00:56:29.458 --> 00:56:32.380 return cache content from its side, but the browser cannot
00:56:32.380 --> 00:56:34.559 cache the results of a post request itself.
00:56:40.879 --> 00:56:46.588 All right, guys, finishing statements, final statements,
00:56:46.588 --> 00:56:47.489 comments.
00:56:49.039 --> 00:56:50.199 Hashing is not evil.
00:56:51.429 --> 00:56:52.219 No, it really.
00:56:51.679 --> 00:56:52.949 Yes, it's annoying.
00:56:53.079 --> 00:56:55.259 It's annoying as a developer sometimes.
00:56:53.759 --> 00:56:57.458 Reindexing the products does not make the product details page
00:56:57.458 --> 00:56:57.869 change.
00:56:59.009 --> 00:57:01.895 Also that yeah, but a lot of people get really frustrated
00:57:01.895 --> 00:57:05.129 about caching because it can be a little bit annoying during the
00:57:05.129 --> 00:57:08.114 development process and they wanna go the nuclear option of
00:57:08.114 --> 00:57:11.199 why don't we just, why don't we just kill this caching thing?
00:57:11.209 --> 00:57:12.709 Because it's causing me trouble right now.
00:57:12.719 --> 00:57:16.619 In this moment, and that's a very bad idea.
00:57:16.709 --> 00:57:18.229 So caching is.
00:57:17.919 --> 00:57:21.739 System cannot function without Redis, period like you can't
00:57:21.319 --> 00:57:21.709 Yes.
00:57:21.739 --> 00:57:24.349 just turn it off and and and let it run.
00:57:21.759 --> 00:57:26.606 And and and it's not a feasible idea to circumvent it in places
00:57:26.606 --> 00:57:31.453 just so you can test something easier, because once that client
00:57:31.453 --> 00:57:36.376 into the production and they're like, why is my site the world's
00:57:36.376 --> 00:57:38.799 slowest website on every metric?
00:57:38.849 --> 00:57:42.169 And it's because you commented out performance optimizations.
00:57:43.709 --> 00:57:44.779 You're going to have a problem.
00:57:44.829 --> 00:57:47.839 So umm, caching is annoying.
00:57:46.529 --> 00:57:48.539 You're gonna have a management problem at that point.
00:57:48.829 --> 00:57:52.259 Yeah, caching is annoying, but caching is not evil.
00:57:52.349 --> 00:57:56.395 Caching is very, very necessary to be competitive at all and
00:57:56.395 --> 00:58:00.573 functional at all on lower end devices, especially cell phones
00:58:00.573 --> 00:58:01.899 and stuff like that.
00:58:01.909 --> 00:58:05.654 So if you're having issues with caching, there are ways to work
00:58:05.654 --> 00:58:06.239 around it.
00:58:06.509 --> 00:58:09.419 If you're having trouble working around it, ask for help.
00:58:09.609 --> 00:58:13.981 Don't just disable caching code and production sites and then
00:58:13.981 --> 00:58:15.039 push that into.
00:58:16.029 --> 00:58:18.879 You know the the source control without hopefully with their,
00:58:18.879 --> 00:58:21.499 you know ideally with no one noticing so that it ends up
00:58:21.499 --> 00:58:24.027 getting all the way to production and then the clients
00:58:24.027 --> 00:58:25.819 like you're your site is slow as hell.
00:58:25.829 --> 00:58:26.409 What's going on?
00:58:28.179 --> 00:58:28.599 Don't do that.
00:58:32.819 --> 00:58:33.489 Alright guys.
00:58:33.499 --> 00:58:35.379 Well, I think that's gonna wrap us up.