WEBVTT 00:00.080 --> 00:04.040 Okay, here we are looking at app dot Pi, which is our Gradio app. 00:04.040 --> 00:05.560 We only have two imports. 00:05.760 --> 00:08.560 Import Gradio and from sidekick. 00:08.600 --> 00:10.640 Import sidekick the class. 00:10.920 --> 00:13.520 And so uh, yeah, the idea is so. 00:13.520 --> 00:16.080 So this is the way that you build a Gradio app. 00:16.320 --> 00:22.240 Uh, you have, um, this blocks, um, and then you can create your fields. 00:22.400 --> 00:25.000 And as I said, it's not this isn't a gradio class. 00:25.000 --> 00:27.440 So I'm not going to go into too much detail. 00:27.440 --> 00:33.040 I want to give you some intuition that you create fields like a chatbot field, which is where we have 00:33.040 --> 00:39.480 our sidekick, we have our message and our success criteria, and we have a go button and a reset button, 00:39.720 --> 00:40.920 um, here. 00:41.360 --> 00:45.520 And, uh, yeah, the thing I wanted to mention, the way that Gradio works is that you have a bunch 00:45.520 --> 00:51.640 of these callbacks that where you have things like, um, you have go button click, and that means 00:51.640 --> 00:57.600 if you click the go button, it will call this function, and it will call it with these inputs. 00:57.600 --> 00:59.720 And it will hook up these outputs. 00:59.920 --> 01:05.880 And when you get used to gradio, you see it all starts to click and you see how you can just simply 01:05.880 --> 01:08.560 think of everything in terms of these callbacks. 01:08.840 --> 01:14.800 And everything here is sort of generated and runs in the front end in a browser, except these callbacks 01:14.800 --> 01:18.600 are called back to your actual server that's running right here. 01:18.640 --> 01:20.400 And so that's how the whole thing works. 01:20.640 --> 01:26.480 Now there is a callback called load, which is one that is called at the beginning when a new screen 01:26.480 --> 01:28.480 is brought up and loaded. 01:28.520 --> 01:33.520 And that's an important one for us here because that is when we're going to call a callback called setup, 01:33.640 --> 01:37.160 which is going to return something called sidekiq. 01:37.320 --> 01:42.280 And that is a something that we're storing in the state of this gradio. 01:42.520 --> 01:44.440 So this is something the sidekick. 01:44.480 --> 01:45.240 It's a state. 01:45.240 --> 01:49.880 It means I'm going to set it through various callbacks, and I'm going to provide it in callbacks so 01:49.880 --> 01:54.240 that that's going to be associated with a particular user of this screen. 01:54.680 --> 01:59.040 Um, and I've also registered this delete callback free resources. 01:59.040 --> 02:04.800 And that's how I'm hoping to clean up this playwright and chromium browser that's running associated 02:04.800 --> 02:05.720 with this resource. 02:06.000 --> 02:10.120 But because we've done it this way, we've done it quite carefully with Gradio, which I've I've not 02:10.120 --> 02:12.480 been careful with some of my prior Gradio projects. 02:12.880 --> 02:15.800 Also in the LM engineering course, no one's called me on this yet. 02:15.800 --> 02:22.240 But but in the big thing we do at the end, I don't properly use gradio state, which means that if 02:22.240 --> 02:27.600 you brought up multiple screens or if you had different users trying to use your platform, and it is 02:27.600 --> 02:32.320 only intended to be used by the individual themselves, but you could get in trouble because everyone 02:32.320 --> 02:34.920 will be sharing the same like like variables. 02:35.360 --> 02:41.720 So this makes sure that different people using the screen, if you were to to supply this as an app, 02:41.760 --> 02:45.720 they would each have their own separate session with their own variables. 02:45.960 --> 02:50.720 So in this case we initialize it by calling UI load. 02:50.720 --> 02:55.280 So if we go to the load callback sorry not not the it's called setup. 02:55.280 --> 02:56.160 It's the callback. 02:56.560 --> 02:59.160 Here it is uh setup. 02:59.440 --> 03:04.030 And what that does is it instantiates it creates a new instance of sidekick. 03:04.190 --> 03:09.070 And remember that that sets up it just has a bunch of of things in the init to get things ready. 03:09.070 --> 03:14.910 The big work is done in sidekick setup, the async method that we await right here. 03:15.190 --> 03:21.510 So that now populates all of the things in sidekick, including building the graph. 03:21.510 --> 03:23.830 So this is where all of the graph gets built. 03:23.870 --> 03:25.310 The nodes are put together. 03:25.350 --> 03:26.470 Everything happens here. 03:26.470 --> 03:32.550 These are all of the steps, the five steps that happen before the graph is invoked, before any super 03:32.550 --> 03:32.950 step. 03:33.350 --> 03:36.470 And then this callback returns sidekick. 03:36.590 --> 03:42.030 And that means that sidekick is hooked up to this, also called sidekick. 03:42.430 --> 03:47.750 This variable also because this is the state object associated with the session. 03:47.750 --> 03:53.510 So that means that the sidekick that we created right here gets associated whenever you load a user 03:53.510 --> 03:54.310 interface. 03:54.310 --> 03:59.830 That user interface is associated with this particular sidekick Instance. 03:59.830 --> 04:00.270 Okay. 04:00.310 --> 04:01.270 Hope that made some sense. 04:01.270 --> 04:06.950 It doesn't need to make you just just get some intuition for it and understand the basic plumbing and 04:06.990 --> 04:09.150 that will that will be all that you need for now. 04:09.310 --> 04:09.830 Okay. 04:09.870 --> 04:15.590 And then I just wanted to mention the big thing here is that there's a go button, and that go button 04:15.590 --> 04:16.630 says go on it. 04:16.870 --> 04:20.430 And if we look at go button.click we'll see what that does. 04:20.550 --> 04:25.350 It calls Processmessage, which we're just going to look at in a second. 04:25.390 --> 04:26.430 That is a callback. 04:26.430 --> 04:32.230 And it calls that with the message that the user has just entered, which comes from from here, uh, 04:32.470 --> 04:39.150 with the success criteria which the user has entered, and with all of the chat history and what comes 04:39.150 --> 04:45.830 back needs to go to the chat history and to the sidekick object to make sure that we keep that updated 04:45.830 --> 04:46.510 in state. 04:47.190 --> 04:52.710 Uh, and so, uh, and I actually don't think you need to do this, but I feel like it's, it's, uh, 04:53.150 --> 04:57.430 more consistent to do it that way to, to repopulate that in the state. 04:57.430 --> 05:00.150 But if you're a gradio wiz, you know what's going on here, then? 05:00.190 --> 05:03.190 Probably like me, you know that this is probably not required. 05:03.430 --> 05:03.910 Um. 05:03.950 --> 05:06.190 But anyway, I digress. 05:06.390 --> 05:08.390 This this is the process message. 05:08.590 --> 05:09.430 Uh, callback. 05:09.430 --> 05:10.870 It's perfectly straightforward. 05:11.070 --> 05:16.230 Uh, it takes everything that I just mentioned that's hooked up to to Gradio, and it simply calls the 05:16.230 --> 05:23.990 run super step method, a coroutine that we looked at just a second ago on our sidekick object. 05:23.990 --> 05:27.510 The thing that we that we instantiated so it calls run super step. 05:27.550 --> 05:30.950 It passes in the message, the success criteria and the history. 05:30.950 --> 05:34.110 And that is going to run a super step of our graph. 05:34.310 --> 05:37.390 And then it's going to return the results back to the user. 05:37.910 --> 05:41.230 And that that is the tour of the app. 05:41.230 --> 05:43.110 It's the same code that we had in Gradio. 05:43.270 --> 05:48.550 It's just sorry in the notebook, same code we had in the notebook, just with a bunch more tools, 05:48.830 --> 05:53.990 a bit of a built out prompting there to handle some some troubles that I had. 05:54.030 --> 05:55.790 And you will have to do a lot more, I'm sure. 05:56.030 --> 05:59.790 And with that, it's time for us to give this thing a drive.