00:00:04.457 --> 00:00:05.317 While the feds.
00:00:06.407 --> 00:00:10.169 You can already zip file let's 5 gigs. Not great to leave that
00:00:10.169 --> 00:00:10.527 there.
00:00:11.357 --> 00:00:12.837 One of the reasons the hard drive is full.
00:00:13.887 --> 00:00:18.090 Uh, I'm normally if you've got a file like that, you wanna like
00:00:18.090 --> 00:00:21.767 zip up, grab it, throw it into the under score archive.
00:00:23.217 --> 00:00:27.407 Here and then at some point somebody will.
00:00:28.047 --> 00:00:28.817 Umm.
00:00:30.397 --> 00:00:33.786 Create a link from this folder over to with the the long term
00:00:33.786 --> 00:00:34.497 storage mass.
00:00:36.627 --> 00:00:39.441 Slash slash files or whatever they call it these days and it's
00:00:39.441 --> 00:00:40.737 been moved a couple of times.
00:00:42.997 --> 00:00:46.610 And in that we will drag like old copies of, you know, things
00:00:46.610 --> 00:00:50.223 like this. It's better zips and whatever and pull them out of
00:00:50.223 --> 00:00:52.787 where they are and over to the other spots.
00:00:53.827 --> 00:00:57.695 Umm, looks like you've got our IE here. I see a backup configs.
00:00:57.695 --> 00:01:00.657 It's normally deployed by CCD according to that.
00:01:01.257 --> 00:01:02.957 Umm, so that's nice.
00:01:03.957 --> 00:01:08.215 I'll open IIS and I'll look and double check that IIS has. Are
00:01:08.215 --> 00:01:09.297 we recording it?
00:01:09.777 --> 00:01:10.597 Yep, I got you.
00:01:12.017 --> 00:01:16.139 Umm IIS should have like maximize this window and RIE. In
00:01:16.139 --> 00:01:20.262 here I see an RIA debug in Raqqa. I guess the debug is so
00:01:20.262 --> 00:01:24.597 that you guys have an access to it to do that kind of thing.
00:01:26.017 --> 00:01:29.132 With its own domain on it, I see it's got bindings on it. I mean,
00:01:29.132 --> 00:01:32.153 we'll double check because it's the first time I'm touching the
00:01:32.153 --> 00:01:34.938 site. I'm double checking everything set up correctly like
00:01:34.938 --> 00:01:37.534 this is wrong. You have to have server name indication
00:01:37.534 --> 00:01:40.461 correctly, otherwise it doesn't identify sites properly and I
00:01:40.461 --> 00:01:43.057 don't recommend doing capital letters on these things.
00:01:44.157 --> 00:01:44.647 Umm.
00:01:45.777 --> 00:01:48.979 And instead do that like. It's not bad that it's happened. It's
00:01:48.979 --> 00:01:52.032 like a break anything. But I don't recommend it. So we clean
00:01:52.032 --> 00:01:54.834 those bindings up that parts there. I'll go to advanced
00:01:54.834 --> 00:01:57.886 settings. I'll turn preload on so that as you start the site
00:01:57.886 --> 00:01:59.087 it's it warms itself up.
00:02:00.197 --> 00:02:02.237 I would do that to all the inner ones.
00:02:03.167 --> 00:02:06.626 Uh, so like API here, manage application advanced settings,
00:02:06.626 --> 00:02:07.087 preload.
00:02:08.087 --> 00:02:08.467 Bump.
00:02:09.607 --> 00:02:11.157 I'll do that to each of these.
00:02:14.977 --> 00:02:16.847 And if the site was already configured for all the stuff, I
00:02:16.847 --> 00:02:17.907 wouldn't have to do anything but.
00:02:19.287 --> 00:02:21.570 Doing it because they're not configured that way, but
00:02:21.570 --> 00:02:24.064 scheduler especially needs that in order to stay awake and
00:02:24.064 --> 00:02:26.728 alive. So if you're scheduler is going dead, that's one reason
00:02:26.728 --> 00:02:28.757 why it would be feeling is to reload is not on.
00:02:29.387 --> 00:02:32.829 Umm, I can see we have the shot for react we have UI admin and
00:02:32.829 --> 00:02:36.216 UI storefront. So that's all there. I'm going to look for the
00:02:36.216 --> 00:02:39.495 images ecommerce link. Yep, that's going over to the images
00:02:39.495 --> 00:02:39.877 folder.
00:02:40.547 --> 00:02:43.843 And uh, I'm not worried about there not being like an API
00:02:43.843 --> 00:02:47.138 reference that's that's not really necessary to be there.
00:02:47.138 --> 00:02:50.491 The meta services there, the scheduler is there. All those
00:02:50.491 --> 00:02:53.730 others are there. So that stuff's all good. I'm gonna go
00:02:53.730 --> 00:02:55.207 over to our IIS app pools.
00:02:58.257 --> 00:03:02.425 And inside here I see the RE debugs all down and the QA ones
00:03:02.425 --> 00:03:06.661 are running. Let's look at the defaults. The defaults for app
00:03:06.661 --> 00:03:08.027 pools are currently.
00:03:08.787 --> 00:03:12.984 An idle timeout of 1200 and on demand startups with no regular
00:03:12.984 --> 00:03:16.915 resets on your locals, you should never have this as 1200.
00:03:16.915 --> 00:03:21.045 You should be 0. The reason I we're doing it on the dev boxes
00:03:21.045 --> 00:03:22.977 so that they will eventually.
00:03:24.117 --> 00:03:26.324 You know, go down and on your local. It should be always
00:03:26.324 --> 00:03:28.647 running so that he just spins up as soon as you're running.
00:03:29.037 --> 00:03:32.152 Umm, you'll do that? Schedulers need they always running in
00:03:32.152 --> 00:03:35.475 order to stay awake alive. Looks like it's got it there for the
00:03:35.475 --> 00:03:38.746 scheduler with right. No regular time interval and on the same
00:03:38.746 --> 00:03:42.016 thing on the schedule. Here we need to make sure that it's not
00:03:42.016 --> 00:03:42.847 idle timing out.
00:03:44.127 --> 00:03:45.437 Otherwise it will shut itself down.
00:03:46.257 --> 00:03:48.578 Uh, so we want those settings like that. That'll keep
00:03:48.578 --> 00:03:49.567 scheduler up and going.
00:03:51.697 --> 00:03:53.938 Don't need to do that specifically to the DNN or
00:03:53.938 --> 00:03:56.727 anything because of the other stuff in there. Other stuff is
00:03:56.727 --> 00:03:59.470 really just about keeping it alive for other things connect
00:03:59.470 --> 00:04:02.305 because it's hanging fire based. We want the same thing where
00:04:02.305 --> 00:04:03.997 it's always running at a no timeout.
00:04:04.967 --> 00:04:07.887 I'm gonna keep that stuff awake and alive by doing that.
00:04:09.657 --> 00:04:13.465 Even if it was the C4 build, we would want that just to keep it
00:04:13.465 --> 00:04:16.916 awake and alive. So we have a debug and we have a QA. I'm
00:04:16.916 --> 00:04:19.891 gonna go to QA and basic settings. Sorry advanced
00:04:19.891 --> 00:04:20.427 settings.
00:04:21.627 --> 00:04:24.697 It looks like i.e. Is a multi.
00:04:25.177 --> 00:04:28.728 Uh multi branded things, so it's got multiple bindings on it. If
00:04:28.728 --> 00:04:32.278 I look at the bindings and go to HTTPS on them, there's a server
00:04:32.278 --> 00:04:33.917 name indication that's got it.
00:04:34.717 --> 00:04:37.287 That's got it. And that's got it. So those are all correct.
00:04:37.967 --> 00:04:40.887 Umm I'll I just did preload on this one, didn't I?
00:04:41.877 --> 00:04:45.527 Yes, I did and then desktop modules, clarity, ecommerce.
00:04:46.337 --> 00:04:48.334 Same thing again with all of these. Just make sure they all
00:04:48.334 --> 00:04:50.297 have preload. It looks like this one all set up correctly.
00:04:51.317 --> 00:04:52.737 Oop. Nope, that one didn't have it.
00:04:55.517 --> 00:04:56.227 On admin.
00:05:03.207 --> 00:05:05.955 Said OK and then I see those things there. We don't, we're
00:05:05.955 --> 00:05:08.657 not. We're again. I'm not worried about having the actual
00:05:08.657 --> 00:05:11.592 thing or API reference. I see the images are there. OK, so now
00:05:11.592 --> 00:05:14.061 I've reasonably verified that it's at least stood up
00:05:14.061 --> 00:05:14.527 correctly.
00:05:15.527 --> 00:05:18.583 Your or close to it to make other minor corrections like
00:05:18.583 --> 00:05:22.015 just putting the capital C's on here, I would go do that, put a
00:05:22.015 --> 00:05:25.017 2 on the end, because the tasting changes on their own.
00:05:25.017 --> 00:05:28.127 That way it just looks a little more visually consistent.
00:05:29.277 --> 00:05:31.997 That's just me being OCD about it, so I'll refresh that
00:05:31.997 --> 00:05:35.009 everything is nice and clean. I know that both of those sites
00:05:35.009 --> 00:05:37.973 are good to go regardless of which one I'm actually going to
00:05:37.973 --> 00:05:38.507 touch here.
00:05:40.337 --> 00:05:45.877 And be app pools are are ready and alive for QA so.
00:05:46.647 --> 00:05:48.975 That said, which of the two sites do you want me to to try
00:05:48.975 --> 00:05:51.421 and deal with? You want me to work with debug? Or do you want
00:05:51.421 --> 00:05:52.447 me to work with the staff?
00:05:53.247 --> 00:05:54.867 The the the regular one.
00:05:56.317 --> 00:05:58.583 There's probably not a way to attach to the QA because on a
00:05:58.583 --> 00:05:59.187 pipeline, right?
00:06:00.327 --> 00:06:03.248 Well, now you can attach to it with with an instance of self
00:06:03.248 --> 00:06:06.122 you just pointed at the that ones app pools as long as it's
00:06:06.122 --> 00:06:08.277 reasonably the same code, it should be fine.
00:06:09.197 --> 00:06:11.932 But if you're gonna debug and modify code and then try to try
00:06:09.367 --> 00:06:10.147 Yeah, let's do that.
00:06:11.932 --> 00:06:14.623 to change it, you would have to run it through the pipeline,
00:06:14.623 --> 00:06:17.447 which means merging it and all the other stuff. If you wanna do
00:06:17.447 --> 00:06:20.226 that right now and make changes and do modifications, we would
00:06:20.226 --> 00:06:21.417 have to use the debug site.
00:06:22.767 --> 00:06:26.317 Gotcha. So payable sites are all set up on pipelines as well. So
00:06:26.317 --> 00:06:28.557 if you could go through attaching to it.
00:06:29.977 --> 00:06:32.471 So what would? What would the answer be then you'd clone down
00:06:32.471 --> 00:06:34.925 QA branch on that machine and then it used that to attach to
00:06:34.925 --> 00:06:35.367 that Apple.
00:06:36.287 --> 00:06:39.356 Yeah. And that's I think that's what this debug affect is. So
00:06:37.977 --> 00:06:39.047 That's what debug is, yeah.
00:06:39.356 --> 00:06:42.425 like you have a hot fix with product upsert, that's whatever.
00:06:42.425 --> 00:06:44.157 But so I would open Visual Studio.
00:06:44.857 --> 00:06:47.997 Umm, which it's running in the background here as I spins up.
00:06:49.707 --> 00:06:50.277 Opening up.
00:06:50.047 --> 00:06:53.417 Yeah. And I I did want to point out too, I I don't know if debug
00:06:53.417 --> 00:06:54.817 is actively maintained, so.
00:06:56.017 --> 00:06:57.667 QA may be the better one.
00:06:56.587 --> 00:07:01.788 So like what I could do is let's do a let's do a couple of things
00:07:01.788 --> 00:07:02.497 here one.
00:07:03.567 --> 00:07:05.994 That's another archive that should be like dropped
00:07:05.994 --> 00:07:06.517 eventually.
00:07:08.397 --> 00:07:10.794 I normally when I have a debug site in here, unless I'm
00:07:10.794 --> 00:07:13.148 actually pulling a whole separate thing, I just pulled
00:07:13.148 --> 00:07:14.047 the set to that root.
00:07:14.707 --> 00:07:17.597 Where they're the files are right there as opposed to
00:07:17.597 --> 00:07:20.863 further end or I do like CEF dash debug or Sev two so that I
00:07:20.863 --> 00:07:24.021 don't have. I don't have to abstract it in a further layer
00:07:24.021 --> 00:07:27.339 of a folder for no extra reason. So with self configs there's
00:07:27.339 --> 00:07:29.427 this file here called fetch and prune.
00:07:30.177 --> 00:07:33.579 Copy that into here and when you run it, anything that has a git
00:07:33.579 --> 00:07:36.877 folder will get a fetch and it will prune out or other files I
00:07:36.877 --> 00:07:39.965 might actually need to run it as admin because of the file
00:07:39.965 --> 00:07:40.907 permissions on it.
00:07:43.657 --> 00:07:46.691 Uh, Nope. It's running it from there, which does not work,
00:07:46.691 --> 00:07:48.337 right? So I've gotta do command.
00:07:49.237 --> 00:07:51.507 Michael, shift enter, yes.
00:07:53.277 --> 00:07:54.467 E over to hear.
00:07:55.947 --> 00:07:59.625 And then run fetching prune there and now it appropriately
00:07:59.625 --> 00:08:01.557 checks checks though the Web 9.
00:08:02.277 --> 00:08:02.967 Like it should.
00:08:06.437 --> 00:08:10.257 And it's going to fetch all the branches from the server for Web
00:08:10.257 --> 00:08:13.784 9, and then it'll remove any branches that are not actually
00:08:13.784 --> 00:08:15.077 on the server anymore.
00:08:15.757 --> 00:08:19.020 Right, remove branches that are referenced from the server that
00:08:19.020 --> 00:08:22.282 are no longer on the server. OK and then I'll do the same thing
00:08:22.282 --> 00:08:24.627 from inside here because it is a folder down.
00:08:25.507 --> 00:08:27.967 I'm gonna CD into the debug folder.
00:08:28.867 --> 00:08:30.127 And do the same thing.
00:08:31.057 --> 00:08:32.647 And we'll do it against that 7 instance.
00:08:34.157 --> 00:08:37.169 We'll see is an output of a bunch of like branches that got
00:08:37.169 --> 00:08:39.077 deleted because they no longer there.
00:08:44.327 --> 00:08:45.847 Or it's not pulling its fetching specifically.
00:08:50.977 --> 00:08:52.857 Upon thirty Megs where the data?
00:08:55.337 --> 00:08:58.364 Trying to make sure all the data is matching what it's supposed
00:08:58.364 --> 00:09:00.397 to match for server reference to branches.
00:09:04.907 --> 00:09:07.068 It will spin on a report of all the branch updates that have
00:09:07.068 --> 00:09:07.387 occurred.
00:09:09.727 --> 00:09:11.417 The origin side.
00:09:27.267 --> 00:09:30.475 And then you see here all these branches like sifa SI RX1. These
00:09:30.475 --> 00:09:33.239 are all really old branches. Those are all removed from
00:09:33.239 --> 00:09:36.249 inside this thing's local thing. So if you go to like Switch
00:09:36.249 --> 00:09:39.407 branch, you won't see these ones anymore because they no longer
00:09:39.407 --> 00:09:42.418 there and that's what the prune helps with. Is just cleaning
00:09:42.418 --> 00:09:45.330 that kind of stuff up for you and running it with that bat
00:09:45.330 --> 00:09:48.488 file. It makes it really simple because it will loop over every
00:09:48.488 --> 00:09:50.857 directory looking for git folders and run them.
00:09:52.227 --> 00:09:54.459 It's a little more pain in the as when you don't have the
00:09:54.459 --> 00:09:56.884 direct permissions you have to run it as admin, so you have to
00:09:56.884 --> 00:09:59.386 like open an admin prompt to go over to the folder to do it. But
00:09:59.386 --> 00:10:01.849 generally speaking like if it's just your local you should have
00:10:01.849 --> 00:10:04.236 mention you just double click it and it will loop through and
00:10:04.236 --> 00:10:06.237 take care of that for you. So now what I can do is.
00:10:06.557 --> 00:10:10.001 I'm from inside by Visual Studio which is running as admin.
00:10:10.001 --> 00:10:13.559 Before I do anything else, I'm gonna press open and I'm going
00:10:13.559 --> 00:10:14.937 to go over to my folder.
00:10:16.187 --> 00:10:18.697 Like I was inside Tasco last apparently.
00:10:19.707 --> 00:10:22.953 I'll go over to my RIE. I'll go to debug and CEF and instead of
00:10:22.953 --> 00:10:26.301 doing anything else with it, I'm gonna use tortoise git from this
00:10:26.301 --> 00:10:29.394 window because this gives it admin rights and I'll say pull.
00:10:29.394 --> 00:10:32.539 So let's see if there I could pull anything for that instance
00:10:32.539 --> 00:10:33.097 real quick.
00:10:35.387 --> 00:10:37.483 Now the fetch has already occurred, so there's stuff and
00:10:37.483 --> 00:10:39.689 it's telling me that the branch does not exist in the other
00:10:39.689 --> 00:10:41.417 thing. So the branch there is no longer there.
00:10:41.977 --> 00:10:44.231 I'm. I'm not gonna do anything else with the branch itself. I'm
00:10:44.231 --> 00:10:45.217 just gonna switch check out.
00:10:46.357 --> 00:10:48.337 I'm going to go over to Ries QA.
00:10:49.347 --> 00:10:51.257 Unless you want to name another branch for me to use.
00:10:51.967 --> 00:10:53.227 This is all accu stuff.
00:10:53.957 --> 00:10:56.404 That's that's leftovers from like when it got copied from
00:10:56.404 --> 00:10:57.037 another client.
00:10:58.537 --> 00:11:00.388 Umm so I want to wipe out all this active stuff because
00:11:00.388 --> 00:11:01.347 there's no way it's accurate.
00:11:02.007 --> 00:11:03.307 From 2021 so.
00:11:05.227 --> 00:11:06.817 I mean these guys out and get him out of the way.
00:11:08.177 --> 00:11:09.267 Never have to look at them again.
00:11:14.597 --> 00:11:17.071 You would normally have done this like add like before I
00:11:17.071 --> 00:11:18.547 copied the branch and stuff over.
00:11:24.017 --> 00:11:26.902 Uh, I was last modified in January, so I'm actually going
00:11:26.902 --> 00:11:27.747 to keep that one.
00:11:28.617 --> 00:11:32.001 And then this guy was last updated in total 28 on the
00:11:32.001 --> 00:11:32.377 local.
00:11:33.127 --> 00:11:36.267 And then you have a pipeline, something going on here from?
00:11:37.027 --> 00:11:41.588 2021, whatever that can go away. So now I'm gonna go to remotes
00:11:41.588 --> 00:11:43.227 and look for our IE QA.
00:11:45.217 --> 00:11:48.359 The list here I see my right QA last updated 222 which was two
00:11:48.359 --> 00:11:51.350 days ago which was a lot lower than the 12221. Now if I had
00:11:51.350 --> 00:11:54.243 left the QA branch that was there, I would have needed to
00:11:54.243 --> 00:11:57.434 check override Branch if exists to tell to do that. But since I
00:11:57.434 --> 00:12:00.576 got rid of it, I don't need to do that and I could just hit OK
00:12:00.576 --> 00:12:03.318 after picking my branch it should update all the local
00:12:03.318 --> 00:12:06.510 files to whatever was there and that should match what's in the
00:12:06.510 --> 00:12:09.701 server for shifts and giggles I will pull one more time just to
00:12:09.701 --> 00:12:11.147 make sure nothing got missed.
00:12:11.777 --> 00:12:14.823 By accident, somehow with all the build that is entirely
00:12:14.823 --> 00:12:17.976 unnecessary because it says already up-to-date. Now I have
00:12:17.976 --> 00:12:21.342 this thing here and now instead of open file I'm going to open
00:12:21.342 --> 00:12:22.037 the solution.
00:12:24.007 --> 00:12:25.657 And I can get to work on.
00:12:26.257 --> 00:12:27.247 You know making attaching.
00:12:29.247 --> 00:12:32.087 Was the debug site is off for RIE?
00:12:33.227 --> 00:12:36.067 All five of those confirmed off I can do RE.
00:12:36.967 --> 00:12:40.873 Debug and then I would say like stop if they were still running,
00:12:40.873 --> 00:12:43.817 I would come in and I want to do a nice rebuild.
00:12:44.437 --> 00:12:47.486 Make sure that I'm all up to date with this code so that when
00:12:47.486 --> 00:12:50.485 I attach to the QA site, I'm good to at least reasonably try
00:12:50.485 --> 00:12:51.567 to match what's there.
00:12:53.317 --> 00:12:56.095 For the stuff, because what's inside the QA branch should have
00:12:56.095 --> 00:12:58.167 been gone through the pipeline to get to here.
00:13:02.767 --> 00:13:07.341 You do. You do do, do, do, do, do, do, do, do, do, do, do, do,
00:13:07.341 --> 00:13:08.067 do do, do.
00:13:36.587 --> 00:13:39.527 I'm gonna go ahead, close these two files.
00:13:42.807 --> 00:13:43.677 It wants to.
00:13:45.037 --> 00:13:46.277 Think of every server running in it.
00:14:00.007 --> 00:14:02.557 First time I have opened it, so we'll Resharper.
00:14:05.867 --> 00:14:09.219 Force Resharper to stop. I should have my hotkey to toggle
00:14:09.219 --> 00:14:10.867 it off with control numpad 0.
00:14:12.667 --> 00:14:13.287 For that.
00:14:15.667 --> 00:14:17.137 Yep, that turned re sharper off entirely.
00:14:21.307 --> 00:14:21.897 Projects.
00:14:24.317 --> 00:14:24.687 Like.
00:14:35.647 --> 00:14:40.118 OK, so there's my data model. I can see the stuff in here for
00:14:40.118 --> 00:14:40.407 the.
00:14:41.517 --> 00:14:44.328 Yeah, making sure that this is nice and clean. I'm gonna roll
00:14:44.328 --> 00:14:47.048 the client plugins. We're gonna nuke the one that was built
00:14:47.048 --> 00:14:47.547 previously.
00:14:51.357 --> 00:14:54.417 Same thing for the providers so that I'm nice and clean.
00:14:55.857 --> 00:14:57.927 Anything that would be relevant for us.
00:14:59.737 --> 00:15:01.899 All that stuff out, these are all just secretary package polls
00:15:01.899 --> 00:15:04.026 that are really going to change, or if they are gonna changes
00:15:04.026 --> 00:15:04.747 should override them.
00:15:06.487 --> 00:15:07.867 Now I'm going to do a nice rebuild.
00:15:14.737 --> 00:15:15.267 Right, like.
00:15:19.357 --> 00:15:22.524 You know solution and then, well, that's rebuilding. I'm
00:15:22.524 --> 00:15:25.913 going to go back over here. So the output files that come in
00:15:25.913 --> 00:15:29.580 here have the plugins and client bugs and everything they do have
00:15:29.580 --> 00:15:32.747 their PDB and XML's and that's how it's gonna be able to
00:15:32.747 --> 00:15:36.136 recognize that it's attachable for debugging. If it was just
00:15:36.136 --> 00:15:39.692 adls and the artifact push, we would not be able to attach very
00:15:39.692 --> 00:15:43.026 well. It would be telling us that it can't find anything to
00:15:43.026 --> 00:15:44.637 actually try and match it up.
00:15:45.277 --> 00:15:49.622 Umm. And So what we might do is try to lessen some of the debug
00:15:49.622 --> 00:15:52.337 requirements by going to debug options.
00:15:54.707 --> 00:15:56.899 And telling it that like it doesn't have to match the source
00:15:56.899 --> 00:15:57.797 code and stuff like that.
00:15:59.807 --> 00:16:02.357 Inside these settings. But if it you know.
00:16:03.347 --> 00:16:05.557 Worst comes to worst, we probably just have to run a new
00:16:05.557 --> 00:16:08.000 pipeline to make sure there's a new set of files coming out in
00:16:08.000 --> 00:16:08.737 order to get there.
00:16:09.407 --> 00:16:10.067 I.
00:16:11.567 --> 00:16:14.348 And and and and pull it up in there so we can we can go
00:16:14.348 --> 00:16:17.079 through and and mod those settings and and whatever in
00:16:17.079 --> 00:16:17.327 here.
00:16:18.097 --> 00:16:18.617 Umm.
00:16:21.437 --> 00:16:23.787 And it may end up being that like we can debug some files
00:16:23.787 --> 00:16:26.178 that we can't debug others because some specific reason of
00:16:26.178 --> 00:16:28.447 whatever decided not to work, but we'll we'll find out.
00:16:29.377 --> 00:16:30.567 But ends up being the case here.
00:16:31.257 --> 00:16:32.967 Who was complaining about a project reference?
00:16:35.497 --> 00:16:36.097 I'll resolved.
00:16:44.307 --> 00:16:44.757 Policing.
00:16:46.447 --> 00:16:48.913 So while this is building, James gonna give us a walk through of
00:16:47.207 --> 00:16:47.647 I don't know.
00:16:48.913 --> 00:16:50.697 like the structure here and where things live.
00:16:51.797 --> 00:16:55.419 Oh, sure. So we have a tiered architecture and each tier is
00:16:55.419 --> 00:16:56.687 one of these folders.
00:16:57.857 --> 00:17:00.946 Ohh, with the exception of like T4 it's just it's not really a
00:17:00.946 --> 00:17:03.839 tier, it's just moving stuff out of the way so the deepest
00:17:03.839 --> 00:17:06.780 darkest layer of the dungeon is this core stuff. And that's
00:17:06.780 --> 00:17:09.722 because these things tend to be referenced by everything in
00:17:09.722 --> 00:17:12.811 order to provide information to the entire system. So like the
00:17:12.811 --> 00:17:14.037 Richard Loader is our DI.
00:17:15.267 --> 00:17:17.616 We have an encryption library so that we can we can encrypt
00:17:17.616 --> 00:17:19.377 passwords and other things in a certain way.
00:17:20.577 --> 00:17:23.594 For for tokenization, it's not the the identity password
00:17:23.594 --> 00:17:26.717 password part, but it's for secondary workflows talking to
00:17:26.717 --> 00:17:30.211 DNN and some other stuff. We get the configuration library, which
00:17:30.211 --> 00:17:33.651 is one of the settings live, and we have utilities which is like
00:17:33.651 --> 00:17:36.774 async extensions and string extension stuff like that that
00:17:36.774 --> 00:17:40.162 are just commonly used in the. So we keep them down low and are
00:17:40.162 --> 00:17:43.497 very very small DLL that just handles a few classes by itself.
00:17:44.037 --> 00:17:47.309 Umm. Again, that's our Dr. our DRI. We had logging as a
00:17:47.309 --> 00:17:51.107 separate project, but because it was so intertwined with how the
00:17:51.107 --> 00:17:54.087 registry loader was working, we put them together.
00:17:55.307 --> 00:17:58.581 Core has like information for the JS configs and it has our
00:17:58.581 --> 00:18:01.910 enums and stuff and some basic classes like the serializable
00:18:01.910 --> 00:18:05.348 attributes dictionary. So that stuff lives in configuration is
00:18:05.348 --> 00:18:08.731 just a configuration setup so like it has a couple of classes
00:18:08.731 --> 00:18:12.060 of its own for attributes and app settings and then our main
00:18:12.060 --> 00:18:15.498 config dictionaries in here. So if you ever need to change the
00:18:15.498 --> 00:18:18.991 setting value this is where we go to look up where the settings
00:18:18.991 --> 00:18:22.483 values are and then if you need to add it to like how the stuff
00:18:22.483 --> 00:18:24.557 config works from the storefront and.
00:18:24.737 --> 00:18:27.611 React or or angular you would come into this file and this is
00:18:27.611 --> 00:18:30.577 literally the output file that it would spit out and pretend to
00:18:30.577 --> 00:18:32.617 be a JavaScript file that has that content.
00:18:33.077 --> 00:18:35.472 Umm. And you would come in and you would modify it to add
00:18:35.472 --> 00:18:37.537 additional settings. Stuff in here if you had to.
00:18:39.897 --> 00:18:43.277 So that's the core layer, the next layer up is the data access
00:18:43.277 --> 00:18:46.711 layer. This is the state engine of the system. So everything is
00:18:46.711 --> 00:18:50.252 stored in the database. We tried out the store hardly anything in
00:18:50.252 --> 00:18:53.364 memory. There is some secondary stuff that has to do with
00:18:53.364 --> 00:18:56.690 sessions based things for Redis as well as some other caching
00:18:56.690 --> 00:18:59.963 stuff that happens inside Redis. But the state of the system
00:18:59.963 --> 00:19:03.236 itself is the database. So we have this all isolated here to
00:19:03.236 --> 00:19:06.455 do this one thing and it's all entity framework code first.
00:19:06.455 --> 00:19:09.567 There's T fours in here that drive everything. This is a.
00:19:09.887 --> 00:19:12.489 Not the current version of steps, but in the current
00:19:12.489 --> 00:19:15.532 version we've actually migrated most of the T4's down to this
00:19:15.532 --> 00:19:18.673 spot so that you run 1T4 in the back end all the way up through
00:19:18.673 --> 00:19:19.557 the service layer.
00:19:20.097 --> 00:19:23.091 Umm so that you have to go to each layer and run each
00:19:23.091 --> 00:19:26.640 individual T4 that's going on. It's like the the filter by here
00:19:26.640 --> 00:19:30.078 T4 is physically inside here here just running the one T4 and
00:19:30.078 --> 00:19:31.797 it includes it as that one job.
00:19:32.657 --> 00:19:33.797 Which is, uh, nice.
00:19:35.167 --> 00:19:38.322 So you have your data model. We have a shared project here
00:19:38.322 --> 00:19:41.637 because there are actually two data model projects. There's a
00:19:41.637 --> 00:19:45.005 second one out there called dot .net 5. It was because we were
00:19:45.005 --> 00:19:48.053 gonna do totally different setups inside EF for the fact
00:19:48.053 --> 00:19:51.475 that it's net core and net core didn't directly service support
00:19:51.475 --> 00:19:54.523 entity framework as it was versus entity framework Core,
00:19:54.523 --> 00:19:58.052 there was confusing their setup. They've actually changed it over
00:19:58.052 --> 00:20:01.474 time, so it's no longer the same thing. And at this point we're
00:20:01.474 --> 00:20:04.361 gonna do something totally different when we actually
00:20:04.361 --> 00:20:05.377 migrate to Phoenix.
00:20:06.587 --> 00:20:09.031 You know, like this year or next year, whenever it actually
00:20:09.031 --> 00:20:09.357 happens.
00:20:09.957 --> 00:20:12.916 Umm, so the data model project here and it references the
00:20:12.916 --> 00:20:16.029 shared project which is where all the actual like migrations
00:20:16.029 --> 00:20:19.243 and all the bottles about the individual tables are. So if you
00:20:19.243 --> 00:20:22.152 wanna look at the language table, all that stuff in here
00:20:22.152 --> 00:20:25.417 and then we have our SQL schema tag, we have our relationships,
00:20:25.417 --> 00:20:28.530 there's base classes for it to commonality and not having to
00:20:28.530 --> 00:20:31.642 rewrite the same code over and over again. All that stuff in
00:20:31.642 --> 00:20:34.857 there and our base concretes and interfaces are on this stuff.
00:20:36.057 --> 00:20:39.994 So like I have a language or I am a language relationship table
00:20:39.994 --> 00:20:43.931 base or I am filterable by user. I am an applied discount base,
00:20:43.931 --> 00:20:47.806 that kind of stuff and then I have a state. I have a status. I
00:20:47.806 --> 00:20:51.497 have a stored file. I have a type. Those kind of interfaces
00:20:51.497 --> 00:20:55.372 are here. These root concretes and interfaces are all mirrored
00:20:55.372 --> 00:20:59.124 on the model Center for data transfer objects and they might
00:20:59.124 --> 00:21:02.630 have whatever modifications for the DTO version of these
00:21:02.630 --> 00:21:06.567 properties are inside here. For instance, for the longest time.
00:21:06.647 --> 00:21:10.080 The idea on a model in the database was non nullable, but
00:21:10.080 --> 00:21:10.317 the.
00:21:10.657 --> 00:21:14.126 Uh, sorry, sorry. The the record version of the entity version of
00:21:14.126 --> 00:21:17.596 it was non nullable and then the data transfer object model had a
00:21:17.596 --> 00:21:21.013 nullable version of that ID, so we didn't have to pass them with
00:21:21.013 --> 00:21:22.327 IDs through from connect.
00:21:23.507 --> 00:21:26.778 Now it's just gonna initialize to 0, but it's gonna recognize
00:21:26.778 --> 00:21:29.943 it the same way as effectively null, but it's gonna be a 0.
00:21:29.943 --> 00:21:33.002 Otherwise it's a contract invalid ID type of check. So we
00:21:33.002 --> 00:21:36.167 have our shared project here. That's where our data is. The
00:21:36.167 --> 00:21:39.491 searching is a bunch of filter buys that get generated as well
00:21:39.491 --> 00:21:42.708 extended ones that you make custom so that you don't have to
00:21:42.708 --> 00:21:46.085 write all the where statements that get super complex yourself,
00:21:46.085 --> 00:21:49.408 you just call the filter bias and pass the filter data through
00:21:49.408 --> 00:21:51.307 it and it will take care of itself.
00:21:52.567 --> 00:21:56.184 The interfaces is the next layer which is so that we can use DI
00:21:56.184 --> 00:21:59.350 on everything. We have everything coded to an interface
00:21:59.350 --> 00:22:02.798 with the exception of a few static types of concrete classes
00:22:02.798 --> 00:22:06.358 that we use that are not meant to be changed. I never meant to
00:22:06.358 --> 00:22:09.750 be replaceable because they're meant to be just like it's a
00:22:09.750 --> 00:22:12.915 lookup key or something like that, so we don't actually
00:22:12.915 --> 00:22:16.306 change out those things or anything else, even in tests. So
00:22:16.306 --> 00:22:19.811 we just keep those static. So all the interfaces for the data
00:22:19.811 --> 00:22:22.637 transfer objects will be here in the models here.
00:22:23.047 --> 00:22:26.046 And then the workflows will be the interfaces of the workflows
00:22:26.046 --> 00:22:28.997 and any providers that are in there as well. These would have
00:22:28.997 --> 00:22:31.996 been separate projects and they were at one point, but because
00:22:31.996 --> 00:22:34.757 they're you might be passing workflows into providers you
00:22:34.757 --> 00:22:37.471 might be providing passing providers into workflows they
00:22:37.471 --> 00:22:40.184 had to reference each other and keeping them in separate
00:22:40.184 --> 00:22:43.183 projects was no longer feasible. So we have them in. One thing
00:22:43.183 --> 00:22:45.087 here as its own subfolder of providers.
00:22:47.357 --> 00:22:50.459 Umm. Bottles of mapping is this is the concretes version of the
00:22:50.459 --> 00:22:53.318 interfaces. Here those are paired and whatever is going on
00:22:53.318 --> 00:22:56.469 inside these things. So you have to generated and extended files
00:22:56.469 --> 00:22:59.474 generated. One says reputation stuff so you have to write the
00:22:59.474 --> 00:23:02.430 boilerplate code yourself. It will take care of that for you
00:23:02.430 --> 00:23:05.435 and then you extend the object with the other properties that
00:23:05.435 --> 00:23:08.198 are doing stuff in the latest version. Way more of these
00:23:08.198 --> 00:23:10.912 properties are now auto generated and you don't have to
00:23:10.912 --> 00:23:13.675 deal with them anymore. It's really just the convenience
00:23:13.675 --> 00:23:16.680 extra properties that you're gonna write into these files now
00:23:16.680 --> 00:23:18.667 whereas the rest are all auto generated.
00:23:19.167 --> 00:23:21.316 And they do the necessary modifications and necessary
00:23:21.316 --> 00:23:23.783 flattening properties for those things automatically for you.
00:23:23.783 --> 00:23:24.977 You have to take care of them.
00:23:25.637 --> 00:23:29.447 Umm. The models also have search models which are queryable
00:23:29.447 --> 00:23:33.130 versions of those things. So like if I go to a rate quote
00:23:33.130 --> 00:23:36.940 search model it generated a search model that allows you to
00:23:36.940 --> 00:23:40.559 filter by selected shipping carrier method on minimum or
00:23:40.559 --> 00:23:44.242 maximum CART hash ID or number value. That kind of stuff,
00:23:44.242 --> 00:23:48.370 purchase order IDs and lookups, minimum rates for the things and
00:23:48.370 --> 00:23:52.180 or it must match this rate exactly. Values including nulls.
00:23:52.180 --> 00:23:56.116 It has weird lookups and those things should encourage you to
00:23:56.116 --> 00:23:56.307 go.
00:23:56.647 --> 00:23:59.725 Play around and look at what those kind of results do with
00:23:59.725 --> 00:24:02.803 postman and figure out what they are and they all of these
00:24:02.803 --> 00:24:05.620 generated properties should batch filter buys and the
00:24:05.620 --> 00:24:08.854 searching thing to pass data too. So if I go back to the same
00:24:08.854 --> 00:24:11.775 thing here with the shipping and look at the rate quote
00:24:11.775 --> 00:24:12.297 generated.
00:24:13.427 --> 00:24:16.252 I should see filter rate quotes by min rate, Max rate, match
00:24:16.252 --> 00:24:19.308 rate and then like it passes the match rate include null to that.
00:24:19.308 --> 00:24:22.225 So that's one to one matching and all of those properties that
00:24:22.225 --> 00:24:25.142 are being able to generated for you to give you the ability to
00:24:25.142 --> 00:24:27.874 go in and do whatever kind of querying you would generally
00:24:27.874 --> 00:24:30.791 need. And then you just extend it beyond that with extra stuff
00:24:30.791 --> 00:24:32.597 and you apply those into the workflow.
00:24:34.177 --> 00:24:35.177 For for what you need there.
00:24:35.877 --> 00:24:39.475 Mapping layer is just mapping between the data. The data
00:24:39.475 --> 00:24:43.325 record versus the DIO record or DTO model. It's passing that
00:24:43.325 --> 00:24:44.587 data back and forth.
00:24:44.987 --> 00:24:48.045 Umm, that stuff so it it tries to build as efficient as
00:24:48.045 --> 00:24:51.431 possible SQL queries including using expressions and stuff so
00:24:51.431 --> 00:24:53.397 that we have to repeat query calls.
00:24:54.717 --> 00:24:57.875 And for that stuff, if you're in a situation where those where
00:24:57.875 --> 00:25:00.983 these things don't work for what you're trying to do, because
00:25:00.983 --> 00:25:03.941 whatever you trying to do is super complex or require some
00:25:03.941 --> 00:25:06.899 super thing, you could just write your own mapper like the
00:25:06.899 --> 00:25:09.857 product Mapper has its own mapper because of how it has to
00:25:09.857 --> 00:25:12.664 handle the mapping. And that thing in such an efficient
00:25:12.664 --> 00:25:15.421 manner. I had to write a hyperspecific 1 to cover that
00:25:15.421 --> 00:25:18.529 same thing for CART is that the carts do session and whatever
00:25:18.529 --> 00:25:21.838 maps because cards are loaded on every page every time. There's a
00:25:21.838 --> 00:25:24.946 lot of extra stuff that has to go into this to make sure that
00:25:24.946 --> 00:25:25.247 it is.
00:25:25.317 --> 00:25:28.602 Performance as possible for all of these different things. So we
00:25:28.602 --> 00:25:31.584 have to make these other tiny modifications to it to to do
00:25:31.584 --> 00:25:31.837 that.
00:25:32.847 --> 00:25:33.387 Umm.
00:25:34.827 --> 00:25:37.980 The next tier is the providers. That's where the providers are.
00:25:37.980 --> 00:25:40.887 If you're looking for a check out provider, you would come
00:25:40.887 --> 00:25:43.794 over to providers, find the provider in here and this goes
00:25:43.794 --> 00:25:46.750 start mucking around with this thing. Or you probably might
00:25:46.750 --> 00:25:49.952 have it an override of what you were doing. You were workflow or
00:25:49.952 --> 00:25:53.056 provider in here and you would go play with it inside here and
00:25:53.056 --> 00:25:56.159 inherit and override individual functions. You have to rewrite
00:25:56.159 --> 00:25:56.997 the entire class.
00:25:58.317 --> 00:26:01.192 Of here so you could inherit target order checkout and then
00:26:01.192 --> 00:26:04.164 override a particular virtual function and if it's a function
00:26:04.164 --> 00:26:07.183 is not virtual, you can make it function virtual. That's fine.
00:26:07.183 --> 00:26:09.962 So like you might override the analyze async or you might
00:26:09.962 --> 00:26:11.927 override some specific function in here.
00:26:13.157 --> 00:26:16.438 Like the update shipping content for CART whatever like maybe
00:26:16.438 --> 00:26:19.878 this isn't doing what you needed to do. You would take it off of
00:26:19.878 --> 00:26:21.307 static and make it virtual.
00:26:22.197 --> 00:26:23.237 And protected.
00:26:24.277 --> 00:26:26.384 And now you can override it inside your overridden class and
00:26:26.384 --> 00:26:26.937 take care of it.
00:26:29.377 --> 00:26:31.435 So if you need to do that with with when you're working on
00:26:31.435 --> 00:26:33.457 Seth, if most of you are not working on stuff you're only
00:26:33.457 --> 00:26:34.957 doing connecting you don't to worry about.
00:26:36.907 --> 00:26:38.477 But the safe guy worried about that.
00:26:39.057 --> 00:26:42.794 Umm, so you got your checkouts, your taxes, your address
00:26:42.794 --> 00:26:46.860 validation, your authentication. So this is like Octa and our
00:26:46.860 --> 00:26:48.827 regular ethnic identity setup.
00:26:49.957 --> 00:26:53.140 You know a proxy for in case you have to do something internally
00:26:53.140 --> 00:26:56.372 that has to talk through a proxy in order to get to something. We
00:26:56.372 --> 00:26:58.919 had a client where we were talking, we had a direct
00:26:58.919 --> 00:27:02.004 integration with like Alex or something and we had to have the
00:27:02.004 --> 00:27:04.894 proxy there so that we could have its traffic flow through
00:27:04.894 --> 00:27:07.587 that for external communications to the AX, excuse me.
00:27:09.457 --> 00:27:11.957 You know, e-mail providers, all the emails that go in there.
00:27:12.767 --> 00:27:16.490 All that stuff is inside there. Business logic is the main crud
00:27:16.490 --> 00:27:20.039 logic for most tables. There's gonna be a generated file for
00:27:20.039 --> 00:27:23.239 each one, and that generator will be the standard CRUD
00:27:23.239 --> 00:27:26.904 workflow that we have. So you have create, update, deactivate,
00:27:26.904 --> 00:27:30.685 reactivate, delete resolves that basically are extended expanded
00:27:30.685 --> 00:27:34.176 versions of lookups. You have the main search query and you
00:27:34.176 --> 00:27:37.550 have to like get by ID you get by key get by name, get by
00:27:37.550 --> 00:27:41.215 display name up a bunch of stuff like that. So it's a bunch of
00:27:41.215 --> 00:27:42.437 extended versions of.
00:27:42.707 --> 00:27:45.982 Those things and then the auto assign what the mappers would be
00:27:45.982 --> 00:27:48.898 out of the mapping layer whenever it's trying to pull it
00:27:48.898 --> 00:27:52.173 out and then these things can be overridden and extended files.
00:27:52.173 --> 00:27:53.247 So like the accounts.
00:27:54.097 --> 00:27:57.346 I have the jittered one and I have my extended one. It's a
00:27:57.346 --> 00:28:00.871 partial class and in my partial I can override what I'm telling
00:28:00.871 --> 00:28:01.367 it to do.
00:28:01.887 --> 00:28:06.017 Umm by default. So if I can find an override here?
00:28:07.737 --> 00:28:10.401 But over right here filter, filter query model by custom
00:28:10.401 --> 00:28:13.252 model. So like I might do like the base and then override it
00:28:13.252 --> 00:28:14.327 with this custom stuff.
00:28:15.387 --> 00:28:18.520 So these are not autogenerated filter bias. I'm adding these
00:28:18.520 --> 00:28:21.549 two specifically so those are part of my search model, and
00:28:21.549 --> 00:28:24.117 then I'm adding them to my filters on this stuff.
00:28:24.927 --> 00:28:27.636 And then assign additional properties. I'm doing some
00:28:27.636 --> 00:28:30.797 custom flows here to make sure that if no type information got
00:28:30.797 --> 00:28:33.657 passed, I automatically assign the customer if no status
00:28:33.657 --> 00:28:36.517 information got passed, I automatically assign normal on
00:28:36.517 --> 00:28:39.377 it. So that's where we're applying custom workflows onto
00:28:39.377 --> 00:28:42.388 things where the defaults would not have covered themselves
00:28:42.388 --> 00:28:45.298 automatically and you can see here I'm doing it where I'm
00:28:45.298 --> 00:28:48.559 updating the account model. I'm applying those defaults in there
00:28:48.559 --> 00:28:51.118 and then I just go back to running my default auto
00:28:51.118 --> 00:28:54.279 generated related workflows and then I come back and go OK let
00:28:54.279 --> 00:28:56.537 me clean up some stuff for the address book.
00:28:57.107 --> 00:28:59.362 And make sure the address book gets cleaned up and associated
00:28:59.362 --> 00:29:01.727 correctly and then I will go run my default associate workloads.
00:29:02.947 --> 00:29:05.935 For those things for associating, you know, accounts
00:29:05.935 --> 00:29:08.923 to products or or users or whatever. In my associate
00:29:08.923 --> 00:29:09.487 workflows.
00:29:10.427 --> 00:29:12.897 And then I have a custom delete here overridden.
00:29:13.937 --> 00:29:17.818 Where I can't delete the account if it has these other records in
00:29:17.818 --> 00:29:21.464 here cause not cascade deleting because they prevents cascade
00:29:21.464 --> 00:29:25.110 deleting bloops. So I manually go through and wipe out things
00:29:25.110 --> 00:29:27.697 like the images and associations and users.
00:29:28.197 --> 00:29:30.933 Umm that would or or at least the association to them. So
00:29:30.933 --> 00:29:33.670 that's like the users here. I just dissociate it from the
00:29:33.670 --> 00:29:36.595 user. I don't delete the user when I'm deleting here and then
00:29:36.595 --> 00:29:39.426 I go through and save on each loop and make sure that these
00:29:39.426 --> 00:29:42.398 things get cleaned up. And then when I'm done with that, I can
00:29:42.398 --> 00:29:45.323 go back and call the base like normal delete function itself.
00:29:45.323 --> 00:29:48.107 So if you're trying to wipe out data, this is one of those
00:29:48.107 --> 00:29:50.891 things that it would do is it would go through and try and
00:29:50.891 --> 00:29:53.863 wipe out additional data that would have been dependent on the
00:29:53.863 --> 00:29:55.467 account to clear those things up.
00:29:56.977 --> 00:30:00.551 So that's where the workflows are and that's most of the back
00:30:00.551 --> 00:30:03.952 end. The last piece is really just the service layer. When
00:30:03.952 --> 00:30:07.641 you're in connect, you're mostly talking to the API itself, not
00:30:07.641 --> 00:30:11.388 the API store phone or API admin and that's this one which loads
00:30:11.388 --> 00:30:14.674 everything. Every endpoint we have gets loaded into that
00:30:14.674 --> 00:30:17.845 instance of. It does not restrict itself to the having
00:30:17.845 --> 00:30:21.303 the used in storefront or used it in admin type tags on the
00:30:21.303 --> 00:30:21.707 routes.
00:30:22.257 --> 00:30:25.414 Umm but yeah, so you you'd be hitting this one and you'd be
00:30:25.414 --> 00:30:28.675 logging in or logging into it and and doing all the stuff and
00:30:28.675 --> 00:30:31.621 things. So like, if you have product routes that you're
00:30:31.621 --> 00:30:31.937 gonna.
00:30:33.987 --> 00:30:36.887 You could have your your break point to.
00:30:38.027 --> 00:30:40.472 You know, like, if you're gonna call this get options page is
00:30:40.472 --> 00:30:42.247 from act. You have your break point in here.
00:30:43.397 --> 00:30:45.765 And you would attach and you would. It would come into this
00:30:45.765 --> 00:30:48.370 endpoint and then it would go in and do what it's gonna do and it
00:30:48.370 --> 00:30:50.659 would pass into the workflows layer, the providers layer,
00:30:50.659 --> 00:30:51.567 whatever it's gonna do.
00:30:52.967 --> 00:30:55.427 Inside the endpoint to go to go touch and and do stuff.
00:30:56.427 --> 00:30:57.457 Once the build is done now.
00:30:56.537 --> 00:30:59.106 You know, probably have you demo that too, James to be like, OK,
00:30:59.106 --> 00:31:01.635 here's a call. It's getting me from the front end. Here's where
00:31:01.635 --> 00:31:04.125 it goes in. Let's send a bright point and kind of step through
00:31:04.125 --> 00:31:04.757 it that way too.
00:31:05.657 --> 00:31:05.937 Why?
00:31:07.487 --> 00:31:10.590 The last part is really just all the portals. These are all for
00:31:10.590 --> 00:31:13.790 the storefront and everything or for vendor admin or one of those
00:31:13.790 --> 00:31:16.942 other ones. Or like the signalr. If you're dealing with connect,
00:31:16.942 --> 00:31:19.899 you won't mess with any of these because connect is gonna be
00:31:19.899 --> 00:31:22.760 talking to this guy instead. But if you're trying to debug
00:31:22.760 --> 00:31:25.669 something for the store front, we can go over that too, and
00:31:25.669 --> 00:31:28.627 that will be where we start touching it. We attach to one of
00:31:28.627 --> 00:31:31.682 these instead. You also have the client override project where
00:31:31.682 --> 00:31:34.494 there might be endpoints inside here that like re account
00:31:34.494 --> 00:31:37.306 service. Here's an endpoint that's been used by the store
00:31:37.306 --> 00:31:37.597 front.
00:31:37.967 --> 00:31:41.192 And then here's the endpoint handler from it. So if I need to
00:31:41.192 --> 00:31:44.312 hit this from the storefront perspective, I'd have my break
00:31:44.312 --> 00:31:47.589 point in here and it should hit it when I attach, this will be
00:31:47.589 --> 00:31:49.877 loaded into as I'm this done, indent there.
00:31:50.997 --> 00:31:54.977 This should be loaded into the the.
00:31:55.727 --> 00:31:58.728 API for connect there because it is an endpoint that does allow
00:31:58.728 --> 00:32:01.777 to all endpoints, but it's less likely that you would hit one of
00:32:01.777 --> 00:32:04.544 these and unless you're like actually like this, something
00:32:04.544 --> 00:32:05.857 specific in here for Kinect.
00:32:07.077 --> 00:32:09.621 On a most of these end up being just like store front end points
00:32:09.621 --> 00:32:10.287 for them to call.
00:32:12.787 --> 00:32:14.964 Uh, that said, I'm gonna undo that change because I just
00:32:14.964 --> 00:32:17.331 realized that we're trying to attach and we just do the build
00:32:17.331 --> 00:32:18.057 to make that match.
00:32:19.707 --> 00:32:22.699 OK. And then we have a testing layer which is where all of our
00:32:22.699 --> 00:32:25.644 tests are. I won't go do that. And then the T4 are just these
00:32:25.644 --> 00:32:28.779 are these are helpers for the T4 so they can generate appropriate
00:32:28.779 --> 00:32:31.344 code and then your solution items which is our config
00:32:31.344 --> 00:32:32.057 settings files.
00:32:32.707 --> 00:32:32.967 OK.
00:32:33.677 --> 00:32:36.546 That's pretty much the entire like tier architecture for it. I
00:32:36.546 --> 00:32:39.369 could go into more detail and specific areas and other times,
00:32:39.369 --> 00:32:42.147 but I don't want to overburden and I know we're trying to do
00:32:42.147 --> 00:32:44.924 debugging here. So I'm what I'm gonna do now is I'm going to
00:32:44.924 --> 00:32:46.017 attach my control alt P.
00:32:47.217 --> 00:32:50.423 And when it when? When the window comes up Visual Studio
00:32:50.423 --> 00:32:53.967 2022 and later fixed it so that you can actually see the title
00:32:53.967 --> 00:32:57.623 of the app pool inside here. So you don't have to go look up the
00:32:57.623 --> 00:33:01.111 process ID anymore. What we used to have to do and that's why
00:33:01.111 --> 00:33:04.542 these are here is we have to go actually hit it and find out
00:33:04.542 --> 00:33:07.973 what was going on there. Now I can see here I have my API is
00:33:07.973 --> 00:33:11.461 not running right now. So if there was a connect to attach to
00:33:11.461 --> 00:33:15.117 I will that run that later then I would have expected the API to
00:33:15.117 --> 00:33:17.817 be alive and running for connect to be hitting.
00:33:19.327 --> 00:33:22.836 It's gonna just not there. It's not doing anything. I'm gonna go
00:33:22.836 --> 00:33:25.751 ahead and attach to the storefront, and we'll just do
00:33:25.751 --> 00:33:29.207 something from the store front for now. So that's 38012. I will
00:33:29.207 --> 00:33:32.554 type W3W into here. I can't do Rio because it won't filter by
00:33:32.554 --> 00:33:35.793 that. Because that's secondary data that it loads after the
00:33:35.793 --> 00:33:39.194 fact. But I can see that Raqqa is the last one here. If I sort
00:33:39.194 --> 00:33:42.433 by this, I can see all the different because they're sorted
00:33:42.433 --> 00:33:43.837 by the app will name here.
00:33:45.057 --> 00:33:47.937 I could find RE if it wasn't at the top of list and or like I
00:33:47.937 --> 00:33:51.003 was in a hard time finding it. I could sort by that and just come
00:33:51.003 --> 00:33:53.512 down and find it if I want to debug something for the
00:33:53.512 --> 00:33:56.345 scheduler then I'm gonna touch the scheduler if I want debug
00:33:56.345 --> 00:33:59.179 something for the API store front I just to the store front.
00:33:59.179 --> 00:34:02.059 If I want to debug something that's coming in through connect
00:34:02.059 --> 00:34:05.032 then I might attach to if it's the connect solution that's open
00:34:05.032 --> 00:34:07.959 I would attach to the CONNECT tool. If it's the CEF solution I
00:34:07.959 --> 00:34:10.793 would attach to the API with no store runner admin on it for
00:34:10.793 --> 00:34:13.487 example we're here, I'm going to do these API storefront.
00:34:13.987 --> 00:34:14.617 Will attach.
00:34:15.907 --> 00:34:18.932 Now we'll attach it to the API, catch all calls, or are there
00:34:16.207 --> 00:34:16.867 And then.
00:34:18.932 --> 00:34:20.737 separate between API storefront API?
00:34:21.327 --> 00:34:24.557 They they are separate app pools and app domains so so attached
00:34:24.557 --> 00:34:27.584 to 1 does not attach to them all you can attach to multiple
00:34:27.584 --> 00:34:30.814 things at the same time so I am attached to that one right now.
00:34:30.814 --> 00:34:34.044 If I hit control AP I can select another one and be attached to
00:34:34.044 --> 00:34:34.397 it too.
00:34:35.557 --> 00:34:35.887 Gotcha.
00:34:35.917 --> 00:34:38.466 It it's a little weird in a couple of things. Like it
00:34:38.466 --> 00:34:41.346 doesn't necessarily give you some of the information because
00:34:41.346 --> 00:34:43.990 it doesn't. It's hard to identify which app Pool is the
00:34:43.990 --> 00:34:46.728 one that where you hit like a break point and it actually
00:34:46.728 --> 00:34:47.247 stopped on.
00:34:49.297 --> 00:34:52.647 In there and and like the the the events list here I believe
00:34:52.647 --> 00:34:56.051 only does it to what the like the first one that you attached
00:34:56.051 --> 00:34:59.620 to. So there's a few limitations to it. But if you had to attach
00:34:59.620 --> 00:35:01.817 to multiple things, you absolutely can.
00:35:02.567 --> 00:35:04.717 And it for the most part works.
00:35:05.387 --> 00:35:08.640 Umm, unless you get into some weird scenario that something's
00:35:08.640 --> 00:35:10.267 going wrong. So like right now.
00:35:11.007 --> 00:35:12.647 I think I'm attached to two things now. Am I?
00:35:13.447 --> 00:35:16.053 And it will show me that I'm attached to these two things. So
00:35:16.053 --> 00:35:18.407 like these two are locked. I can't attach to them again
00:35:18.407 --> 00:35:21.055 because I'm already attached to them. You should never have to
00:35:21.055 --> 00:35:23.157 attach to DNA. There's no reason to ever do that.
00:35:25.397 --> 00:35:28.894 On there. But I've attached two things right now and I could put
00:35:28.894 --> 00:35:32.283 a break point in on something that like the scheduler would be
00:35:32.283 --> 00:35:35.027 running like a scheduled task for like the emails.
00:35:35.777 --> 00:35:38.746 Umm, so the process emails are supposed to happen every minute.
00:35:38.746 --> 00:35:41.762 Process, e-mail, batch task. If I come into this thing and put a
00:35:41.762 --> 00:35:44.638 break point in here, then within a minute the schedule should
00:35:44.638 --> 00:35:47.097 have fired off this job and it should stop all this.
00:35:52.117 --> 00:35:56.018 I don't want to zoom out too much as I wanna make sure people
00:35:56.018 --> 00:35:59.919 can actually read their stuff while that's waiting, let me go
00:35:59.919 --> 00:36:03.568 to say the service and the products and go to the product
00:36:03.568 --> 00:36:05.707 service and let me find like the.
00:36:07.787 --> 00:36:10.872 A minimum minify with control M control O to collapse to this
00:36:10.872 --> 00:36:11.917 function definitions.
00:36:12.537 --> 00:36:15.517 And then get products by ID's. I'll put a break point in that.
00:36:16.517 --> 00:36:18.850 I'm gonna something that the catalog would do and then like
00:36:18.850 --> 00:36:20.327 get product by ID's another good one.
00:36:21.677 --> 00:36:22.177 I'm.
00:36:23.377 --> 00:36:26.449 Good one that like I know what could hit a lot. Oh, OK. So
00:36:26.449 --> 00:36:29.469 here's the scheduler that I'm attached to. This is it. If
00:36:29.469 --> 00:36:32.697 fired to the job for process e-mail batch task and now I'm on
00:36:32.697 --> 00:36:35.821 my break point inside here and I can debug this. So to give
00:36:35.821 --> 00:36:39.049 myself more room I'll collapse the left sidebar and I can see
00:36:39.049 --> 00:36:41.705 it's going to log some information to cancellation
00:36:41.705 --> 00:36:44.985 token did not fire off that it needed to be cancelled. I'll do
00:36:44.985 --> 00:36:48.213 a step so F-10 I'll go F-11 to step into my function here the
00:36:48.213 --> 00:36:51.441 system processes an e-mail batch well it stopped on the batch
00:36:51.441 --> 00:36:52.587 size so I'll step out.
00:36:53.467 --> 00:36:56.788 I'll step in again, and now I'm inside the function. It's going
00:36:56.788 --> 00:37:00.056 to resolve the status IDs out, so I'll just have 10 pass those
00:37:00.056 --> 00:37:00.627 real quick.
00:37:01.317 --> 00:37:04.514 And now in memory I have my pending status idea of 1. We're
00:37:04.514 --> 00:37:07.657 trying status idea of two and retrying failed status ID of
00:37:07.657 --> 00:37:07.977 three.
00:37:09.317 --> 00:37:12.655 So those are there. I can look at my watch here. I can write a
00:37:12.655 --> 00:37:15.781 watch that would write whatever the the locals window will
00:37:15.781 --> 00:37:18.642 automatically include all parameters, static values I
00:37:18.642 --> 00:37:21.556 think and the any local variables that are created. It
00:37:21.556 --> 00:37:24.894 just automatically appends them to this window. Now they maybe
00:37:24.894 --> 00:37:28.020 know because they have been initialized yet like I have an
00:37:28.020 --> 00:37:31.305 initialized the context. But when I step one more time you'll
00:37:31.305 --> 00:37:34.696 see that it switches from null to applied of an actual value of
00:37:34.696 --> 00:37:37.981 a database entity. And I can expand and look at the types and
00:37:37.981 --> 00:37:40.047 look at the SQL that it would run and.
00:37:40.367 --> 00:37:40.967 Stuff like that.
00:37:41.487 --> 00:37:45.087 Umm, I'm going to await this e-mail queues pulling them in to
00:37:45.087 --> 00:37:48.745 drink it a batch of instead. In step forward it looks like the
00:37:48.745 --> 00:37:51.881 count is gonna be 0, so it's gonna exit this function
00:37:51.881 --> 00:37:55.539 positively because there's no e-mail for it to physically send
00:37:55.539 --> 00:37:58.849 at the moment I see this formatting here, so if I change
00:37:58.849 --> 00:38:02.508 this formatting, the file will no longer match and it will say
00:38:02.508 --> 00:38:03.727 that I can't do that.
00:38:05.097 --> 00:38:07.709 So if I hit save on that file now or I didn't have to hit
00:38:07.709 --> 00:38:10.592 save, it will just complain. So if I start to step again, if it
00:38:10.592 --> 00:38:11.087 tell me no.
00:38:12.857 --> 00:38:15.156 Flying code update. Yes, see it can't apply the code and Nate
00:38:15.156 --> 00:38:17.232 update because this is .NET Framework was allowed to do
00:38:17.232 --> 00:38:17.417 that.
00:38:18.127 --> 00:38:21.382 And then now it says the source is not found because it doesn't
00:38:21.382 --> 00:38:24.689 match. It gives me the option to decompile the source code which
00:38:24.689 --> 00:38:25.757 is looking at the IL.
00:38:26.507 --> 00:38:29.665 Umm and try to match it up a little bit so I can still try to
00:38:29.665 --> 00:38:32.873 debug it a little bit and it's it's a lot harder to debug, but
00:38:32.873 --> 00:38:35.267 it's still kind of possible in some scenarios.
00:38:38.237 --> 00:38:40.017 So we'll let that try and run.
00:38:46.447 --> 00:38:47.627 I actually changed them there but.
00:38:48.707 --> 00:38:50.597 It was trying to offer to save it again.
00:38:53.617 --> 00:38:55.297 Uh, it didn't do it. We try it again.
00:38:57.237 --> 00:39:00.378 Frame not in module, you just assembly noticeably available.
00:39:00.378 --> 00:39:03.673 OK, so it basically it screwed up, so it wasn't gonna let me do
00:39:03.673 --> 00:39:03.827 it.
00:39:04.477 --> 00:39:05.027 Umm.
00:39:05.997 --> 00:39:07.947 Oh, no, here it is. This is it. This is the.
00:39:08.807 --> 00:39:12.253 The decompiled the version of it that basically got as close as
00:39:12.253 --> 00:39:14.837 it could to recreating the what what was there.
00:39:15.347 --> 00:39:18.747 Umm. On the stuff it does a pretty good job about this, so
00:39:18.747 --> 00:39:22.378 you'll get like, you know, at least enough to make it somewhat
00:39:22.378 --> 00:39:25.836 legible to your eyeballs, but it may not be the most 1 to 1
00:39:25.836 --> 00:39:29.524 matching to what was originally written. So if I come in here I
00:39:29.524 --> 00:39:33.155 could try and put a breakpoint inside here and have it stop on
00:39:33.155 --> 00:39:36.555 stuff. It's gonna tell me that it doesn't match the thing.
00:39:36.555 --> 00:39:39.437 Maybe it will let me go to debug options. Whoops.
00:39:40.077 --> 00:39:41.297 That options.
00:39:42.147 --> 00:39:45.607 And go to the debug and say must match the source file.
00:39:49.797 --> 00:39:52.260 Our source also met exactly matched the original version, so
00:39:52.260 --> 00:39:52.947 I unchecked that.
00:39:53.727 --> 00:39:55.477 And it might let that breakpoint work.
00:39:59.267 --> 00:40:01.549 We'll see. I put a break point and it put it over in the actual
00:40:01.549 --> 00:40:01.727 file.
00:40:03.727 --> 00:40:06.459 Though it just it just weird stuff like that. So like it's
00:40:06.459 --> 00:40:09.236 it's harder, but it's still possible to kind of get some of
00:40:09.236 --> 00:40:12.199 that data back out to look at it whenever the that's happening.
00:40:12.199 --> 00:40:15.116 But generally speaking whatever. So I would I'm gonna continue
00:40:15.116 --> 00:40:15.857 and let that go.
00:40:18.287 --> 00:40:21.056 And I'm gonna take this break point off and just like that. So
00:40:21.056 --> 00:40:23.826 I stopped stopping inside that thing. Stop. It's like here and
00:40:23.826 --> 00:40:24.837 see what I get instead.
00:40:25.677 --> 00:40:28.245 So what I want to do is I want to hit the website somewhere.
00:40:28.245 --> 00:40:29.677 I'm go and open the browser here.
00:40:31.127 --> 00:40:34.367 And look at a binding for Rae that is valid.
00:40:35.557 --> 00:40:36.207 Yay.
00:40:37.747 --> 00:40:38.597 He connect you is.
00:40:38.197 --> 00:40:41.362 Can you pull up the the API too so we can see all the endpoints
00:40:41.362 --> 00:40:41.857 available?
00:40:44.867 --> 00:40:45.737 Uh.
00:40:47.577 --> 00:40:48.147 No.
00:40:47.787 --> 00:40:48.937 What are I is?
00:40:51.257 --> 00:40:52.967 There are relationship website.
00:40:51.857 --> 00:40:52.527 That was this.
00:40:55.337 --> 00:40:56.497 This is alright, that's all I.
00:40:58.747 --> 00:40:59.667 I don't know what that was.
00:40:59.227 --> 00:40:59.927 I don't think so.
00:41:01.317 --> 00:41:04.116 I didn't, but that came up like automatically. I wonder if
00:41:02.747 --> 00:41:03.937 I didn't know that.
00:41:04.116 --> 00:41:05.397 there's like a thing I had.
00:41:06.077 --> 00:41:08.087 Like that just opened and it was like, what the hell is this?
00:41:09.247 --> 00:41:12.357 OK, so there's BCC ice RI QA.
00:41:14.437 --> 00:41:16.197 So if I'm on this thing.
00:41:17.297 --> 00:41:20.447 Wondering if I can get to like a stop showing me that.
00:41:21.117 --> 00:41:22.237 That's just go away right now.
00:41:23.127 --> 00:41:26.396 I don't need this thing was gonna close that. I'm gonna go
00:41:26.396 --> 00:41:27.227 to the catalog.
00:41:28.217 --> 00:41:30.897 By clicking on shop and browse categories.
00:41:31.977 --> 00:41:33.017 We'll see what's in here.
00:41:33.767 --> 00:41:37.187 I'm hoping one of these like calls. It's something that.
00:41:38.067 --> 00:41:38.587 I.
00:41:40.617 --> 00:41:42.757 The ****** is going to attach and stop on.
00:41:46.837 --> 00:41:49.881 Been really slow about it. OK, so there's a lot of gobble that
00:41:49.881 --> 00:41:52.877 go right here. I'm seeing jobs files that I don't need to see
00:41:52.877 --> 00:41:56.018 in all that stuff by waterfalls too wide for some reason. So I'm
00:41:56.018 --> 00:41:58.869 gonna set it up by dragging waterfalls narrow as possible.
00:41:58.869 --> 00:42:00.657 Turning off initiator turn off type.
00:42:01.527 --> 00:42:02.637 Add method.
00:42:03.737 --> 00:42:07.651 And the response headers content encoding so I can tell if it's
00:42:07.651 --> 00:42:08.507 using the the.
00:42:10.497 --> 00:42:13.833 The compression correctly or not. So like these are here the
00:42:13.833 --> 00:42:17.115 default the deflate to comma deflate. That's the safari bug
00:42:17.115 --> 00:42:20.506 issue that will happen. So this request can't be processed by
00:42:20.506 --> 00:42:23.679 Safari correctly without the fix. And then I'm gonna open
00:42:23.679 --> 00:42:27.288 this and turn off this overview. Use large request rows. So now I
00:42:27.288 --> 00:42:30.844 have my thing showing a lot more stuff. I'll click on fetch as I
00:42:30.844 --> 00:42:34.125 could Jr. which are all my requests I will control click JS
00:42:34.125 --> 00:42:37.626 and then I will do Slash API. So now I'm looking at just my API
00:42:37.626 --> 00:42:40.634 calls including the one call that goes against the SEC
00:42:40.634 --> 00:42:41.017 config.
00:42:41.827 --> 00:42:44.237 Umm, I think it's actually stuck.
00:42:45.007 --> 00:42:48.317 Because I'm attached and I think the attachment is freaking out.
00:42:49.207 --> 00:42:51.962 Which sometimes happens in these boxes where stuff is going on
00:42:51.962 --> 00:42:53.187 and it just doesn't like it.
00:42:55.317 --> 00:42:58.281 We're at 96% RAM, so that's not helpful. I'm gonna kick these
00:42:58.281 --> 00:43:00.097 things off that are all disconnected.
00:43:00.927 --> 00:43:02.197 That I can free up some RAM.
00:43:03.627 --> 00:43:06.174 Uh, when Ben changed the settings so that it would kick
00:43:06.174 --> 00:43:08.994 you off in a certain amount of time. He unfortunately changed
00:43:08.994 --> 00:43:11.814 it to the just disconnect you not actually fully kick you off
00:43:11.814 --> 00:43:13.497 is what it was supposed to be doing.
00:43:14.547 --> 00:43:17.619 To free up the resources and unlock files and folders and
00:43:17.619 --> 00:43:17.937 stuff.
00:43:19.177 --> 00:43:22.039 So I'll do that and that gives us a little more room.
00:43:22.039 --> 00:43:25.272 Fortunately, the virtual host is a little ram starved, so we
00:43:25.272 --> 00:43:27.657 can't add more RAM to these boxes right now.
00:43:33.237 --> 00:43:36.179 Yeah, I'm pretty sure one of these calls like is like this
00:43:36.179 --> 00:43:36.727 query here.
00:43:37.247 --> 00:43:38.997 Umm is is.
00:43:43.377 --> 00:43:46.179 Inside the server it wants to stop on it or it wants to at
00:43:46.179 --> 00:43:48.839 least determine that it is attached, but it's taking so
00:43:48.839 --> 00:43:50.027 long that it can't do it.
00:43:50.847 --> 00:43:53.332 Unfortunately, in a situation like this, you're at a point
00:43:53.332 --> 00:43:56.070 where if it won't come back, it won't come back. I've never been
00:43:56.070 --> 00:43:57.207 able to solve that problem.
00:43:58.227 --> 00:44:01.149 It did just start responding again though, so maybe it's it's
00:44:01.149 --> 00:44:01.667 good to go.
00:44:02.857 --> 00:44:04.007 As an attached thing.
00:44:05.507 --> 00:44:09.101 Since it is hitting that query endpoint, I wonder if I can get
00:44:09.101 --> 00:44:09.557 over to.
00:44:10.617 --> 00:44:12.737 Where that is, once this comes back up again.
00:44:18.877 --> 00:44:21.437 And get to that query endpoint and debug from there.
00:44:23.457 --> 00:44:25.559 I think it won't hit any of these until that query when
00:44:25.559 --> 00:44:26.047 resolves the.
00:44:29.527 --> 00:44:32.357 Doo Doo Doo Doo Doo Doo Doo Doo, Doo Doo.
00:44:43.147 --> 00:44:43.697 Come on.
00:44:45.007 --> 00:44:45.867 We're out of time.
00:44:48.597 --> 00:44:50.467 Things were collapse all.
00:44:59.897 --> 00:45:00.827 White screen of death.
00:45:11.007 --> 00:45:14.058 Problem is, we have so many websites on these boxes that we
00:45:14.058 --> 00:45:17.212 don't necessarily need on there anymore. But like if a client
00:45:17.212 --> 00:45:20.314 has gone away, we need to be archiving this crap and getting
00:45:20.314 --> 00:45:21.077 it off the box.
00:45:21.827 --> 00:45:23.507 Umm so that they stopped taking up resources.
00:45:24.987 --> 00:45:28.127 But getting people to actually sit down and do that is, uh.
00:45:29.257 --> 00:45:30.167 Herding cats.
00:45:31.367 --> 00:45:31.857 Umm.
00:45:32.487 --> 00:45:33.287 Times 100.
00:45:38.507 --> 00:45:39.297 Mine claps.
00:45:41.037 --> 00:45:41.577 You something?
00:45:51.797 --> 00:45:52.987 Bring that up is.
00:45:51.907 --> 00:45:54.244 If you want to show this part of your locals, you two, you can
00:45:54.244 --> 00:45:54.467 James.
00:45:57.507 --> 00:46:02.005 James bringing that up, is there a process for archiving old
00:46:02.005 --> 00:46:06.355 stuff like Como for instance, comma might come out QA here
00:46:06.355 --> 00:46:10.631 soon and then do you is who's supposed to be in charge of
00:46:10.631 --> 00:46:14.834 archiving. That is it the developer or is it somebody on
00:46:14.834 --> 00:46:16.087 the systems side?
00:46:15.307 --> 00:46:17.825 We that's part of the problem is we don't have anyone who
00:46:17.825 --> 00:46:20.517 actually has ownership of the process. I'm the only one who's
00:46:20.517 --> 00:46:23.382 ever really driven it, trying to make sure, like, hey, we need to
00:46:23.382 --> 00:46:26.117 move this crap off so we have more room in the boxes and then.
00:46:27.107 --> 00:46:29.904 Either I have end up doing it myself or it is fell on deaf
00:46:29.904 --> 00:46:32.890 ears and just doesn't get done. I've seen Chris do it a couple
00:46:32.890 --> 00:46:33.317 of times.
00:46:34.517 --> 00:46:37.670 For stuff that's known, but also just trying to get to the list
00:46:37.670 --> 00:46:40.626 from the PMS, that would be really gunshy about. They don't
00:46:40.626 --> 00:46:43.483 want to archive something. There's a possibility they may
00:46:43.483 --> 00:46:46.439 come back. I'm like, come on, it's been production plus 90.
00:46:46.439 --> 00:46:49.148 They've stopped asking us for anything but or they are
00:46:49.148 --> 00:46:52.202 different direction with their project and stopped going with
00:46:52.202 --> 00:46:54.567 us. Whatever reason, let's move it off the box.
00:46:55.777 --> 00:46:59.134 The idea is that you would take all the physical code files, zip
00:46:59.134 --> 00:47:02.180 them up. You might remove some of the bin folders from the
00:47:02.180 --> 00:47:05.382 secondary directories, but leave the ones for like the actual
00:47:05.382 --> 00:47:08.636 output like web folders and like we're connects output folders
00:47:08.636 --> 00:47:09.307 and stuff is.
00:47:10.947 --> 00:47:14.944 To become smaller, zip all that up with ultra compression on 7
00:47:14.944 --> 00:47:19.069 zip files and then you pick them up and move them all to the Nas
00:47:19.069 --> 00:47:23.066 and in the same folder structure and then you remove the sites
00:47:23.066 --> 00:47:23.637 from IIS.
00:47:24.397 --> 00:47:24.977 Umm.
00:47:25.977 --> 00:47:29.121 So that they're just gone from the box and that way it's at
00:47:29.121 --> 00:47:32.369 least reasonably not that hard to bring them back because you
00:47:32.369 --> 00:47:35.513 basically just kind of come back, unzip the files that were
00:47:35.513 --> 00:47:38.867 there and then point a new IIS instance at those folders and to
00:47:38.867 --> 00:47:39.967 get it running again.
00:47:40.527 --> 00:47:43.552 Umm. But at that point it would should have happened is is we
00:47:43.552 --> 00:47:46.235 weren't expecting that to come back anytime soon or or
00:47:46.235 --> 00:47:49.259 whatever. So there should have been any real need to do that.
00:47:49.259 --> 00:47:52.235 We also at some point maybe trying to get like a new server,
00:47:52.235 --> 00:47:55.260 a new main host VM host server which would be another like 80
00:47:55.260 --> 00:47:58.187 grand to try and make it more boxes that we can utilize and
00:47:58.187 --> 00:48:00.577 move more resources around. So that more of the.
00:48:01.377 --> 00:48:04.725 In turtle like operational stuff is away from where the dev stuff
00:48:04.725 --> 00:48:07.972 is being done as far as virtual machines, and we could dedicate
00:48:07.972 --> 00:48:11.270 more resources to the dev boxes themselves. Kind of thing. But I
00:48:11.270 --> 00:48:13.807 mean it depends on how that stuff goes long term.
00:48:15.547 --> 00:48:18.801 I did get this thing and it is behaving. It's now stopped at an
00:48:18.801 --> 00:48:22.004 end point. I'm gonna go to the elastic search and I'm gonna go
00:48:22.004 --> 00:48:25.207 to products and I'm gonna go to the elastic searching service.
00:48:26.107 --> 00:48:28.993 And the query endpoint for products is right here the
00:48:28.993 --> 00:48:32.145 search one. So I put a break point in there. It would stop
00:48:32.145 --> 00:48:35.459 there if it had already gotten past it and it ended this part
00:48:35.459 --> 00:48:38.398 you see here I've got get products by IDs, which means
00:48:38.398 --> 00:48:41.818 it's done the search, it's come back. And now I have my request
00:48:41.818 --> 00:48:45.131 which is a list of IDs to use. So this is a page worth. These
00:48:45.131 --> 00:48:48.604 are all the product IDs it wants me to look up and load into the
00:48:48.604 --> 00:48:51.918 page. So it's gonna come in and do the three or four requests
00:48:51.918 --> 00:48:55.017 part of it, which is the browser caching level that says.
00:48:56.497 --> 00:49:00.512 If they if the browsers already gotten the data and the data is
00:49:00.512 --> 00:49:04.464 will be timestamped based upon an updated date, that timestamp
00:49:04.464 --> 00:49:08.604 will say hey server, do you have anything new to give me for this
00:49:08.604 --> 00:49:12.619 particular request? The server will go, your timestamp is newer
00:49:12.619 --> 00:49:16.508 or matches the same data that I have, so I don't even need to
00:49:16.508 --> 00:49:20.398 send you new data so I don't have to do that processing. Keep
00:49:20.398 --> 00:49:22.217 what you got your good to go.
00:49:23.577 --> 00:49:27.256 If you're forcibly overwriting that cache by passing the no
00:49:27.256 --> 00:49:30.689 cache parameter on your free string or by a new request
00:49:30.689 --> 00:49:34.245 that's never been asked for before, or you're telling the
00:49:34.245 --> 00:49:37.923 server that it's not allowed to return cache using like the
00:49:37.923 --> 00:49:41.663 disable cache option inside your dev tools, so this disabled
00:49:41.663 --> 00:49:45.281 cache flag right here would make it so that it it sends an
00:49:45.281 --> 00:49:48.837 argument and header that says it's just not allowed to do
00:49:48.837 --> 00:49:52.760 that. Then it would go in and go ignore the fact there's a last
00:49:52.760 --> 00:49:53.067 time.
00:49:53.207 --> 00:49:56.483 Time stamp and actually just pass it through to the get by
00:49:56.483 --> 00:49:59.316 ID's call. So if I put breakpoints in here I can't
00:49:59.316 --> 00:50:02.981 really do that very well because of the Lambda expressions I have
00:50:02.981 --> 00:50:06.479 to step through to get to them. We would do that stuff but our
00:50:06.479 --> 00:50:09.978 request as a total is basically the serialization of all these
00:50:09.978 --> 00:50:13.421 properties and values together and it turns that into an earn
00:50:13.421 --> 00:50:17.086 which would then go store inside Redis as the key for the readus.
00:50:17.086 --> 00:50:20.307 So I'm gonna step through this. We'll see how that looks.
00:50:21.177 --> 00:50:25.194 I'll F-11 in which will send me into the UI useless modified
00:50:25.194 --> 00:50:25.787 function.
00:50:27.467 --> 00:50:30.402 And in here you see there's a bunch of arguments that don't
00:50:30.402 --> 00:50:33.239 necessarily always pass, like one of them is the no cache
00:50:33.239 --> 00:50:36.174 argument, varying it by rules or age, or, you know, turning
00:50:36.174 --> 00:50:39.255 compression on and off, stuff like that that we could pass in.
00:50:39.255 --> 00:50:40.087 It will then run.
00:50:40.757 --> 00:50:41.407 E.
00:50:42.837 --> 00:50:44.177 Operation cancelled exception.
00:50:44.897 --> 00:50:47.017 Yeah, that's all in the indexer. I don't care about that.
00:50:48.017 --> 00:50:48.397 Go away.
00:50:50.207 --> 00:50:51.881 Uh, so I'm attached the scheduler. That's why that
00:50:51.881 --> 00:50:52.177 happened.
00:50:54.287 --> 00:50:56.970 Search catalog with writer Ohh stopped in here again. I'm
00:50:56.970 --> 00:50:59.792 betting someone else is also hitting the site so it hit that
00:50:59.792 --> 00:51:02.521 too, so I'm gonna take this breakpoint off and just let it
00:51:02.521 --> 00:51:02.937 continue.
00:51:04.797 --> 00:51:06.847 I could stay with just the part that I care about.
00:51:09.137 --> 00:51:10.407 Uh. Subs.
00:51:13.717 --> 00:51:14.097 No.
00:51:19.317 --> 00:51:22.148 Unfortunately, the only way to detach is to stop and detach to
00:51:22.148 --> 00:51:22.687 all of them.
00:51:23.367 --> 00:51:25.787 Umm, I can't detach one thing specifically.
00:51:29.807 --> 00:51:31.708 At least that I'm aware of. Maybe I've added that feature,
00:51:31.708 --> 00:51:31.837 but.
00:51:40.127 --> 00:51:42.494 So James, if I was on the front end and I was browsing the site
00:51:42.494 --> 00:51:44.602 and I wanted to attach to a specific endpoint that I see
00:51:44.602 --> 00:51:45.157 getting called.
00:51:46.927 --> 00:51:47.997 Would that process look like?
00:51:49.417 --> 00:51:52.190 So generally speaking, what's gonna happen is you have to load
00:51:52.190 --> 00:51:54.832 the page once in order to see stuff. If you've got your one
00:51:54.832 --> 00:51:57.517 failing call here like this list call. If this was, this was
00:51:57.517 --> 00:52:00.159 actually like what I was trying to deal with, then what you
00:52:00.159 --> 00:52:02.712 would do is you would right click that one and say replay
00:52:02.712 --> 00:52:05.354 XHR and then the only that one call gets hit. And so if you
00:52:05.354 --> 00:52:08.171 have your break point and there will only do that one thing you
00:52:08.171 --> 00:52:10.901 have to worry about any of those stuff like coming through or
00:52:10.901 --> 00:52:11.737 trying to activate.
00:52:12.907 --> 00:52:14.747 My my ID's came back.
00:52:15.597 --> 00:52:16.247 Trying to.
00:52:18.627 --> 00:52:19.097 Something.
00:52:20.867 --> 00:52:23.217 Part of this is that it's operating so slowly, I can't.
00:52:24.997 --> 00:52:27.146 Keep it going and that might be partially because I'm attached
00:52:27.146 --> 00:52:27.897 to two things at once.
00:52:30.177 --> 00:52:32.350 I think what I want to do is go ahead and detach that I don't
00:52:32.350 --> 00:52:33.297 get anymore scheduler hits.
00:52:34.667 --> 00:52:36.147 Simplify this process a little bit.
00:52:39.797 --> 00:52:41.297 Is this response I'm going to detach?
00:52:43.367 --> 00:52:47.676 That means that the page was now let go and can able is able to
00:52:47.676 --> 00:52:51.648 reply with its results. I'm going to reattach, but only to
00:52:51.648 --> 00:52:52.927 the API storefront.
00:52:53.677 --> 00:52:54.117 You're.
00:52:57.417 --> 00:53:00.143 And it will as long as Visual Studio stays open, it will
00:53:00.143 --> 00:53:03.108 remember this filter when you close and reopen Visual Studio.
00:53:03.108 --> 00:53:06.025 You'll have to retype this and it always resets to sorted by
00:53:06.025 --> 00:53:06.647 process name.
00:53:07.497 --> 00:53:10.144 So just be aware of that. So I wanted to attach to you API
00:53:10.144 --> 00:53:10.637 storefront.
00:53:12.657 --> 00:53:16.812 And then get products by ID's. I had that call. Now I'm gonna ask
00:53:16.812 --> 00:53:18.197 it to replay that XHR.
00:53:18.927 --> 00:53:21.337 And what I should see is it coming back.
00:53:22.657 --> 00:53:23.657 In in the list.
00:53:26.427 --> 00:53:26.927 Umm.
00:53:27.617 --> 00:53:30.508 But then go in and and stop on in here. It's currently
00:53:30.508 --> 00:53:31.927 responding, so that's good.
00:53:32.867 --> 00:53:33.877 Don't see it.
00:53:36.557 --> 00:53:37.477 All where is it?
00:53:39.037 --> 00:53:39.527 By.
00:53:40.987 --> 00:53:44.272 Errors the second one. OK, so the first one replied and it
00:53:44.272 --> 00:53:47.669 gave it data in that data that it replied with the response.
00:53:47.669 --> 00:53:51.066 One of the headers is gonna be the elevated this over. So we
00:53:51.066 --> 00:53:51.957 have room on it.
00:53:53.757 --> 00:53:58.115 It's going to be the hash control Max age of 60, so that's
00:53:58.115 --> 00:53:58.927 60 minutes.
00:53:59.687 --> 00:54:03.339 I believe UM and then the date stamp and the last modified
00:54:03.339 --> 00:54:07.176 stamp are important. The last modified, there's the timestamp
00:54:07.176 --> 00:54:11.138 for that data that you used and now when it asks the server for
00:54:11.138 --> 00:54:14.666 the request again, on the subsequent request, it's gonna
00:54:14.666 --> 00:54:17.327 pass in that same timestamp on my request.
00:54:18.407 --> 00:54:19.817 If modified since.
00:54:20.897 --> 00:54:24.264 That, if modified since has that stamp and then the server goes
00:54:24.264 --> 00:54:27.526 up. Yep, that matches what I've got, and so you can keep what
00:54:27.526 --> 00:54:30.525 you have. And so the reply becomes 304. It does not send
00:54:30.525 --> 00:54:33.471 any actual body on its actual response, but the browser
00:54:33.471 --> 00:54:36.575 automatically marries it to the original data that it had,
00:54:36.575 --> 00:54:39.784 whether it was inside this page runner or whatever. It's got
00:54:39.784 --> 00:54:43.256 that data in its memory cache or inside of its physical cache for
00:54:43.256 --> 00:54:46.413 the browser and loads that data back up. And so the request
00:54:46.413 --> 00:54:49.832 response time drops from however long it would normally have run
00:54:49.832 --> 00:54:50.937 like this, obviously.
00:54:51.027 --> 00:54:53.671 Brent minutes. Because I was attached in messing with stuff.
00:54:53.671 --> 00:54:56.402 If that had been a one second response time, the three or four
00:54:56.402 --> 00:54:58.960 would have been a couple of milliseconds response time. It
00:54:58.960 --> 00:55:00.347 just had to load from his local.
00:55:01.767 --> 00:55:04.932 On top of the maybe 5050 millisecond round trip to ask
00:55:04.932 --> 00:55:07.925 him about the date. So we're saving all that server
00:55:07.925 --> 00:55:10.975 processing time now to get around that there are two
00:55:10.975 --> 00:55:14.543 things. One, you wait out the cache so 60 minutes and wait 60
00:55:14.543 --> 00:55:18.169 minutes. What it would do is it would ask the server again and
00:55:18.169 --> 00:55:21.967 actually give it back there. I'm sorry I messed this up a little.
00:55:23.107 --> 00:55:26.724 If you got a response 304, you're inside the cache window.
00:55:26.724 --> 00:55:30.463 The the Max age of 60 minutes. It didn't even ask the server
00:55:30.463 --> 00:55:32.547 for more info, it just loaded it.
00:55:33.397 --> 00:55:37.946 I'm if you're beyond the Max age, it will ask the server. The
00:55:37.946 --> 00:55:39.267 server will reply.
00:55:39.707 --> 00:55:42.825 Umm if if the date matches and if the deep matches then it then
00:55:42.825 --> 00:55:45.893 it then it will tell you to load the existing cache value data
00:55:45.893 --> 00:55:48.768 and not go to the additional processing of actually asking
00:55:48.768 --> 00:55:51.885 the database. For more info the workflow process to process all
00:55:51.885 --> 00:55:54.954 the data whatever is gonna do and press us back. So we sitting
00:55:54.954 --> 00:55:55.977 that processing time.
00:55:56.637 --> 00:56:00.767 And then the third level is if the date no longer matches then.
00:56:01.007 --> 00:56:04.166 I it will go through the process of saying ohh you're out of
00:56:04.166 --> 00:56:07.481 date. Let me give you more info and it will reply with the full
00:56:07.481 --> 00:56:10.589 response like it would have originally. So that's the three
00:56:10.589 --> 00:56:13.697 types of caching to forcibly to ignore the 304 you could do
00:56:13.697 --> 00:56:16.856 disable cache or you could do empty cache and hard reload on
00:56:16.856 --> 00:56:17.167 stuff.
00:56:17.967 --> 00:56:21.392 Hard reload usually gets it, but it's better to just do empty
00:56:21.392 --> 00:56:22.497 cache on that stuff.
00:56:23.257 --> 00:56:25.587 So if I say disable cache and replay XHR.
00:56:26.627 --> 00:56:29.723 It see how I hit the server this time even though I inside the
00:56:29.723 --> 00:56:32.770 Max age. This means I will not get a 304 response and ask for
00:56:32.770 --> 00:56:32.917 it.
00:56:33.687 --> 00:56:36.735 I believe it will also skip the last modified check in here
00:56:36.735 --> 00:56:39.427 because of the disabled cache. So if I step in here.
00:56:40.367 --> 00:56:43.668 I'm inside this function. It's passing in the function call as
00:56:43.668 --> 00:56:46.863 an expression that say to get the last modified date and the
00:56:46.863 --> 00:56:50.059 factory. So I'm gonna go step into my last modified function
00:56:50.059 --> 00:56:53.307 and you see how I'm back right back here. It's gonna go to my
00:56:53.307 --> 00:56:56.503 products dot git last modified for IDs by result async. It's
00:56:56.503 --> 00:56:59.856 passing in the brand the store the IDs that were on request. Is
00:56:59.856 --> 00:57:02.528 this vendor in have been stopping what the context
00:57:02.528 --> 00:57:05.357 profile name was, which in production is always null.
00:57:06.377 --> 00:57:09.800 So I step into there it goes and goes, hits my workflows, it asks
00:57:09.800 --> 00:57:12.705 for the workflows controller stepping again. There's my
00:57:12.705 --> 00:57:13.587 product workflow.
00:57:14.247 --> 00:57:17.874 Stepping again and I get my ice property call. I step in again
00:57:17.874 --> 00:57:21.328 and you kind of have to step through this a few times until
00:57:21.328 --> 00:57:22.307 we get past that.
00:57:23.467 --> 00:57:24.827 If I'm just doing straight steps.
00:57:27.237 --> 00:57:29.697 And her admin flag vendor admin flag.
00:57:31.537 --> 00:57:34.175 Go into it now. Now I'm actually on my function now. I could have
00:57:34.175 --> 00:57:36.693 instead of trying to do step in and having to do this stuff as
00:57:36.693 --> 00:57:39.290 variables if I knew it function I was calling, I could just come
00:57:39.290 --> 00:57:41.808 here and put a break point and hit F5 and continue to it. That
00:57:41.808 --> 00:57:43.047 would have been perfectly fine.
00:57:43.597 --> 00:57:47.061 Umm. And this function is very simple, so all it's doing is
00:57:47.061 --> 00:57:50.641 literally going in passing in those ads and then grabbing the
00:57:50.641 --> 00:57:54.452 updated date. Localizing that to the created date and then giving
00:57:54.452 --> 00:57:55.087 me the 1st.
00:57:56.397 --> 00:57:57.357 Unfortunately.
00:58:00.217 --> 00:58:01.157 This is not.
00:58:02.317 --> 00:58:03.317 There is a bug here.
00:58:03.827 --> 00:58:04.757 Yeah, this is gonna say.
00:58:03.987 --> 00:58:05.307 We need to be ordering.
00:58:06.217 --> 00:58:06.787 Order.
00:58:07.687 --> 00:58:08.277 By.
00:58:10.977 --> 00:58:14.406 AX because we selected that and then we want the. Actually I
00:58:14.406 --> 00:58:17.667 don't need to order by, I can just do the column command.
00:58:18.477 --> 00:58:19.337 Or Max Evan rather.
00:58:20.907 --> 00:58:21.647 The Max command.
00:58:22.677 --> 00:58:24.637 Think of dates, so whoops.
00:58:25.807 --> 00:58:29.116 Here's my there we go so I could take give me the maximum value,
00:58:29.116 --> 00:58:32.170 not the first that was. That's actually a bug in core right
00:58:32.170 --> 00:58:35.428 there and then anyone else who's doing that same thing. We need
00:58:35.428 --> 00:58:38.533 to make sure that we go fix those so that they're doing that
00:58:38.533 --> 00:58:41.434 correctly. But basically the idea is, yeah, all of those
00:58:41.434 --> 00:58:43.267 products who's got the latest date.
00:58:44.187 --> 00:58:47.064 And then I that's becomes become my value. Now I have to save
00:58:47.064 --> 00:58:50.034 this and screw with it. So I'm not gonna save it at the moment,
00:58:50.034 --> 00:58:53.097 but I now that I now know that I have a bug that I have fixed and
00:58:53.097 --> 00:58:56.067 that I need to step back out. So what I'm gonna do is step out.
00:58:56.757 --> 00:58:59.403 Hope that it will let me keep it. Nope, it's tries to wants to
00:58:59.403 --> 00:59:00.537 try and apply code updates.
00:59:01.427 --> 00:59:02.977 So I have to cancel that.
00:59:03.937 --> 00:59:06.618 And then we're gonna let it continue as is. It reached to
00:59:06.618 --> 00:59:09.391 see if there was a no cache value. There was not a no cache
00:59:09.391 --> 00:59:12.257 value. A no cache is an actual property to send. It's not the
00:59:12.257 --> 00:59:12.997 header argument.
00:59:14.167 --> 00:59:17.865 I stepped through that is the API kind the storefront? Yes or
00:59:17.865 --> 00:59:21.623 no? If it's not the storefront, meaning that it's the API API,
00:59:21.623 --> 00:59:24.725 Admin API, brand admin, whatever, none of those are
00:59:24.725 --> 00:59:26.097 allowed to do 30 fours.
00:59:27.067 --> 00:59:30.724 And because they are not allowed to do 304 days, we return not
00:59:30.724 --> 00:59:31.247 modified.
00:59:31.767 --> 00:59:35.521 UM on here. We're we're not allowed to do the the not
00:59:35.521 --> 00:59:37.537 modified reply, which is the.
00:59:39.197 --> 00:59:40.537 What's it called? I can't remember the.
00:59:41.467 --> 00:59:42.657 I think it's 204.
00:59:43.527 --> 00:59:44.277 Is the.
00:59:45.597 --> 00:59:46.687 Is the status code.
00:59:48.937 --> 00:59:49.457 It's.
00:59:51.877 --> 00:59:52.217 Here.
00:59:53.587 --> 00:59:55.327 I I think it's 204 I.
00:59:53.727 --> 00:59:55.157 204 is no content.
00:59:56.467 --> 00:59:58.487 UH-2 first content. So then what's what's the?
00:59:56.777 --> 00:59:57.137 You.
01:00:00.947 --> 01:00:03.737 Keep your like no content changed one.
01:00:05.517 --> 01:00:06.247 Three or four.
01:00:07.207 --> 01:00:09.077 3040 it is OK.
01:00:10.897 --> 01:00:11.437 Umm.
01:00:16.967 --> 01:00:20.186 200 always like good responses. 3 hundreds are redirecting. So
01:00:20.186 --> 01:00:23.302 in this case it's like you're redirecting to the old content
01:00:23.302 --> 01:00:25.397 because it's how I would think about it.
01:00:24.777 --> 01:00:25.777 Yeah, yeah, yeah, yeah.
01:00:28.677 --> 01:00:29.437 OK. Yeah.
01:00:30.717 --> 01:00:33.990 Umm, so there's that. OK, so we have that. When Anna did that
01:00:33.990 --> 01:00:34.307 thing.
01:00:34.987 --> 01:00:35.517 Umm.
01:00:37.067 --> 01:00:39.097 Then if the data.
01:00:39.987 --> 01:00:41.987 Is where are we right now? I mean my call.
01:00:43.867 --> 01:00:47.138 All stacks right here, so I'm in here and it does the thing. And
01:00:47.138 --> 01:00:50.458 then so I continue now because I did the the no cache, it's gonna
01:00:50.458 --> 01:00:51.817 skip that because with the.
01:00:52.467 --> 01:00:57.417 The stuff in there and then if they're, you know, always very
01:00:57.417 --> 01:00:57.657 by.
01:00:58.287 --> 01:01:00.767 Was very that should be a RY. There's a typo.
01:01:01.517 --> 01:01:02.007 Umm.
01:01:02.797 --> 01:01:05.977 Then it does create and cache results, so the factory function
01:01:05.977 --> 01:01:09.006 for actually generating the results it gets passed in there
01:01:09.006 --> 01:01:12.236 as the expression and it passes in these other arguments, which
01:01:12.236 --> 01:01:15.164 may have been set by something or another, and it has the
01:01:15.164 --> 01:01:18.294 request itself. So if I step in there I get my thing here. If
01:01:18.294 --> 01:01:21.524 the API is doesn't have, if it has the node cache or it's not a
01:01:21.524 --> 01:01:24.806 storefront, then all it does is it just passes up in, it doesn't
01:01:24.806 --> 01:01:26.017 start to cache anything.
01:01:26.897 --> 01:01:29.847 Umm. If that's not the case, it's skips that block.
01:01:31.147 --> 01:01:34.210 It comes in here and it's it knows that it's a lot to create
01:01:34.210 --> 01:01:37.374 a cache key and do the optimized result. So what it's gonna do
01:01:37.374 --> 01:01:40.487 here is it's gonna build a key that's gonna pass it to Reedus
01:01:40.487 --> 01:01:43.550 so that it can look up that value and read it in the future,
01:01:43.550 --> 01:01:46.663 and it has the cache timeout time span, which in this case is
01:01:46.663 --> 01:01:49.827 2 minutes. That's a very fast cache expiration, which is going
01:01:49.827 --> 01:01:53.040 to harm the impact or harm the speed of the site, but it's more
01:01:53.040 --> 01:01:56.053 useful for debugging inside the stuff. So in production you
01:01:56.053 --> 01:01:58.765 absolutely do not want two-minute cache, you want a 2
01:01:58.765 --> 01:01:59.317 hour cache.
01:02:01.457 --> 01:02:04.777 Or something longer, depending on how often the data actually
01:02:04.777 --> 01:02:07.990 needs to be requested and and redone. So it's gonna pass in
01:02:07.990 --> 01:02:11.363 the ASP net request it's gonna pass in the body of the our get
01:02:11.363 --> 01:02:14.737 products by ID's request. It's got the local, it doesn't use a
01:02:14.737 --> 01:02:18.111 local cache. What's the Max age? All that data that's going to
01:02:18.111 --> 01:02:21.645 get passed in or it's gonna fall back to defaults by creating and
01:02:21.645 --> 01:02:24.483 just straight up earn ID and then create and run the
01:02:24.483 --> 01:02:28.017 optimized result for that stuff. So I'll step into the build key.
01:02:28.717 --> 01:02:29.587 Prepared to step back out.
01:02:30.597 --> 01:02:31.297 Step in.
01:02:32.677 --> 01:02:35.959 It does. If it's not like at the verb, is not a git or or a head,
01:02:35.959 --> 01:02:39.042 it's not allowed to do this. It's so it has to just return it
01:02:39.042 --> 01:02:42.125 reply with other stuff. You can only do that with browsers on
01:02:42.125 --> 01:02:45.009 Git requests and head requests. If I don't have a caching
01:02:45.009 --> 01:02:48.091 feature, I throw an exception because I'm supposed to have my
01:02:48.091 --> 01:02:48.887 caching feature.
01:02:50.307 --> 01:02:53.553 I make a string builder and on my builder I add modifier to all
01:02:53.553 --> 01:02:56.748 this stuff so my user session part of it my roles, my headers,
01:02:56.748 --> 01:02:59.893 my parameters, all that stuff gets enabled if there's a brand
01:02:59.893 --> 01:03:02.986 that it does another piece for the brand in there so that it
01:03:02.986 --> 01:03:05.979 can isolate out the cache key for the brand, which for our
01:03:05.979 --> 01:03:08.870 isn't entirely applicable because they have the websites
01:03:08.870 --> 01:03:11.913 and if I look at my modifiers here you can see I've added a
01:03:11.913 --> 01:03:13.637 ton of crap to my string builder.
01:03:15.257 --> 01:03:18.802 And then I add my MIME type for my application JSON and then at
01:03:18.802 --> 01:03:22.236 this point now I have I generate a cache info object which is
01:03:22.236 --> 01:03:25.559 part of what it's gonna store inside the thing and that key
01:03:25.559 --> 01:03:28.993 that it generates off of that because it's gonna use all this
01:03:28.993 --> 01:03:32.538 information is gonna tell it how to create that info. So if I'm
01:03:32.538 --> 01:03:35.307 also the key now my earn is this crazy *** thing.
01:03:37.077 --> 01:03:40.699 So this is basically the the array of IDs all the way through
01:03:40.699 --> 01:03:44.205 to there and then my referral URL and then my JSON that I'm
01:03:44.205 --> 01:03:47.827 attempting to reply with JSON. The colons are the separations
01:03:47.827 --> 01:03:51.566 of. Think of them as directory separators if you will, versus A
01:03:51.566 --> 01:03:55.130 slash. And so I have my request type. I have like body of my
01:03:55.130 --> 01:03:58.227 request and then I have other info about my request.
01:03:59.187 --> 01:04:01.829 Up to here and then the fact that this is supposed to be
01:04:01.829 --> 01:04:04.703 containing JSON right here and that it's an earned key at the
01:04:04.703 --> 01:04:05.167 beginning.
01:04:05.757 --> 01:04:08.320 So that's what's to generate as far as a key goes for saving it
01:04:08.320 --> 01:04:10.764 into ritus, but I would be able to go look that up inside by
01:04:10.764 --> 01:04:13.287 Redis cache once the saves, so it's gonna take that cache key.
01:04:14.127 --> 01:04:17.212 And if it did generate anything there, and it all coalesced,
01:04:17.212 --> 01:04:20.348 then it generate a generic one right here and slap some stuff
01:04:20.348 --> 01:04:21.157 in there for it.
01:04:22.147 --> 01:04:25.151 Why am I catching time at times fan my factory functions go
01:04:25.151 --> 01:04:28.355 physically do it. So now that I have a key I'm gonna it's gonna
01:04:28.355 --> 01:04:31.459 pass it into here and go. Hey, give me my thing that tells it
01:04:31.459 --> 01:04:34.513 to go actually make my resolve go cache or resolve the thing
01:04:34.513 --> 01:04:37.617 there. It's gonna resolve from cache and go. Oh, I don't need
01:04:37.617 --> 01:04:40.921 to do that. So here's my factory function which goes into the Git
01:04:40.921 --> 01:04:43.975 Boyds I step in and out a few times to go do that stuff. But
01:04:43.975 --> 01:04:47.080 instead I'm going to go control F-12 over to the function I'm
01:04:47.080 --> 01:04:50.184 going to put my break point in I'm going five over to it so I
01:04:50.184 --> 01:04:52.787 don't have to go through those variable pull steps.
01:04:53.427 --> 01:04:55.888 I'll new up a context. I'll clean the Alex so that they
01:04:55.888 --> 01:04:58.436 don't have bad data on them. There's a couple of clean up
01:04:58.436 --> 01:05:01.072 rules in there, like fixing inventory and other stuff data,
01:05:01.072 --> 01:05:03.885 and then I'll loop through them and I'll go map the product for
01:05:03.885 --> 01:05:06.477 the store front for each product and add it to my results.
01:05:07.497 --> 01:05:10.668 So all 5 past that and to get my product results I have my 9
01:05:10.668 --> 01:05:13.890 products, they are fully pulled out and ready to go. For what
01:05:13.890 --> 01:05:16.437 the store front wants. Then I will step through.
01:05:17.817 --> 01:05:18.647 Pulling it back.
01:05:20.727 --> 01:05:22.567 And so the F-10 from right there.
01:05:22.117 --> 01:05:22.547 Umm.
01:05:23.557 --> 01:05:26.973 Good. Put me back in. Maybe not. Or one of these other spots. I
01:05:26.973 --> 01:05:28.307 don't know exactly where.
01:05:30.047 --> 01:05:32.716 Oh, it just went back all the way through and replied with the
01:05:32.716 --> 01:05:35.428 reply. So now I have my payload that gave me all that stuff and
01:05:35.428 --> 01:05:37.970 I could go through and I could see where stuff is look for.
01:05:37.970 --> 01:05:40.598 That's the entire request of everything that was going to do.
01:05:40.598 --> 01:05:43.182 I could have stepped into the MAP product for storefront and
01:05:43.182 --> 01:05:45.640 looked at like the mapping itself and seeing if there was
01:05:45.640 --> 01:05:48.267 like a mapping problem or there was like a null references up
01:05:48.267 --> 01:05:50.809 something in here, whatever I could have gone in and fussed
01:05:50.809 --> 01:05:53.351 around with that kind of stuff and mess with it. But that's
01:05:53.351 --> 01:05:56.021 debugging a full request all the way through that has three or
01:05:56.021 --> 01:05:58.097 four. If it doesn't have 304, it's much simpler.
01:05:59.417 --> 01:06:01.615 It makes it a lot smaller, so like this process product
01:06:01.615 --> 01:06:03.814 notifications. I'm literally just going straight to the
01:06:03.814 --> 01:06:04.167 workflow.
01:06:04.917 --> 01:06:07.825 And hitting it and inside the workflow I can go through and
01:06:07.825 --> 01:06:10.830 debug those pieces and just talk to that part directly. And I
01:06:10.830 --> 01:06:13.834 don't have to do any of that other crap. The three or four is
01:06:13.834 --> 01:06:16.451 add this extra layer of abstraction that kind of does
01:06:16.451 --> 01:06:19.311 extra stuff, but it's there so that we can get our massive
01:06:19.311 --> 01:06:22.122 performances for having the server not have to do near as
01:06:22.122 --> 01:06:25.223 much physical processing either in RAM or CPU by excluding that
01:06:25.223 --> 01:06:28.277 stuff out by adding those dates and dumping that stuff. So all
01:06:28.277 --> 01:06:31.281 that stuff goes in there and does whatever. And like this one
01:06:31.281 --> 01:06:34.141 says, do cache research. But that's from what I originally
01:06:34.141 --> 01:06:37.097 was trying to build the caches. This was totally inaccurate.
01:06:37.177 --> 01:06:38.587 This and I would delete that line.
01:06:39.087 --> 01:06:41.487 Umm, as as it's completely irrelevant to that that function
01:06:41.487 --> 01:06:43.967 call. So I would say that that would close that out. And then
01:06:43.967 --> 01:06:46.527 there's that stuff because that kind of cover a lot of what you
01:06:46.527 --> 01:06:48.927 were looking for. Is there something more specific you want
01:06:48.927 --> 01:06:49.607 me to try and do?
01:06:50.067 --> 01:06:53.431 Yeah, that's great. So for us specifically for connect, we do
01:06:53.431 --> 01:06:56.633 a lot of creating things, updating things when we get like
01:06:56.633 --> 01:06:59.617 state keys that are wrong or type keys that are wrong.
01:07:01.907 --> 01:07:04.969 Where do we go to attach and look for those? And so we're
01:07:04.969 --> 01:07:06.817 trying to create a customer, yeah.
01:07:05.487 --> 01:07:09.038 OK. So yeah, so like we're gonna create a an account record. I'll
01:07:09.038 --> 01:07:12.428 go to the account service that is in the T4 first. The T4 here
01:07:12.428 --> 01:07:15.333 has services that accounts that account, which is the
01:07:15.333 --> 01:07:18.561 referencing the account table you have the inside this file
01:07:18.561 --> 01:07:22.059 you have the create function. So like the create account we also
01:07:22.059 --> 01:07:25.556 have upsert and we have update. So depending on which one you're
01:07:25.556 --> 01:07:28.946 going to do what will slightly drive which one you're going to
01:07:28.946 --> 01:07:31.367 do all stick with create. So we have create.
01:07:30.467 --> 01:07:33.160 And in this services TTS these have all of the endpoints so we
01:07:33.160 --> 01:07:34.357 can hit for connect correct?
01:07:35.557 --> 01:07:37.367 Yes, I mean.
01:07:37.017 --> 01:07:37.227 Cool.
01:07:38.897 --> 01:07:41.419 When you're in connect and you're talking to the main API,
01:07:41.419 --> 01:07:44.069 it has loaded every endpoint. There is no restriction whether
01:07:44.069 --> 01:07:46.591 they're inside the providers, they're inside your override
01:07:44.177 --> 01:07:44.427 Yep.
01:07:46.591 --> 01:07:48.857 project. They are all loaded and you are all access.
01:07:50.367 --> 01:07:50.677 Cool.
01:07:51.287 --> 01:07:53.306 All the time inside that when the main one, that's the
01:07:53.306 --> 01:07:55.618 difference with this one with that one and that's why that one
01:07:55.618 --> 01:07:57.930 takes like a minute and a half, two minutes to load versus the
01:07:57.930 --> 01:08:00.206 storefront which can load in like 15 seconds. It's because of
01:08:00.206 --> 01:08:02.335 all the extra reflection and everything it's doing inside
01:08:02.335 --> 01:08:04.317 service desk to load all those endpoints into memory.
01:08:04.937 --> 01:08:07.545 And there's and then there's, like, your get accounts for
01:08:07.545 --> 01:08:10.199 connect, which is your search for connect call like that's
01:08:10.199 --> 01:08:13.122 your main one to go look up and grab accounts from connect after
01:08:13.122 --> 01:08:15.730 the digest you've got your digest, you've got your search
01:08:15.730 --> 01:08:18.383 for connect. The digest gives you your ID key and the hash
01:08:18.383 --> 01:08:21.127 value so that you can do your hash lookups to just to verify
01:08:21.127 --> 01:08:23.960 stuff done without having to do the extra data of all the info
01:08:23.960 --> 01:08:26.748 about the account. You could just do the hash and just assume
01:08:26.748 --> 01:08:28.187 that it's correct if the hashes.
01:08:28.877 --> 01:08:31.864 Umm get accounts for connect is the request. That's also it
01:08:31.864 --> 01:08:34.602 should be pageable and stuff inside there, but I can't
01:08:34.602 --> 01:08:37.738 remember if they if that's on that version we're gonna do that
01:08:37.738 --> 01:08:41.023 on a newer one and then ignoring that one because that's not part
01:08:41.023 --> 01:08:44.309 of what we're going to do. We go to the create update. Here's the
01:08:44.309 --> 01:08:47.544 create guy so we've got upsert, create and update going to go to
01:08:47.544 --> 01:08:50.680 my create function now part of what it does is it says to when
01:08:50.680 --> 01:08:53.767 something gets updated it should be clearing the cache of any
01:08:53.767 --> 01:08:56.554 account data in Redis so that they can go appropriately
01:08:56.554 --> 01:08:58.247 automatically refresh themselves.
01:08:58.787 --> 01:09:01.983 Our next call meaning that the clash is known to be dead or
01:09:01.983 --> 01:09:05.391 expired or invalid. Whatever you wanna call it and so it should
01:09:05.391 --> 01:09:08.693 be going in and actually running that call to go clear it and
01:09:08.693 --> 01:09:12.102 then call the create same thing for update. It's gonna do that.
01:09:12.102 --> 01:09:15.404 So you might be stepping past that function to get into where
01:09:15.404 --> 01:09:17.907 the actual create is. I would do control F-12.
01:09:19.397 --> 01:09:22.896 And what should happen is you'll see some kind of implementation
01:09:22.896 --> 01:09:26.179 option here, where some of the workflows override the create
01:09:26.179 --> 01:09:29.731 function, and if they do, you'll see that one's workflow in here.
01:09:29.731 --> 01:09:32.907 So you would double click it if this was a user event or a
01:09:32.907 --> 01:09:36.298 message or whatever. I would go to my extended one and look at
01:09:36.298 --> 01:09:39.635 the overridden version of it, and that's where I put my break
01:09:39.635 --> 01:09:43.080 point. Most things are gonna be in the workflow base, so you're
01:09:43.080 --> 01:09:46.310 just going to come in here and put your breakpoint here and
01:09:46.310 --> 01:09:48.947 then you'll step in. So once it steps into here.
01:09:49.337 --> 01:09:51.891 They'll go through. It'll new up a context for it and it will
01:09:51.891 --> 01:09:54.486 pass itself over to this other instance of the endpoint, where
01:09:54.486 --> 01:09:56.999 if you already have a context, you could just pass it and in
01:09:56.999 --> 01:09:59.471 this case we're doing it and we're gonna pass it in through
01:09:59.471 --> 01:09:59.677 here.
01:10:01.157 --> 01:10:04.043 So I got my create async here and that stuff now because the
01:10:04.043 --> 01:10:07.023 endpoint might might have been overridden in that part, I will
01:10:07.023 --> 01:10:09.767 come look over here in the account service that's outside
01:10:09.767 --> 01:10:12.794 the T4 just to double check that I didn't overwrite it in here.
01:10:12.794 --> 01:10:15.585 And in this case I did not. So I don't have anything extra
01:10:15.585 --> 01:10:18.424 special due to the here and I can close this file. It's not
01:10:18.424 --> 01:10:21.451 doing anything extra for me. So the basic process for create is
01:10:21.451 --> 01:10:21.877 gonna be.
01:10:22.497 --> 01:10:24.863 Did you put a valid ID on it? Well, you can't do that with a
01:10:24.863 --> 01:10:27.344 create because that would mean that already existed. That's not
01:10:27.344 --> 01:10:29.167 good. And so we throw an exception if you did.
01:10:30.737 --> 01:10:34.104 If this table is designed to allow duplicate, could custom
01:10:34.104 --> 01:10:37.586 keys, then it will skip this check. But if it doesn't, which
01:10:37.586 --> 01:10:41.296 most of them are are not allowed to skip that, it will check for
01:10:41.296 --> 01:10:42.837 duplicate check to say hey.
01:10:43.957 --> 01:10:46.875 You're trying to create a custom or create a record with a custom
01:10:46.875 --> 01:10:49.527 key that already exists, and so it will throw an exception.
01:10:50.467 --> 01:10:53.981 If you get past those first initialization validation stuff,
01:10:53.981 --> 01:10:57.553 it goes into this create entity without saving part, which is
01:10:57.553 --> 01:11:01.356 basically just just just mock or building up our model that we're
01:11:01.356 --> 01:11:04.812 gonna of the database entity record class in memory so that
01:11:04.812 --> 01:11:08.500 it maps all of that stuff in for it. So when I go to the create
01:11:08.500 --> 01:11:09.767 entity without saving.
01:11:11.387 --> 01:11:13.332 I can see that it's been overridden in the product price
01:11:13.332 --> 01:11:15.447 point workflow, but everybody else is doing it just the base.
01:11:16.837 --> 01:11:19.754 So I come into here and it does the basics of the of the model
01:11:19.754 --> 01:11:22.440 it creates. It creates an instance of the entity and that
01:11:22.440 --> 01:11:25.218 it is tied to that database record that's important for the
01:11:25.218 --> 01:11:26.607 tests, but not for production.
01:11:28.237 --> 01:11:31.393 It does the basic you know, flat properties of it active, create
01:11:31.393 --> 01:11:34.258 custom key hash and Jason attributes and then it calls the
01:11:34.258 --> 01:11:37.220 assigned additional properties async part which is where the
01:11:37.220 --> 01:11:40.085 more specific stuff starts happening depending on what the
01:11:40.085 --> 01:11:43.241 data visual table is. So if it's a product we're in the account,
01:11:43.241 --> 01:11:46.058 it's gonna do extra stuff in here, so it's gonna call the
01:11:46.058 --> 01:11:49.117 update and inform model which is one of the mapping functions.
01:11:51.157 --> 01:11:54.092 So like that gets overridden all of them, so that's that's a a
01:11:54.092 --> 01:11:57.120 funk which is going to go do the mapping expression stuff, which
01:11:57.120 --> 01:11:58.937 is in the mapping layer. If I go back.
01:11:59.637 --> 01:12:00.267 Umm.
01:12:01.207 --> 01:12:04.307 Then then it will run the relay and associate workflows for it.
01:12:05.597 --> 01:12:06.187 On there.
01:12:07.967 --> 01:12:11.221 This function is very commonly overridden because most tables
01:12:11.221 --> 01:12:14.422 need extra info to do extra things. You can see like account
01:12:14.422 --> 01:12:15.157 crud workflow.
01:12:15.687 --> 01:12:18.681 And sales invoice sales orders, all that stuff. They have more
01:12:18.681 --> 01:12:21.770 complicated stuff to do, so they overwrite it so they can modify
01:12:21.770 --> 01:12:24.479 what it's doing. And in this case, we're overwriting the
01:12:24.479 --> 01:12:27.379 account one. So I'm gonna keep that one open and you can see
01:12:27.177 --> 01:12:30.110 So specific call out here, this is where you would look to see
01:12:27.379 --> 01:12:29.137 this is what we talked about before.
01:12:30.110 --> 01:12:32.857 what happens exactly 4 accounts and what it needs correct.
01:12:33.777 --> 01:12:36.040 Yes, you would go find that function. You'd find the
01:12:34.767 --> 01:12:35.067 Awesome.
01:12:36.040 --> 01:12:38.688 override and then come look at what the override is doing and
01:12:38.688 --> 01:12:41.036 step through this part, especially to do stuff and and
01:12:41.036 --> 01:12:43.598 those things. So if you didn't have a type key or whatever,
01:12:43.598 --> 01:12:46.331 then what would probably happen is it would go into the default
01:12:46.331 --> 01:12:47.057 relate workflows.
01:12:48.217 --> 01:12:51.146 Uh, which we would do a context so they can, it can provide
01:12:51.146 --> 01:12:54.075 additional types separately and save them it case that type
01:12:54.075 --> 01:12:56.857 needs to get saved and it would go relate required type.
01:12:57.967 --> 01:13:01.673 If I didn't provide any type information at all and I didn't
01:13:01.673 --> 01:13:05.439 have that other thing where it said to use the that specified
01:13:05.439 --> 01:13:06.107 override 1.
01:13:07.427 --> 01:13:11.026 Like, let's let's pretend that the the this type key customer.
01:13:11.026 --> 01:13:14.283 Let's pretend this was not here, so we weren't providing
01:13:14.283 --> 01:13:17.825 information when nothing else was provided. This call here is
01:13:17.825 --> 01:13:21.253 the first step that happens. It goes. Do I have any kind of
01:13:21.253 --> 01:13:24.910 valid type information? Either as flattening properties or as a
01:13:24.910 --> 01:13:28.452 model that we passed in type? It has to be somewhere. If it's
01:13:28.452 --> 01:13:31.537 not, then this resolved with Autogenerate will throw.
01:13:32.537 --> 01:13:33.017 Umm.
01:13:34.017 --> 01:13:37.396 If you provided type information that didn't previously exist,
01:13:37.396 --> 01:13:40.721 whether it was a type key, a type name, or on the type model,
01:13:40.721 --> 01:13:44.099 whatever, then what it would do is it would automatically with
01:13:44.099 --> 01:13:47.371 ourselves autogenerate is. It would create that account type
01:13:47.371 --> 01:13:50.803 record in that database and save it over there and allow you to
01:13:50.803 --> 01:13:54.235 then reference the ID to it back over here so that we say we're
01:13:54.235 --> 01:13:55.737 able to reference that info.
01:13:57.237 --> 01:14:00.366 So let's say that we didn't pass anything. We'll go into resolve
01:13:57.777 --> 01:13:58.147 Awesome.
01:14:00.366 --> 01:14:03.447 without a generate, and you'll find out here that it does to do
01:14:03.447 --> 01:14:06.432 resolves and which passes down stuff and it says invalid data
01:14:06.432 --> 01:14:08.887 extension. If it can't generate an instance of it.
01:14:09.587 --> 01:14:10.857 Umm from that stuff.
01:14:11.917 --> 01:14:12.767 And there there is.
01:14:14.167 --> 01:14:18.567 Multiple levels of overwrite overridden function calls here,
01:14:18.567 --> 01:14:23.112 so you have to the displayable basis like types and status and
01:14:23.112 --> 01:14:23.617 states.
01:14:24.747 --> 01:14:28.467 Have a display name. They'll pass it down to the lower layer.
01:14:28.927 --> 01:14:31.990 Umm. Or she's gonna be the same layer 1st and then a lower layer
01:14:31.990 --> 01:14:34.864 where the name will base where it allows it by name and then
01:14:34.864 --> 01:14:37.597 the name will pass it into itself and then into the lower
01:14:37.597 --> 01:14:40.283 layer where it's the lowest layer of resolve async where
01:14:40.283 --> 01:14:43.346 it's allowed to do it by key and so it kind of basically just as
01:14:43.346 --> 01:14:45.985 an order of operation where the most important piece of
01:14:45.985 --> 01:14:47.587 information is if you have an ID.
01:14:48.317 --> 01:14:51.334 Or you and then followed by a custom key followed by a name
01:14:51.334 --> 01:14:54.300 followed by a display name able to use them in that order.
01:14:54.300 --> 01:14:57.066 Trying to look up an existing record. If it can't find
01:14:57.066 --> 01:15:00.234 anything after all of that, and there's no way to put, there's
01:15:00.234 --> 01:15:03.502 no data to physically look up by then it will throw an exception
01:15:03.502 --> 01:15:06.619 saying. I don't know what to do. You were supposed to send me
01:15:06.619 --> 01:15:07.977 info. What you did was bad.
01:15:09.377 --> 01:15:11.217 And then call the tell the request the Dina fire.
01:15:12.717 --> 01:15:15.556 And unless you have a try catch then it's gonna bubble that
01:15:15.556 --> 01:15:18.396 exception all the way back over the wire to connect on that
01:15:18.396 --> 01:15:21.330 stuff. So. So, yeah, if you're gonna die, you're gonna die in
01:15:21.330 --> 01:15:24.217 here in one of these things. And that's what's gonna happen.
01:15:26.437 --> 01:15:28.347 The newest version of Seth.
01:15:29.317 --> 01:15:32.597 Because of the new attributes and everything that are going on
01:15:32.597 --> 01:15:35.929 those models, it is now gonna be a little bit smarter about the
01:15:35.929 --> 01:15:39.001 fact that you can't serialize the request correctly and it
01:15:39.001 --> 01:15:42.281 will stop you sooner. So what would probably happen is some of
01:15:42.281 --> 01:15:45.353 those requests if you don't provide certain data points is
01:15:45.353 --> 01:15:48.321 just hitting the endpoint itself. You won't even be able
01:15:48.321 --> 01:15:51.601 to debug into CEF because Jeff service decks layer is going to
01:15:51.601 --> 01:15:54.725 outright rejects the response the request, and then it will
01:15:54.725 --> 01:15:58.057 tell you our particular property ID or whatever was missing and
01:15:58.057 --> 01:15:59.567 what you were trying to send.
01:15:58.677 --> 01:15:59.127 Ah.
01:15:59.877 --> 01:16:02.117 And you have to fill that data in before sending it.
01:16:02.577 --> 01:16:04.857 So much better is that, uh, what version of stuff is that?
01:16:05.637 --> 01:16:06.777 The the the.
01:16:07.597 --> 01:16:10.877 2022.4 should do it the the what's in developed right now,
01:16:10.877 --> 01:16:14.435 which means it's gonna go to the next release, is gonna be even
01:16:14.435 --> 01:16:15.547 stronger about that.
01:16:15.877 --> 01:16:19.050 That's awesome. I think we've all seen the uh unable to auto
01:16:17.197 --> 01:16:18.547 What I suggest you do.
01:16:19.050 --> 01:16:20.507 generate with no other help.
01:16:19.987 --> 01:16:23.181 Yeah, absolutely. It's one of the biggest things that will
01:16:23.181 --> 01:16:26.375 happen is you'll forget to put that piece in or it did get
01:16:24.587 --> 01:16:24.887 Yep.
01:16:26.375 --> 01:16:29.894 passed in correctly or whatever. And so it lost it and it has to
01:16:29.894 --> 01:16:33.466 go back and deal with that. What I suggest you do for performance
01:16:33.466 --> 01:16:36.985 purposes of connect is if you're having to deal with a type like
01:16:36.985 --> 01:16:40.341 that, don't try passing a key. Ask the server for the list of
01:16:40.341 --> 01:16:43.698 types for the pullback. You can pull them back on a digest of
01:16:43.698 --> 01:16:47.054 those types, which will provide the ID and the custom key for
01:16:47.054 --> 01:16:50.248 each of those things. They won't have a hat on. It doesn't
01:16:50.248 --> 01:16:50.627 matter.
01:16:51.227 --> 01:16:54.433 But you'll have those key value pairs for to look up, and you
01:16:54.433 --> 01:16:57.691 can look up the the the status. You would tend to use and pass
01:16:57.691 --> 01:17:00.949 it in and if you don't have that in the list because it's some
01:17:00.949 --> 01:17:03.949 new status that came from the ERP or whatever that didn't
01:17:03.949 --> 01:17:06.741 exist before, just call the result without a generate
01:17:06.741 --> 01:17:09.741 function or we'll call the upsert function of the type of
01:17:09.741 --> 01:17:12.843 it like account type and pass that in there so that it's in
01:17:12.843 --> 01:17:16.050 the digestion. You can add it to your memory list of what the
01:17:16.050 --> 01:17:19.204 digest you previously called. That way you're always passing
01:17:19.204 --> 01:17:20.497 IDs over and it's faster.
01:17:20.947 --> 01:17:24.074 Because I passed a lookup by ID is faster than a lookup by key
01:17:21.217 --> 01:17:21.567 Awesome.
01:17:24.074 --> 01:17:27.151 because the string value and how SQL has to physically handle
01:17:27.151 --> 01:17:29.981 that information. So if you could do that, that's gravy.
01:17:29.981 --> 01:17:32.810 That's golden to be able to do that on that stuff. And I
01:17:32.810 --> 01:17:35.887 started transitioning more of our stuff internally to do that
01:17:35.887 --> 01:17:38.915 in there. You could absolutely continue to pass a key that's
01:17:38.915 --> 01:17:41.596 not a problem, but it does provide a nice performance
01:17:41.596 --> 01:17:44.127 boost. If you could switch over to IDs themselves.
01:17:45.167 --> 01:17:47.483 Plus you could call that like once at the beginning and save
01:17:47.483 --> 01:17:49.876 it in memory inside connect and you don't have to keep calling
01:17:49.876 --> 01:17:50.597 on subsequent runs.
01:17:52.747 --> 01:17:56.640 Makes sense. And so just to wrap up here, we have just a few
01:17:56.640 --> 01:18:00.406 minutes. Can you show us your postman requests for hitting
01:18:00.406 --> 01:18:02.767 Seth? How we set that whole repo up?
01:18:05.317 --> 01:18:06.267 Uh.
01:18:06.947 --> 01:18:08.487 Zapped authenticate first? Or how does that work?
01:18:07.467 --> 01:18:08.277 I don't.
01:18:09.347 --> 01:18:09.947 I don't.
01:18:11.057 --> 01:18:13.723 I don't know where trust about that anymore because I don't use
01:18:13.723 --> 01:18:15.847 that anymore. I switched to insomnia at one point.
01:18:14.487 --> 01:18:14.967 Ah.
01:18:16.487 --> 01:18:17.817 That works for us. We use insomnia.
01:18:19.087 --> 01:18:21.357 See if Postman's collection is still there.
01:18:21.957 --> 01:18:22.507 Umm.
01:18:24.207 --> 01:18:26.795 And I don't think I think the one that we actually passed
01:18:26.795 --> 01:18:29.428 around, I didn't directly control and I don't remember who
01:18:29.428 --> 01:18:29.607 did.
01:18:30.647 --> 01:18:33.742 But let's open postman and see if it's gonna do anything. For
01:18:33.742 --> 01:18:36.337 me, it might be out of date. It might user profile.
01:18:37.807 --> 01:18:39.317 Where it might just not want to load at all.
01:18:40.087 --> 01:18:40.517 If.
01:18:43.337 --> 01:18:43.697 Yeah.
01:18:47.127 --> 01:18:47.837 Uh.
01:18:47.817 --> 01:18:50.806 And if you have an insomnia repo that you use uh on your local
01:18:50.806 --> 01:18:52.087 James on your main machine.
01:18:51.137 --> 01:18:54.215 I I never created, I never created a repo, I just throw a
01:18:54.215 --> 01:18:56.657 request in whenever I needed to do something.
01:18:57.257 --> 01:18:57.547 OK.
01:18:57.277 --> 01:19:01.471 Uh, because I honestly, most of my my request that I do like
01:19:01.471 --> 01:19:05.528 that I'll do. I'm going to somebody's third party thing or
01:19:05.528 --> 01:19:06.697 I'm doing like a.
01:19:07.897 --> 01:19:08.397 Uh.
01:19:09.357 --> 01:19:12.073 Like I'm trying to experiment a specific way that I need to
01:19:12.073 --> 01:19:14.382 write a property to send it incorrectly, so that's
01:19:14.382 --> 01:19:17.280 deserializes or something like that. I'm not doing like I don't
01:19:14.817 --> 01:19:15.127 Yeah.
01:19:17.280 --> 01:19:19.996 know that a major collection of work I have access to every
01:19:19.996 --> 01:19:22.894 endpoint, I can just click and run it kind of thing and the one
01:19:21.597 --> 01:19:21.897 OK.
01:19:22.894 --> 01:19:25.656 that was there was horrendously out of date and I can't have
01:19:25.656 --> 01:19:28.553 postman on my local anymore and inside here it's not wanting to
01:19:28.553 --> 01:19:29.187 let me run it.
01:19:31.047 --> 01:19:33.467 I'm wondering if this is the app that died.
01:19:34.117 --> 01:19:37.113 As they like replace the the the build of what they had a while
01:19:37.113 --> 01:19:37.347 back.
01:19:39.477 --> 01:19:43.077 No, I think I I think my sign into it, I do I should.
01:19:39.497 --> 01:19:41.818 If you could show us even just a sample insomnia call, that'd be
01:19:41.818 --> 01:19:41.997 fine.
01:19:44.737 --> 01:19:46.687 Yeah, I think I think.
01:19:48.357 --> 01:19:52.479 If I sign into my Google on it, it will bring up the collection
01:19:52.479 --> 01:19:53.187 that I had.
01:19:54.137 --> 01:19:55.467 Is it have been stored in the cloud?
01:19:57.867 --> 01:19:59.835 She's going to run an install for the latest and see what
01:19:59.835 --> 01:20:00.107 happens.
01:20:13.887 --> 01:20:17.538 Dude, dude, dude. Right. Go ahead and close this stuff and
01:20:17.538 --> 01:20:19.147 give myself ram back here.
01:20:25.357 --> 01:20:26.357 You know what? It's so I don't know.
01:20:29.407 --> 01:20:29.867 Back.
01:20:32.357 --> 01:20:34.997 Even Windows is like how dare you try?
01:20:36.497 --> 01:20:36.987 Anything.
01:20:38.777 --> 01:20:39.737 Most men coming up as.
01:20:40.507 --> 01:20:43.957 Processes. Yes, three of them. How about? We knew.
01:20:45.297 --> 01:20:46.017 I want to be sure.
01:20:50.327 --> 01:20:50.897 All those.
01:20:53.357 --> 01:20:54.507 This things being stupid.
01:20:57.777 --> 01:20:58.327 Program.
01:21:09.227 --> 01:21:10.397 Running around now so.
01:21:12.977 --> 01:21:13.537 Be fine.
01:21:16.837 --> 01:21:17.107 But the.
01:21:18.197 --> 01:21:18.597 Mostly.
01:21:21.327 --> 01:21:22.537 This is why we can't have nice things.
01:21:26.697 --> 01:21:27.577 Was my local.
01:21:33.147 --> 01:21:34.667 The Internet is a lot faster.
01:21:50.227 --> 01:21:51.817 Does not want to run postman in this box.
01:21:53.657 --> 01:21:54.037 Weird.
01:21:54.477 --> 01:21:59.100 I only wanna disconnect or stop sharing that screen and switch
01:21:59.100 --> 01:21:59.687 over to.
01:22:00.367 --> 01:22:02.417 My local where I am going to install it.
01:22:09.517 --> 01:22:12.115 And we all use insomnia too. If you have a if you're using
01:22:12.115 --> 01:22:12.687 insomnia, do.
01:22:17.037 --> 01:22:21.095 Jonathan does have a somewhat built out insomnia collection,
01:22:21.095 --> 01:22:21.827 by the way.
01:22:22.907 --> 01:22:23.467 OK, cool.
01:22:28.107 --> 01:22:28.497 OK.
01:22:37.377 --> 01:22:39.567 Uh, jail. Could you share that insomnia repo?
01:22:40.557 --> 01:22:41.367 Collection, whatever.
01:22:42.007 --> 01:22:42.777 Sure, one SEC.
01:22:43.257 --> 01:22:43.597 Awesome.
01:22:48.267 --> 01:22:51.856 OK, here I'll share. I'll I can only have like 9 or listen here
01:22:51.856 --> 01:22:52.417 right now.
01:22:56.597 --> 01:22:58.637 Scratch pads switched over sign in.
01:23:00.047 --> 01:23:01.467 You'd actually sign me in this time.
01:23:04.367 --> 01:23:04.627 And.
01:23:09.667 --> 01:23:11.777 And then if anybody has any specific questions for James
01:23:11.777 --> 01:23:12.147 before we?
01:23:12.957 --> 01:23:13.567 Let him go.
01:23:16.857 --> 01:23:18.817 I feel like my questions would be.
01:23:19.097 --> 01:23:20.697 Oh, here we go. Here we go. I got it. Go ahead.
01:23:22.257 --> 01:23:26.890 Probably a bit too long of an answer for the seven minutes we
01:23:26.890 --> 01:23:28.907 got left, but so on Rydell.
01:23:29.877 --> 01:23:33.216 Brendan made a custom endpoint for upskirting products that
01:23:33.216 --> 01:23:36.444 would be something I'd be interesting or interested in in
01:23:36.444 --> 01:23:39.227 kind of learning how to do like interacting with.
01:23:40.237 --> 01:23:44.245 Uh, the back end and creating an endpoint that would handle
01:23:44.245 --> 01:23:48.253 things a bit more custom but and I think we we saw a couple
01:23:48.253 --> 01:23:52.195 examples of the overrides that did did that, but we didn't
01:23:52.195 --> 01:23:55.067 really get too in depth on how that works.
01:24:01.097 --> 01:24:04.123 Yeah, that should exist inside the ridel overrides client
01:24:04.123 --> 01:24:05.427 project or client folder.
01:24:11.777 --> 01:24:13.628 Yeah, maybe that's a that's probably a worthwhile training
01:24:13.628 --> 01:24:15.197 too, is how to build a custom end point for Seth.
01:24:17.467 --> 01:24:20.467 Uh, I mean, generally speaking, it's really easy. You just make
01:24:20.467 --> 01:24:23.372 a class with properties on it and that's that's your request.
01:24:23.372 --> 01:24:26.419 As long as you have the route on top of it and there's literally
01:24:26.419 --> 01:24:29.419 10,000 examples for how to write a route attribute on the class
01:24:29.419 --> 01:24:32.137 and then your handler is gonna be if it's a post request,
01:24:32.137 --> 01:24:35.090 you're gonna name it post and then you'll pass the class in as
01:24:35.090 --> 01:24:36.777 the argument with the name request.
01:24:37.877 --> 01:24:42.440 And no other arguments, and that becomes the handler for the
01:24:42.440 --> 01:24:45.807 service request inside your service handler.
01:24:46.267 --> 01:24:49.468 Umm for it so that that that's one of the reasons that we have
01:24:49.468 --> 01:24:52.365 and have stuck with service deck. So for so long because
01:24:52.365 --> 01:24:55.160 it's so easy to just new up a new request like that by
01:24:55.160 --> 01:24:58.260 creating that class with those properties and that attribute
01:24:58.260 --> 01:25:01.207 and then the handler to pass all the data back and forth.
01:25:04.157 --> 01:25:07.689 Quick, this collection is as close as I have. I think the
01:25:07.689 --> 01:25:10.916 test collection that was an actual one of a bunch of
01:25:10.916 --> 01:25:14.752 separate endpoints I don't have access to, so it's not showing
01:25:14.752 --> 01:25:15.787 it to me anymore.
01:25:16.837 --> 01:25:20.275 It might have been deprecated, or the person who worked here no
01:25:20.275 --> 01:25:23.498 longer works here and got rid of it. I don't know, but like
01:25:23.498 --> 01:25:26.828 couple of really old ones like an auth logout call from Local
01:25:26.828 --> 01:25:28.117 46. If I were to hit it.
01:25:29.237 --> 01:25:30.217 This had a.
01:25:30.887 --> 01:25:33.677 Form data, whatever this one.
01:25:34.697 --> 01:25:37.357 To emitting an order, but he's telling you that's a really.
01:25:39.607 --> 01:25:42.487 That's that's a, that's a third party client, one this DocuSign.
01:25:43.567 --> 01:25:46.993 Which is their collection to bring stuff in and you can use
01:25:46.993 --> 01:25:50.704 environment variables so that I can pick a different environment
01:25:50.704 --> 01:25:53.844 and swap out this variable automatically for which the
01:25:53.844 --> 01:25:57.441 environment I'm hitting stuff like that. And if I close this I
01:25:57.441 --> 01:25:58.697 have my insomnia open.
01:25:59.697 --> 01:26:02.737 And you know, share and some red.
01:26:05.977 --> 01:26:09.861 Let me just do what reasonable size. There we go. So like here
01:26:09.861 --> 01:26:13.561 is the providers invoicing actions pay an invoice and I was
01:26:13.561 --> 01:26:17.445 detecting whether I was sending stuff through. I was getting a
01:26:17.445 --> 01:26:21.330 four one authorized cuz I wasn't inside of a session yet. This
01:26:21.330 --> 01:26:25.029 server isn't even up right now. This was me hitting a third
01:26:25.029 --> 01:26:27.187 party setup. I believe it was the.
01:26:28.597 --> 01:26:31.444 Ohh yeah, so this is I was trying to gather country data
01:26:31.444 --> 01:26:34.590 from a from a third party API and I used the the request to go
01:26:34.590 --> 01:26:37.637 pull that data and it gave me 3.2 megabytes of country data.
01:26:38.527 --> 01:26:40.777 But I have every country in the planet's worth of info there.
01:26:43.217 --> 01:26:47.000 This is a thing for Patreon. Uh, there is something talking to
01:26:47.000 --> 01:26:50.483 Geo veneer. Using request, trying to get the current card
01:26:50.483 --> 01:26:54.266 and it was failing for whatever reason. So I was trying to fix
01:26:54.266 --> 01:26:55.767 whatever the problem was.
01:26:58.077 --> 01:27:01.007 You're talking to CMMC or stores for connect.
01:27:02.947 --> 01:27:06.243 Which uh gave me a form and authorize. I'm not logged in, so
01:27:06.243 --> 01:27:09.485 the Moodle stuff for like so this is talking to to moodle's
01:27:09.485 --> 01:27:12.673 API to try and get stuff in there. Talking to good hire or
01:27:12.673 --> 01:27:15.915 talking to our API which then talks to good hire and seeing
01:27:15.915 --> 01:27:16.617 does it work.
01:27:17.317 --> 01:27:20.248 Umm, bypassing data in so like this is a request. I'm passing
01:27:20.248 --> 01:27:22.943 that stuff in. I could make a token here to replace this
01:27:22.943 --> 01:27:23.227 piece.
01:27:24.067 --> 01:27:25.987 Umm, so like this would be my.
01:27:26.977 --> 01:27:30.407 I guess one for for sub domain.
01:27:31.707 --> 01:27:34.272 Can't remember if it's one or two inside. Yeah, it's two. So
01:27:34.272 --> 01:27:36.626 with that, I can make an environment variable so that I
01:27:36.626 --> 01:27:38.812 could switch where to environment I'm doing without
01:27:38.812 --> 01:27:41.377 having to create a duplicate of the request with a different
01:27:41.377 --> 01:27:43.437 thing on it. So I can now add the thing and say.
01:27:45.967 --> 01:27:47.837 Environment variable custom.
01:27:49.557 --> 01:27:50.627 Now our variable.
01:27:52.317 --> 01:27:54.787 Uh, a live preview and I can't.
01:27:56.847 --> 01:27:59.222 How to edit that directly? But I have to edit the environment or
01:27:59.222 --> 01:27:59.697 whatever but.
01:27:59.837 --> 01:28:01.087 You have been environment, I think, yeah.
01:28:01.897 --> 01:28:02.697 Yeah, I think.
01:28:02.397 --> 01:28:05.376 How do you make the authenticate call to be able to hit like one
01:28:05.376 --> 01:28:06.247 of those endpoints?
01:28:08.207 --> 01:28:11.385 Oh, that's that's generally speaking in the first thing I
01:28:11.385 --> 01:28:14.618 would do is I would go to a like, I'll go to develop right
01:28:14.618 --> 01:28:14.837 now.
01:28:16.837 --> 01:28:21.841 But I'm actually gonna move this screen over here screen back
01:28:21.841 --> 01:28:24.747 this over here. Somnia right there.
01:28:25.607 --> 01:28:28.217 There at this monitor as opposed to just a screen.
01:28:29.717 --> 01:28:30.577 That I can.
01:28:32.487 --> 01:28:33.177 It's easier.
01:28:34.317 --> 01:28:34.907 Each year.
01:28:42.677 --> 01:28:44.027 OK, so like this is I'm in develop.
01:28:46.177 --> 01:28:49.267 Phillips website. I'm gonna hit sign in here so that I can
01:28:49.267 --> 01:28:52.357 create a session. Just auto fill it with a stupid default.
01:28:57.287 --> 01:28:58.937 OK, my payload here.
01:28:59.647 --> 01:29:03.587 I'll copy that and then I'll go over to insomnia. I'll say new
01:29:03.587 --> 01:29:04.087 request.
01:29:05.607 --> 01:29:07.557 Uh, just control. Invent new, yeah.
01:29:08.377 --> 01:29:10.467 And I'll say that it is a post.
01:29:11.347 --> 01:29:15.592 That the body is Jason and I'll slap that in there. I might take
01:29:15.592 --> 01:29:17.617 a moment to format it slightly.
01:29:19.187 --> 01:29:20.147 Those things like that.
01:29:21.697 --> 01:29:21.937 Great.
01:29:23.647 --> 01:29:26.377 There's the that thing, and then I'm gonna hit the website.
01:29:27.367 --> 01:29:30.574 I'll slap that there on my header is talking to the
01:29:30.574 --> 01:29:31.067 correct.
01:29:31.787 --> 01:29:32.267 Path.
01:29:34.517 --> 01:29:37.352 And boom. So now I had my thing here. I don't have to do
01:29:37.352 --> 01:29:40.087 anything else with any of this stuff. It just hits it.
01:29:41.017 --> 01:29:42.367 And that should generate a session.
01:29:46.627 --> 01:29:47.667 It wants to reply.
01:29:50.867 --> 01:29:53.480 Now there's two things you can do here. One is this and the
01:29:53.480 --> 01:29:55.963 other is. You can clone a specific piece out, so I got a
01:29:55.963 --> 01:29:58.837 reply saying that this is my new session ID and this is stuff so.
01:29:59.477 --> 01:30:01.547 Insomnia should now have a session for it.
01:30:02.267 --> 01:30:06.076 The session is tied to this cookies for SIDS pit and SSRT.
01:30:06.076 --> 01:30:10.337 You wanna if you can match these three cookies on your request so
01:30:10.337 --> 01:30:13.177 some other request that you're going to do.
01:30:15.037 --> 01:30:16.067 On the headers.
01:30:17.127 --> 01:30:20.790 Wherever the cookies assignment stuff is, you can do that.
01:30:20.790 --> 01:30:24.700 There's an alternative method too, where you can actually pass
01:30:24.700 --> 01:30:28.735 on newer versions of stuff from like 2021.4 and newer. I believe
01:30:28.735 --> 01:30:32.646 it actually allows you to put the SSID and spit in as a header
01:30:32.646 --> 01:30:33.267 like this.
01:30:35.747 --> 01:30:38.764 With that value and it will, it will identify that appropriately
01:30:38.764 --> 01:30:41.689 and then apply itself correctly. We had to do that because the
01:30:41.689 --> 01:30:43.917 blazer not being able to use cookies correctly.
01:30:44.387 --> 01:30:46.897 And so that is also an option.
01:30:47.747 --> 01:30:50.110 Pass those in and then a subsequent request with that had
01:30:50.110 --> 01:30:52.107 that. It's kind of like having the token for it.
01:30:52.857 --> 01:30:53.917 How long are those sessions last?
01:30:55.587 --> 01:30:58.593 Ancef by default, unless you've done some rejiggering it in
01:30:58.593 --> 01:31:00.397 custom **** sessions are permanent.
01:31:01.127 --> 01:31:01.447 OK.
01:31:02.467 --> 01:31:05.404 OK, the the ways that they that they quote UN quote die is
01:31:05.404 --> 01:31:08.541 someone with did a flush inside Redis or someone went to Redis
01:31:08.541 --> 01:31:11.628 and like just deleted the urn folder that had all the session
01:31:11.628 --> 01:31:11.877 data.
01:31:12.467 --> 01:31:15.746 Umm. Or you manually went in and deleted it yourself. Or you did
01:31:15.746 --> 01:31:18.874 a logout. The logout should have removed it from Redis though
01:31:18.874 --> 01:31:21.851 sometimes it doesn't. What normally would happen on logout
01:31:21.851 --> 01:31:24.878 though is because you've now lost that cookie during logout
01:31:24.878 --> 01:31:27.653 and lost that header. It's generated a new key for you
01:31:27.653 --> 01:31:30.579 which wouldn't match anything and so you now have a fresh
01:31:30.579 --> 01:31:33.758 session and that session becomes orphaned at that point. If it
01:31:33.758 --> 01:31:34.767 doesn't get deleted.
01:31:35.967 --> 01:31:39.123 On stuff the newest version of CEF develop and forward one of
01:31:39.123 --> 01:31:42.278 the features I'm making in is gonna be the sliding expiration
01:31:42.278 --> 01:31:45.536 timer. I know that BL and some other like the kind of worked on
01:31:45.536 --> 01:31:48.742 that for a particular client. I have an alternate version that
01:31:48.742 --> 01:31:51.643 is kind of marrying. Gonna marry into that from CMMC. So
01:31:51.643 --> 01:31:54.646 basically the best of both worlds for those two pieces are
01:31:54.646 --> 01:31:57.700 going to come together and it should make one fully fleshed
01:31:57.700 --> 01:32:00.499 out solution for our sliding expiration so that it can
01:32:00.499 --> 01:32:03.197 refresh itself but not and not just straight up die.
01:32:03.667 --> 01:32:08.897 And on there and keep it going. The default for that when that
01:32:08.897 --> 01:32:13.630 is available, if you turn sliding expirations on will be
01:32:13.630 --> 01:32:14.377 24 hours.
01:32:16.127 --> 01:32:16.497 OK.
01:32:16.677 --> 01:32:19.595 And then you'll have the ability to set it so that if the client
01:32:19.595 --> 01:32:22.333 wants 90 minutes or they want two weeks, whatever, you'll be
01:32:22.333 --> 01:32:25.027 able to set that as a value for however long you want it to
01:32:25.027 --> 01:32:27.810 last. But the out of box default will still be permanent, but
01:32:27.810 --> 01:32:30.413 you'll be able to settings to adjust that and change that
01:32:30.413 --> 01:32:30.997 those values.
01:32:33.277 --> 01:32:33.667 Awesome.
01:32:33.417 --> 01:32:35.487 Uh, so that that covers that, I think.
01:32:35.857 --> 01:32:38.288 Yeah. And then I put three screenshots in the chat. Is
01:32:38.288 --> 01:32:41.162 there anything more that I need to do or I would need to do if I
01:32:41.162 --> 01:32:43.903 was a or connect developer to build a custom endpoint to have
01:32:43.903 --> 01:32:46.245 that be exposed as soon as I build that it should be
01:32:46.245 --> 01:32:46.997 available, right?
01:32:48.047 --> 01:32:48.577 I will.
01:32:50.097 --> 01:32:52.907 So yeah, you want you want public API just so that it
01:32:52.907 --> 01:32:56.185 doesn't ditch that like the the the set property is never used
01:32:56.185 --> 01:32:59.099 type of stuff. That's what the public API's for used in
01:32:59.099 --> 01:33:02.429 storefront tells it it's allowed to be open and loaded into the
01:33:02.429 --> 01:33:05.759 API for storefront. If you don't have that, storefront will not
01:33:05.759 --> 01:33:08.881 load it. Same thing for using admin using brand admin using
01:33:08.881 --> 01:33:12.107 store admin, using franchise admin, user manufacturer, admin.
01:33:13.067 --> 01:33:16.487 API, the one that connect talks to normally ignores that and
01:33:16.487 --> 01:33:18.057 just loads, it doesn't care.
01:33:18.697 --> 01:33:22.118 And the I return is part of service tech to say what kind of
01:33:22.118 --> 01:33:25.538 response would you normally expect to provide would use that
01:33:25.538 --> 01:33:28.903 as part of our T fours for the TypeScript layer to spit out
01:33:28.903 --> 01:33:32.548 what the response is going to be so that it's strongly typed for
01:33:32.548 --> 01:33:35.856 the reply in there. And then you have your properties. The
01:33:35.856 --> 01:33:39.445 properties are not required to have API member, it's just there
01:33:39.445 --> 01:33:42.585 so that you can provide additional info to make service
01:33:42.585 --> 01:33:45.950 tech more properly understand where is this property coming
01:33:45.950 --> 01:33:48.417 from. Otherwise it tries to use best guess.
01:33:49.127 --> 01:33:51.880 A lot of that you can do by convention if badge ID was
01:33:51.880 --> 01:33:54.932 physically inside the JSON of what it sent, it will probably
01:33:54.932 --> 01:33:58.135 match up the agile you just fine by giving it the explicit name
01:33:58.135 --> 01:34:01.188 of badge ID in there. It knows to specifically look for that
01:34:01.188 --> 01:34:04.341 and take care of it. It is case insensitive on those calls, so
01:34:04.341 --> 01:34:07.544 if you had two properties where one was a capital D and one was
01:34:07.544 --> 01:34:10.647 a lower case D for ID on the badge it will throw an exception
01:34:10.647 --> 01:34:13.850 on loading the API telling you that it can't do that because it
01:34:13.850 --> 01:34:16.853 has to use it in a case and sends it a manner. And I've had
01:34:16.853 --> 01:34:20.156 that every now and then somebody just like it was in two separate
01:34:20.156 --> 01:34:21.657 files and I didn't realize it.
01:34:22.097 --> 01:34:22.997 I'm kind of thing.
01:34:23.847 --> 01:34:28.163 The required will not stop the API from serializing the request
01:34:28.163 --> 01:34:32.277 if you didn't pass it on this piece. But be careful of that.
01:34:34.307 --> 01:34:37.200 And again with a string not. That's not nullable because this
01:34:37.200 --> 01:34:40.000 is supposed to be serialized into existence. That's why you
01:34:40.000 --> 01:34:42.846 have the equal to null with a bang on it so that it knows to
01:34:42.846 --> 01:34:45.832 shut up about the fact that it wasn't initially initialized. It
01:34:45.832 --> 01:34:48.352 because we're expected to deserialize it that way. So
01:34:48.352 --> 01:34:51.198 yeah, that's that handles the first one, second one. This is
01:34:51.198 --> 01:34:53.858 inside your service handler class. You'll have your post
01:34:53.858 --> 01:34:56.564 event you want to award the badge to the user. That's the
01:34:54.107 --> 01:34:54.647 There are six.
01:34:56.564 --> 01:34:59.504 class that we had, and it's the name request. And then we pass
01:34:59.504 --> 01:35:02.304 it into the workload layer. There should be next to nothing
01:35:02.304 --> 01:35:03.517 else inside this function.
01:35:04.277 --> 01:35:07.283 It's unless it's specifically designed to things that are only
01:35:07.283 --> 01:35:10.337 available in the services layer, like who's my current session,
01:35:10.337 --> 01:35:13.343 who's the current user, what's the current domain that I'm in,
01:35:13.343 --> 01:35:16.349 that kind of stuff, where it's information about that's beyond
01:35:16.349 --> 01:35:19.259 the request body, but is more about the environment that I'm
01:35:19.259 --> 01:35:21.979 in. And I would need to pass that information down to my
01:35:21.979 --> 01:35:25.081 workflow. That's the only other stuff that should be inside this
01:35:25.081 --> 01:35:25.367 layer.
01:35:26.737 --> 01:35:29.971 There are plenty of endpoints not following that correctly.
01:35:29.971 --> 01:35:33.313 Bad dev bad. How dare you? Just don't do it in the future. If
01:35:33.313 --> 01:35:36.763 you see it and you can migrate it down to workflow and get a PR
01:35:36.763 --> 01:35:40.212 in for core with permission, I would love to see those kinds of
01:35:40.212 --> 01:35:43.338 things get moved down to what the proper place because it
01:35:43.338 --> 01:35:46.680 means that we can have more of the stuff down in the workload
01:35:46.680 --> 01:35:49.806 layer where it's testable. The service stack layer is not
01:35:49.806 --> 01:35:53.041 testable and in its current state, so stay out of it if you
01:35:53.041 --> 01:35:56.436 can. The whole the whole point of existence is to pass through
01:35:56.436 --> 01:35:57.137 to workflows.
01:35:59.117 --> 01:36:01.908 For stuff and then the last thing you hear this would be
01:36:01.908 --> 01:36:04.994 like your your workflows layer or if it's inside of a provider
01:36:04.994 --> 01:36:07.883 or it's inside your custom overwrite DLL. Whatever this is
01:36:07.883 --> 01:36:10.674 where your real logic of what you're trying to do is and
01:36:10.674 --> 01:36:13.515 you're gonna load settings, you're going to validate your
01:36:13.515 --> 01:36:16.355 data more. You're gonna do other stuff. You're gonna call
01:36:16.355 --> 01:36:19.098 internal async operations. Whatever you're gonna do and
01:36:19.098 --> 01:36:20.077 pass that stuff out.
01:36:20.887 --> 01:36:24.439 If whatever this function is can be elided, meaning it's the only
01:36:24.439 --> 01:36:27.937 async call inside that function, and it's like at the end, which
01:36:27.937 --> 01:36:31.220 in this case it looks like it is. You could elide that await
01:36:31.220 --> 01:36:34.449 function, which means to take the async off of the where it
01:36:34.449 --> 01:36:37.570 says public static async and just have it return the task
01:36:37.570 --> 01:36:41.122 badger response. Take this await and configure await off and just
01:36:41.122 --> 01:36:44.244 return the inner part here where's the send request async
01:36:44.244 --> 01:36:47.742 Badger response request control? I'm sorry, context profile name
01:36:47.742 --> 01:36:51.079 and that allies the task so it doesn't have to be run by this
01:36:51.079 --> 01:36:52.747 function. It can be run by the.
01:36:52.997 --> 01:36:54.287 The thing that's calling it.
01:36:54.977 --> 01:36:59.272 Umm, back up here up here in the service layer endpoint handlers.
01:36:59.272 --> 01:37:03.372 You can never ever ever elide this function, because what will
01:37:03.372 --> 01:37:07.081 happen is service stack will actually serialize the task
01:37:07.081 --> 01:37:10.921 class into the response and break your response. Found out
01:37:10.921 --> 01:37:11.767 the hard way.
01:37:13.027 --> 01:37:16.230 So never elite here, but you're you're more than welcome to a
01:37:16.230 --> 01:37:19.278 light inside your workflows layer that reduces some of the
01:37:19.278 --> 01:37:22.635 tasking and async overhead. When you do that, which is great for
01:37:22.635 --> 01:37:23.617 that kind of stuff.
01:37:25.397 --> 01:37:28.188 But yeah, so. So you're gonna come back to here, and then it
01:37:28.188 --> 01:37:30.659 would get passed. It would serialize the response and
01:37:30.659 --> 01:37:33.542 passed back over the wire. And the very last thing here is all
01:37:33.542 --> 01:37:36.287 of our endpoints should always return task nullable object.
01:37:37.087 --> 01:37:39.681 The reason being that we don't actually care that it's the
01:37:39.681 --> 01:37:42.496 specific type here. We could be throwing exception. We could be
01:37:42.496 --> 01:37:45.310 doing a stuff, action response or something. That's other weird
01:37:45.310 --> 01:37:48.036 stuff. We don't wanna have to enforce extra casting and stuff
01:37:48.036 --> 01:37:50.367 inside this function. We should let it send it back.
01:37:51.087 --> 01:37:54.902 Umm, one of the reasons that we we discovered needing to do the
01:37:54.902 --> 01:37:58.657 object question mark was because on those 30 forward endpoints
01:37:58.657 --> 01:38:02.294 what you're replying with is not necessarily what the actual
01:38:02.294 --> 01:38:05.691 response type is. It might be a compressed service stack
01:38:05.691 --> 01:38:09.268 response class or another, or like an HTTP request response
01:38:09.268 --> 01:38:12.904 class instead of the original class that you have been sent,
01:38:12.904 --> 01:38:16.540 which was that badger response, whatever that is, the badger
01:38:16.540 --> 01:38:17.077 response.
01:38:17.547 --> 01:38:20.405 And you may be just, you may. You may not be sending that
01:38:20.405 --> 01:38:23.264 actual physical object back of the wire, but what ends up
01:38:23.264 --> 01:38:26.024 inside the wire might be like I I compressed an already
01:38:26.024 --> 01:38:28.932 compressed version of that of the original reply that came
01:38:28.932 --> 01:38:31.987 from the cache. So that's part of the reason that we had that
01:38:31.987 --> 01:38:35.191 task object question mark there, and it's confirming it makes it
01:38:35.191 --> 01:38:38.148 easier to just management. You have to worry about it. It's
01:38:38.148 --> 01:38:40.267 just gonna always do the same thing on it.
01:38:41.057 --> 01:38:44.929 But yes, those are the three things that you need in order to
01:38:44.929 --> 01:38:48.675 to new up a new endpoint to do something your your endpoint
01:38:48.675 --> 01:38:52.484 route class, your handler for it and whatever logic workflow
01:38:52.484 --> 01:38:56.169 that's gonna be pushed is gonna be passed through from the
01:38:56.169 --> 01:38:59.603 handler with whatever information you need inside here
01:38:59.603 --> 01:39:00.727 to go do the work.
01:39:02.667 --> 01:39:05.397 Awesome. So as soon as I build that, it's accessible inside the
01:39:03.027 --> 01:39:03.577 Last year.
01:39:05.397 --> 01:39:07.956 client plugins, right? If it's in a client override folder.
01:39:06.887 --> 01:39:07.267 Yes.
01:39:07.956 --> 01:39:08.127 Yep.
01:39:08.267 --> 01:39:11.162 Yes, and because this was inside of a client plugin or if it was
01:39:11.162 --> 01:39:12.097 inside of a provider.
01:39:13.497 --> 01:39:16.615 You do. You did need to have your your apples off so they can
01:39:16.615 --> 01:39:19.833 update the DLL appropriately in order to make it show up and we
01:39:19.833 --> 01:39:22.950 start the the app service with that. So just be aware that if
01:39:22.950 --> 01:39:26.168 it's inside the service project itself, you don't have to do it
01:39:26.168 --> 01:39:28.884 because it's not Stephen providers and it will update
01:39:28.884 --> 01:39:31.247 that DLL and get it going. So you're OK there.
01:39:33.017 --> 01:39:35.974 The last thing I will say is on the properties of this thing.
01:39:35.974 --> 01:39:37.977 Like I said, API members is not required.
01:39:38.737 --> 01:39:42.099 The latest version of SAF that's been released the the the
01:39:42.099 --> 01:39:45.633 release 22.4 and newer have all those extra new properties on
01:39:45.633 --> 01:39:48.767 them that are data contracts. When you activate a data
01:39:48.767 --> 01:39:49.907 contract on a class.
01:39:50.827 --> 01:39:54.372 Every every property then becomes opt in. You then have to
01:39:54.372 --> 01:39:57.738 put those properties on everything. So if you and so if
01:39:57.738 --> 01:40:01.524 you miss that property the the attributes on those properties,
01:40:01.524 --> 01:40:05.369 they will not serialize back and forth. So be careful about and
01:40:05.369 --> 01:40:09.095 that's where some of that stuff gets lost. That is why one of
01:40:09.095 --> 01:40:12.941 the new tests that came out with that release is. It physically
01:40:12.941 --> 01:40:16.487 uses reflection on the entire models section of everywhere
01:40:16.487 --> 01:40:20.212 that's inheriting for service stack and checks to ensure that
01:40:20.212 --> 01:40:23.157 all of those attributes are there appropriately.
01:40:23.307 --> 01:40:26.089 And it will throw in and it will throw an error in the test back
01:40:26.089 --> 01:40:28.829 at you if you have changed one of those things but didn't apply
01:40:28.829 --> 01:40:31.611 the attributes correctly. That's to make sure that you have it's
01:40:31.611 --> 01:40:34.136 to cover your ****, prevent you from accidentally shooting
01:40:34.136 --> 01:40:36.747 yourself in the foot because you forgot to put an attribute.
01:40:38.297 --> 01:40:41.651 And I will require those on those PR's to be filled in. So
01:40:41.651 --> 01:40:42.447 that's that's.
01:40:43.087 --> 01:40:45.785 Thing on the PR reviews that might come up for you. Hopefully
01:40:45.785 --> 01:40:48.353 it's not a big deal. There's literally 10s of thousands of
01:40:48.353 --> 01:40:50.964 properties that have examples on them now. T4 generated and
01:40:50.964 --> 01:40:53.663 otherwise. So there's plenty of examples to go find something
01:40:53.663 --> 01:40:56.535 similar to what you're trying to do and slap it on there and then
01:40:56.535 --> 01:40:58.885 just update the content to actually say like badge or
01:40:58.885 --> 01:41:00.887 recipient, whatever it needs to actually say.
01:41:03.977 --> 01:41:07.104 I know we're over on time. So. So I think we're, uh, we should
01:41:04.297 --> 01:41:04.667 Awesome.
01:41:07.104 --> 01:41:10.131 probably have to stop there. If you have more questions that
01:41:10.131 --> 01:41:13.059 you're thinking of right now, write them down and get them
01:41:13.059 --> 01:41:16.037 into the chat so that we can, then I can try to answer them
01:41:16.037 --> 01:41:18.667 like in the back end chat or somewhere else offline.
01:41:20.557 --> 01:41:22.717 Excellent. This is great. Thanks, James.
01:41:23.757 --> 01:41:24.037 Yeah.