Responder Web Framework Mini-course Transcripts
Chapter: Building a RESTful API with Responder
Lecture: Cleanup and refactoring for real web apps
Login or
purchase this course
to watch this video and the rest of the course contents.
0:00
The last thing we want to do is just reorganize this. Now, if this was the entire application I'd be fine to leave it the way it is.
0:07
But I know how real web apps are. They have hundreds or maybe thousands of these view methods, and templates and all sorts of things.
0:15
So you want to reorganize it and set yourself up for growing into a bigger app than this if that's at all possible. So how are we going to do that?
0:22
Well, the data thing is fine, the templates you can see I've already organized them in a way that's pretty good. Similarly, for the static files here.
0:29
So those three are going to be fine. What we're going to focus on is just this file. Now the one thing we need to do is
0:35
this thing, you can see it's used here, and here, and here and it's an instance. So it's a little silly, but what I'm going to do
0:42
is I'm going to create just a file that basically has that one single line in here. So I'll come up with something like api_instance
0:50
and we'll import responder, and I'll say API equals responder.api, like that. And that's it. So over here, we're not going to do this.
0:59
Instead, we're going to say from api_instance import api and that puts us back. But what that means is other files can also import this
1:08
and share that instance. If I put it here, and then this file has to import some other files, but those files need access
1:15
to that instance, so they got to get back here first it gets really complicated. So this kind of breaks that circular dependency.
1:21
The next thing i want to do is I want to have some views here. Let's have a whatchacallit, like a home view hence the name home right there.
1:30
And, woops I didn't want that to be a directory. I want that to be a file. Have a home set of views, and I'm going to have API views.
1:41
You could just call it API but it's kind of highly confusing that this is also called API, so let's call it api_views.
1:47
So then we're just going to say well, this kind of stuff is what's going to go over in this part
1:53
and we're going to have to say from api_instance import api and this one's done. Now, again pretty simple, but in a real app
2:01
you have tons of these and they'll build up. So that'll be good to have that out of the way. And then here's our API methods, these three.
2:09
Let's take those and put them here. And again we need the api, you can see the arrow there from api_instance import api.
2:17
We're also going to need responder, and this thing really was only defined here for that purpose so I can put that up there.
2:24
We also need our db, so it looks like we have that all up there, everything's cleaned up. Now if I try to run this, how well is this going to work?
2:31
Well, we initialize our database and we call run. How's the responder going to know about these routes? Probably not very well, let's try.
2:38
Yeah, not found. Didn't know so well. So what we need to do is basically let Python more importantly the decorator see these
2:46
and the way you let that see it in Python is you just import it. So we'll say this, from views.home import *
2:53
we'll use star which is normally discouraged but we'll use it because as we add new ones it's just going to get everything. And what else we want here?
3:00
api_views. So we can go say, don't do this. Don't tell us these are not used because they are used. Alright, great.
3:08
Now if I run it, it's not looking great. We still got one more thing to do, but it's getting there. Back to work.
3:13
Woo hoo, everything's working again, see that? But now if we want to go and add something we know where we go. Here's more HTML template based views
3:21
here's where we put some more API methods. Those are all separated from say, the app start up like creating the global_init, importing the views
3:29
creating the app sort of over there and then calling run. So you might want to add a little bit of extra work here
3:36
to make this, I don't know, look a little better. We can put his into a main, or something like that and then use our Python convention one more time.
3:46
Here we go. Alright, so I'm going to call this much more cleaned up and ready for big boy web application that actually does a whole bunch of stuff
3:53
doesn't just cram everything into that app.py file like so many of the Flask apps do. Alright, well that's Responder all put together for you.
4:01
It's a pretty cool little web app. One of the important things we haven't spoken about is because it's an ASGI framework based on Starlette
4:08
we could put async here and use say like await right here, if the database actually supported async behaviors. It doesn't.
4:18
That's why I didn't talk very much about it. But one of the big advantages here which some of the others do have as well
4:23
is that we can use async on our view methods which is pretty awesome. Alright, that's responder in a nutshell.