The Django Jigsaw Puzzle: Aligning All the Pieces with Will Vincent

So

Speaker 1: today's talk is the Django jigsaw puzzle. And this is based on the fact that I've now been using Django over a decade and I feel like I'm only starting to see the patterns. And so I wanted to share with all of you How I see it and something that can help both experienced developers if there's some areas of Django you haven't used, because I'm pretty sure no one has used all of Django. And then certainly if you're mentoring someone else to get a sense of why it's so confusing, or if you're a beginner, and I know there's plenty of beginners here, which is a great thing at the conference, I this is as best I can do to show you a roadmap of How to learn Django and you know if you can't read the thousand page of the docs and absorb it all. So it's a beginner-focused talk. Um we're going to cover web frameworks, Django in particular.

Speaker 1: Let's dive into it. It's 45 minutes. If we need to take a break, we'll do that. But let's let's go. So this is how it feels like. This is how it felt like for me. I think especially because half of all professional developers don't have a formal uh education in computer science. I don't. Django fellow Carlton Gibson who's here doesn't. You know many many of the people who actually the creators of Django except for Simon Don't have it as well. So it's very, very common. And when you have a traditional education, it's bottom-up. You learn about circuits and logic and hardware and software, and you probably don't even get to cover the web at all. But for the rest of us who want to use code, we're just dropped in from the top and kind of sort it out as we go. And so you can often get things working, but really not understand how they fit together.

Speaker 1: Because you don't need to, but then there becomes this point where you say, well, it works and now it's broken and I'm stuck. So I want to try to, again, give the scope of Django to help get you unstuck. And also I would mention this is certainly my uh the case for me, but many people when they're learning Django, it's their first time learning a web framework. So I'm gonna cover quickly a little bit about web frameworks in general, because if you don't know about web frameworks, It's a lot to learn and cover and you might blame Django for it, and it's not Django's fault. So um I think this is covered. I wear a lot of hats. Um happy, especially the I'm I've been the treasurer of the Django Software Foundation board the last three years. That's the nonprofit that handles everything but the code and nominations just opened up for next year's board so I'm happy to talk to anyone about that.

Speaker 1: But yeah, do a bunch of things. I'm very committed to Django. Very lucky to be able to focus on it. So computer basics. So even though I just said like I don't want to go bottom up, we're gonna do some quick quick bottom-up to set context. So right, everything is turtles, everything is an abstraction. Um I mentioned this with with code, but programming languages, you know, Python itself, interpreted language written in C, sits atop assembly, ultimately binary code. You know, nobody knows all of the stack. You just get a sense of it and then pick a turtle and focus on that. So we're gonna focus on the web bit. But it's okay to feel overwhelmed by all of this. I mean The more I get to know the most impressive people to me, the more I realize they just

Speaker 1: talk about all the things they don't know. Yeah, we'll skip ahead on that. Okay, World Wide Web. Again, briefly going through this. Call response. Um, this is how it works. Tim Berners-Lee in 1989 came up with HTTP, the protocol for sending requests. Uh pages hyperlinked together. There's other protocols, SMTP for email, FTP for files, but essentially a protocol is agreed upon language that computers can use to talk to one another. Just as I'm using English. you know if we were speaking Spanish we would have a sense of the syntax and grammar that we could use. So this is something that if you're Not familiar with web frameworks doesn't confuse you, but if you're coming from other frameworks, really confuses you.

Speaker 1: This is the MVC, the model view controller setup that most modern web frameworks use. And it's it's a way to separate logic at the end of the day. So the model is where we store our data, connects to a database. Controller, this is business logic behavior. So in Django, that would be like a view. And the view in this, like in Rails, is a presentation layer, which would be like the template. So Django, if you want to put this construct onto it, would be more of an MVT. But I find it interesting because I didn't have this in my head when I was learning Django, so it wasn't confusing to me, but for the first five years I was Uh using and teaching Django, people who'd done any other framework, especially Rails, would get really stuck on this.

Speaker 1: And I think it's because of the view thing. So don't get stuck on it. Okay, so we're gonna build out over the course of the talk. Really the reason why I did this talk is I I hadn't seen a full you know, image of what happens in Django, right? You send a web page in, magic happens, and sends it back. And so we're gonna build this out to give a sense of the entire request response cycle in a Django app. And to do that, we're going to start by implementing a basic blog just to cover the fundamentals of Django. So the setup. So this is where if you've been using it Django for a while, you just say you'll just install Django. And I know because I teach people for a living, many people just get utterly bewildered and stuck here.

Speaker 1: You know, there because there's all these assumptions. The first assumption is you know what the command line is. I think many people in this room do, but many people do not. They've never used it before. It's a scary place. You can nuke your computer. There's often no feedback on what happens. So if someone comes to me and says I want to learn Django, usually I'll say well you gotta do some familiarity with the command line because how can you install Django without the command line? Right? It's very easy, I think, when you're familiar with Django to skip over this. And a beginner just goes, I can't even do the first step here. So command line text only, uh there's a lot of shell commands In practice, like I just use the same five or six over and over again and I look up the rest. I think most people are like that unless you're you know specifically needing to use the command line a lot.

Speaker 1: Commands are generally similar similar on Windows and Mac OS except when they're not. So that's a pretty common gotcha. For me with my books, I've recently added Windows support because most of the world is on Windows, not Mac. And every every cycle, every update of Django, there's certain things I need to test everything and tweak. So it's a bit frustrating for me, but imagine how frustrating it is for beginners as well. And this, does anyone know what this is from? Can anyone s tell the the who uh what movie this this bit is from? Tron, yeah. Tron Legacy 2, yeah. So he goes, who am I? Right. So I thought that was pretty cool when I saw the. But you know, in it's always in a movie, it's always a little black box and somebody going like this, and they just it works. Anyways, if you want to install Django, you need the command line.

Speaker 1: Pip install Django. Python. Again, this is another one. It's super easy to overlook. This just stops people like cold in their tracks. If I asked in this room how do you install Django, I would get easily a half dozen different answers. Right? So imagine if you're a beginner, what where does that leave you? You're like, well, I don't know. I'm not the expert. So I'm gonna say teaching beginners, I these are the two options I would say, right? You just want to get it going, try it out. The Microsoft Store, you can install Python now. That's grown leaps and bounds in being easy to use. It sets your path now. I would say that's your first bet. And for a Mac, you used to be able to use homebrew. There's a number of issues with that now, unfortunately. So I would highly recommend using just the official installer.

Speaker 1: And as you get more advanced, you'll need things like PyEnv and all these other things, but that'll get you started and then you can go get confused and argue with people. It's one of the religious debates. How do you install Python? But that will get you going. Virtual environments, this is something that I don't believe is mentioned in the Django docs particularly. So this is a longer-term project I have being on the board to improve the docs. How do you know you need them? What are they? It seems it's almost like by the time you learn it, you assume it's obvious, but people it's not obvious to people. And there's also a half dozen ways to do it, right? You can use the Venv module built into Python, you can use poetry, you can use pipenv. Sorry, you can use PyEnv, which I mentioned before. So basically what by default things will be installed globally on your computer, and for each project you want to isolate your Python dependencies.

Speaker 1: So you want Python 3. 6 in one, Python 310 and another. Django versions, nice little box to control everything in. Again, something that super trips up beginners. All right, so now we finally get going. Our first command, so start project. And here we go. There's multiple ways to do it, right? So if you do it this way, there's two, it'll double the directories for you. That's fine. Um I prefer to do it this whoop. Well that's a mistake. Should have a period. If you add the period at the end, it will just have the single directory. Two ways to do it. You just need to pick one and move on. And then we can run the run server command and it spins up the Django

Speaker 1: welcome page. But you know how did that happen? Like what what's going on? So Django ships with its own lightweight server for local development. It will serve static files. So you think well that's not an issue until you try to deploy for the first time and then you realize static files are tricky and it defaults to port 8000 though you can um change that so very convenient um not for production but you don't know any of that when you get started Okay, so they're building out our diagram here, right? We have client response web server magic. All right, we're gonna fill in the magic on the rest of it. And if uh when you run run server, it also runs the system check framework within Django, so you often see error messages like when you run

Speaker 1: Like whoop, we'll get to it. When you run um run server for the first time, you'll have 18 unapplied warnings about not installing things. That's confusing to people. So let's I want to quickly run through a Django blog just to cover the um basics of Django and then we're going to get into kind of the cool exciting stuff. So WISGI ASGI, I bet most beginner intermittent intermediate developers have no idea what this either of these are and and why should they it just work. But back in the day, web servers didn't necessarily connect to web frameworks. They had to have their own versions. WISGI is a standard way. To do that, PEP3333, I believe. And so it's not a server framework itself.

Speaker 1: It just sets the rules so that any Python app will run on any Python server for us. There is a 2021 DjangoCon Europe talk that Timothy McCurk has, The Request Response Cycle, A Django Nautic Journey, where he goes really deep on all this, and I highly recommend you watching that. that but I'm not going super deep on it today just this is kind of what's happening um and will matter more when we get into production So I just mentioned this, but like where is it? Well it's the whiskey. py file. Again, like settings file takes 10 years to kind of have a sense of for me anyways where everything is at. So it's sitting in there. We could dive into it, but that's where WISGI gets set up. And there's also, if you notice, there's an ASGI. py file for an asynchronous web server gateway, which was added in uh Django

Speaker 1: 3. 0, and we'll talk about async in a moment. So this is now, I would say, what the what it looks like. So now we have client, web server, WISGI server, Django app. Comes in, comes out. Um and the what the key thing is the WesG WISGI server sits between our web server and our Django app. All right, Django commands. So I would guess that these five are the ones most of us use 90% of the time, but there's many, many built-in commands. Start project to create a new project, start app to create a new app, more on that shortly. Make migrations to create migrations when we update the database, migrate to apply them, and then create super user. to create a super user account which you need for the Django admin, which we'll talk about.

Speaker 1: Um what's confusing to people? Okay, well why Django Admin as opposed to python manage. py and that's because it's about the Django settings module. So basically Django admin just does it and Python manage. py will look to your settings file and load in extra goodies. So Again, that was confusing to me for many years. I don't know about others, but I thought I'd cover that here. Um And so when you run that command, uh if you run the migrate command, for example, you'll see there's finally it initializes a new database, a D a SQLite database, file-based, very convenient for development. You can put it in production. Talk to Simon Willison if you want more opinions on that. Generally a lot of people won't, but boom, here's a new file, and that's our local database we can use, but most people again won't use it in production.

Speaker 1: You only do something else. So adding on another puzzle piece, right? Client, request response, web server, WISGI server, Django app, connected to a database. And we're gonna fill in what's what's going on. So when you create, we create a new project. Um and For those, again, another thing that trips people up, projects versus apps, one project, multiple apps within it. Um smaller pieces of code that's up to the developer to structure, but generally want to be focused on one isolated thing. So you on a larger site you'd have an authentication app, a users app, a blog app. Use a startup command. Usually you'd use the plural of a name, so you'd use posts , unless it's something like blog where

Speaker 1: blogs. Doesn't make much sense, but generally you should you should use the plural as the best practice. Um and if you're on the command line, you run this command, you're not gonna get any feedback. You only it's only if you run LS or you to see to list what's been created or look visually to see that something has actually happened here. And then the process many of us are familiar with. You create an app, but you have to tell Django about it to use it. This springs lots of um Errors for beginners and myself. I forget to do this all the time too, right? Even 10 years in. But you need to add it, add the app name to your installed apps. Those ones listed there are Django's built-in apps, which You could do an entire 45-minute talk on each of them, but

Speaker 1: not today. Models, right? Moving along. So the tricky thing is you need a model, a URL, a view, and a template. for m pretty much any basic app. And the order doesn't particularly matter. You just need all four to work. So that's as a teacher a question I get all the time. Which do I start with? And it's unsatisfying to say it doesn't matter all four of them, but you know, they all got to fit together. So this would be a basic blog model. So import models, just two fields, title and body, string method, which is You should probably add so it's human readable and get absolute URL, which is a good practice for a detailed view down the line. So this is using Django's ORM, object relational mapper, which we'll

Speaker 1: I'll mention a little bit later. But it translates this Python code into SQL code that will work on any of the supported databases for Django. So SQLite, Postgres SQL, MySQL, MariaDB, Oracle. I got them all, Carlton, right? Yeah. So that's really, really cool. I mean, in many ways, I th the more I do Django, the more I realize the ORM is kind of the heart of what it does. And that's a really black box. Um there's some talks on that. But I'm not going to go into them. So we create the models. You would having uh create new models, we would run m make migrations to uh have a migrations file in case we want to roll things back or forth, and we'd migrate it to apply it. Admin, right? Um can I just show of hands?

Speaker 1: Who uses the admin here in all their projects? Okay, who doesn't use the admin? Okay, so about five hands don't use it. Most people use it in some way. I know there have been talks today on how you can you know use and abuse the admin, but it's a pretty killer feature, especially when you're starting out, to be able to load in data and manipulate it and and use it in your project. Nope. Nope. So you do a create super user command. Again, doesn't give you any feedback. Which is scary to beginners, and then you can spin up your your Django admin. Um this file can get really bloated, and I would personally say when this starts getting like 20 lines long, you might think that you're want to revisit how using the admin, but use

Speaker 1: simply it's fine, I would say. So I don't have slides to show it, but we could then log in and graphically add some blog posts to our To our site at this point. So views. So we have the data, but how do we get it out onto the page? So this again would be the controller in a typical MVC framework like Rails. It handles behavior and business logic. There's a whole thread actually on the official Django forum which you should check out about where to put your business logic because as you get more into Django you realize it has batteries, but you can pretty much do whatever you want. So Often logic will be in the views. In this case, we're just implementing a very basic using a list view. So it's a built-in generic class-based view just to list items

Speaker 1: in the database. And then a detail view. So it would be all blog posts. a single blog post and you link it up to the model so that's our database model and then uh the template name we'll get to that in a second so each has a different template name So uh uh views can be like a religious debate in terms of function-based views versus class-based views. Um And I actually I only learned recently why generic class-based views are they're a little bit odd in how they're implemented, and it's because they mimic generic function-based views back in the day. So there's a whole history on that I would recommend looking into. But again, actually let me I'm curious for the for the room. So I'm gonna ask, who prefers function-based views? If you could raise your hands.

Speaker 1: Okay, I'll say like a third of the room. Who prefer prefers class-based use? Two-thirds. Right. So like right, like what are we doing to beginners here? You know, there's so many of these things that even in this room, even in DjangoCon, how do I do start project? How do I do all these things? You know, and a beginner they just want to work, right? They just want someone to say do it this way. Um, and the last piece is URL routing. So how do we match all our logic and information to a specific page? Django uses URLs. py file for this. So there's one that's included in your project directory. This would be a simple way to add it just on a below admin and then we have to create our own URLs. py file in each app

Speaker 1: and this would be a basic way to have the list in detail view. You can throw in variables, all sorts of things, but again, if you've never used Django before, this is just kind of how you build a basic one. Oh, finally templates, yes. So Let me skip slightly. So the organization, um Django will load in your templates by default. It'll look for a templates folder, then app name, and then the file name. You can also create a project level templates directory. Yet another choice in the Choose Your Own Adventure of Django. But you can put in variables, tags. There's a pretty basic Django templating language, which starting out, I wished it were were more powerful, but now I

Speaker 1: appreciate the fact that it is not particularly powerful, that it's maintainable. You can add in Jinja 2, you can add in all API calls and JavaScript web frameworks if you want. But it will get you a lot of the way there with a minimal amount of fuss. So server-rended templates. So this would be how if you wanted to create a template directory, which I generally recommend to beginners, but you don't have to. Okay, and then we're gonna quickly, so this would be a uh if you create a base, a base template from which others can inherit home. Um Post detail. This is what I want to get to though. So here's this is most of Django. There's still a little more to go, but this fills in what's happening.

Speaker 1: You have a The client submits a request, hits the web server. In this case, it's just a local Django web server, hits the WISGI server, then we're within Django, hits the URL conf. Goes to the view. The view combines the models and templates, hits the database if it needs to, sends it back to the client. Static files. Who here uh I guess I'm curious who here uh has trouble with static files in their in their project? It's a good good amount of hands. Yeah, so static files are super tricky. They seem like they shouldn't be, but they but they are. So static files, any files that aren't pure code, so CSS, JavaScript, images.

Speaker 1: I think part of why it's tricky is because the way you do them locally, the way you do them in production differs. I would suggest creating a static directory in the root level. And so in this case, if we want to we create a static directory, a CSS directory, and within that a single base. css file. Static files are different than media files, which are uploaded by users. So if you create an Instagram clone and users could put up images, those would be media files. Those are handled differently. We'll talk about that. that in a sec. So this would be a basic way to do your your your templates. You would have so your CSS on the side there. The key thing is you load in with your static tag. I forget that all the time. to do even all these years.

Speaker 1: And then you reference when you reference the CSS based CSS file, you would toss it in there. The other thing I also forget all the time is static in our settings file at the bottom, static URL is set automatically. It presumes that The files will be in a static directory, though Django start project doesn't create it for you, so you have to create it. But you need to set the static files, DERS , to tell Django if you have a project level directory, because it tells Django where else to look beyond within the app. Okay, so now we've added on the file system, right? So I don't need to trace it out, but this is there's what maybe one or two more things, but this is essentially I would say the flow. Django request response. And I think if a if a beginner intermediate person has this image in your head, it will make a lot of the pieces fit together better.

Speaker 1: Like I again, I didn't s see a image like this until years into my career and I wish that I had. But this is what like a CRUD create read update delete app looks like, which some variation of that is most websites. Okay, so now a little a little more interesting. So now the core things that Django gives. Middleware. So this is a framework of hooks into Django's request response processing. So it's a low-level plugin that you can put things in in between our individual requests and responses. The key thing is the analogy of it being like an onion, right? So it the request comes in, hits the first middleware, second, third, on down, then it hits the view, and then it propagates back.

Speaker 1: And your settings file, there's a whole big thing with middleware with all these packages, or not all these middlewares that Django provides for you. It sort of makes sense the first so it's again starts at the top, they're loaded top to bottom. It sort of makes sense security would be the first one since you want your app your app to be secure. And you can also write custom middleware. And if you use a third-party package, often they will need to be implemented here, inserted here in some respect. So this is um this is like 95% of the talk, I think, is like this view here. Um this is what most of the request response cycle looks like. comes in server file systems part of it whiskey middleware Django app

Speaker 1: um and back If there's any if anyone has any questions, you're free to raise your hand. I know 45 minutes is a long time, so feel free to interrupt me. Okay, authentication. One of those things that if you've never built your own, which you shouldn't because it's really hard to do, take for granted, but Django comes with a fantastic built-in auth app, login , sign up, log out. This is anecdotally on my personal sites the the tutorial that gets the most traffic by far is a Django login logout signup tutorial because the docs are docs, they're not a tutorial, but Pretty much everyone wants authentication in their Django project. And we, putting on my Django Software Foundation hat for a second, don't have a great story there to tell people.

Speaker 1: So this trips up people. This would be the basic way you would do it. So if you look in your installed apps, you can see contrib. auth is there. Authentication middleware is there. We just talked about middleware. And this will handle your complete cycle for you. But unlike some other frameworks, it doesn't, we don't just give it to you configured. You have to do configuration. yourself. So password reset, most people want to have password reset. That involves using email. So you can do email locally or Most of the cases, if you want to connect to Sengrid, Mailgun, you know, your mail provider of choice, you do something like this in your settings file. Again, there's also built-in templates you can easily customize.

Speaker 1: Where are they? You probably need to look in the Django repo itself. You know, I like search, copy and search like the text on a particular login or password reset form, and you'll find the uh core template unless you're very familiar with the the Django project itself. Last thing is custom user You could do probably a whole talk on custom user. Actually, again, let me ask for the room, who here uses a custom user as opposed to a user profile? So who's custom user? Okay, who doesn't use custom user at all? I'll call that about half and half, including Django Fellow Carlton Gibson. So the docs say recommend you should use a a custom user. Personally, I think If you're starting from scratch, I would just toss it in there in case you need it later.

Speaker 1: But that's a whole subject of a talk that we won't do today. So I think you can't really understand authentication unless you truly understand HTTP. I have a whole talk on this from 2018. But HTTP itself, the protocol we're using, is stateless. So each request is independent and doesn't know past requests. So this causes a problem. How do you know who I am if you don't can't remember anything? Right? So it goes like this. Hey there. Remember me? Nope. No idea who you are. So we have cookies. Cookie is just storing a bit of information on your computer that says who you are essentially at a very high level. So it introduces some memory where we didn't have it before.

Speaker 1: Without a cookie, each HTTP request is a completely isolated event. You have no idea who anyone is, you can't do payments, you can't do anything. But you also need a session. So a session is on the server side. So it matches the cookied browser to information about a user. So you can say, oh, you have this cookie. Let me look in the session's database. Therefore you're this user. And I have lots of notes about how to go deep on this. But I would just say if you want to learn more about this, I have a whole 2018 talk on authentication that I would recommend. Okay, moving along. Forms. Forms are um something that just work when you're starting out, and then as you get more into your career, you realize how scary and complicated they are.

Speaker 1: um at least for me. So it's a way to gather data and send it to the server. Typically you're going to do a GET or a POST request. So GET is for getting. If you want to get information like do a search search query and post is for uh sending. I have a also have a talk on search from 2019. If you want more on that. Uh the key thing I want to mention, especially for people who are beginner intermediate, is it's pretty easy to not know about cross-site request forgery, which is basically the way your forms are going to get hacked. But if you Take some small steps that Django provides, you won't get hacked, but it's very easy to forget to do it. So there's a middleware that does this, but basically cross-site request forgery, someone can have a rogue form. So they can

Speaker 1: set up a fake site. But have a form that posts to a legitimate site. And if you're already logged in at that site and have a cookie, a bad actor can take control and have you do things like withdraw money from your account. So the defense is to generate a large random number, which is what this CSRF token is. So this would be how you would implement it. You just toss in the CRS CSRF token on any POST request. form and that will cover you. So again, this is something that I I feel like it's very easy to just not not get or not do as a beginner because you read it somewhere, it's you don't

Speaker 1: Remember to do it. It's confusing how sessions and cookies works, but I don't know. My site is live and everything's good. But I include it in my slides. I I don't have that many more because it is a I would say a fundamental thing you need to have in all your all your sites and if you're a beginner it may not um be clear that that is the case. So the Django shell um let me ask again uh How many people here prefer to use the Django shell, if you could raise your hands, as opposed to the admin? Okay, about a third. And who who would prefer like the admin? Okay, a little more for the admin. But the Django shell, again, right? It's like, you know, for some of us here, it's like, why is Django complicated for people? It's like, here's another choose your own adventure. So Python comes with an interactive interpreter shell for simple commands, and Django has its own version that loads in the Django

Speaker 1: configuration environment and is set up properly. So some tutorials, including the polls tutorial, dive into the shell right away. Personally, I think that loses a lot of people and I would recommend a mix of visual through the admin and the shell. But as you become more comfortable with Django, I use the shell a lot now, especially around around query sets. If you don't know, you should use Django Extensions, which is a third-party package that loads, has Shell Plus that automatically imports your model. your models because that is super annoying to have to do. So I would almost say Django extensions is a top five third-party package. Okay, ORM query sets. So this is the heart of Django. I kind of already covered this, but essentially we want to write Python, our database wants SQL, and we want it to just work.

Speaker 1: And that's how the ORM does it. A query set is we can apply logic and essentially filter it in some way. So this is what I think most Django professionals spend their time on is the query sets. is optimizing these, sorting out, you can chain query sets together. You learn things like query sets are lazy, so they won't be executed until they hit the database. So you can stack them all day long, seems fine. Then you run it and go, ah, I got got a thousand queries on my page, why is it slow? So there's common methods, getAll filter. A whole talk we could do on that, but that's the quick take on the Django ORM in query sets. Yeah, and query sets are something like maybe my next talk should be on query sets because I find them so cool, but they

Speaker 1: they're not cool to beginners from my experience. Testing, you should have tests, right? I think people know that. Um Django comes, so Python comes with unit test. Django has Django test test case, which is a subclass of unit test test case. So it basically adds on some web-related Tests you can do. There'll be a test. py file when you create a new app. You should use it. I'm curious again who prefers PyTest in this room? If you could raise your hand. And who uses just Django uh test case? What what what what do you guys use instead of PyTest if you don't use Django? Oh prefers, I'm sorry. Okay, prefers. Yeah. So it's

Speaker 1: you can do a mix, but um it's not universal to use to not to use PyTest as opposed to the default Django testing. Like I may be, I personally am not a huge PyTest fan, but um that's another somewhat religious debate. But um code without tests is broken, so you should have tests. Okay, we're almost done, I swear, with this sec with this section. Um so other goodies, messages. There's a whole built-in framework to add messages, especially around forms. So user tries to submit something and it works or doesn't. Django's got you covered. You can loop it into Bootstrap and other CSS frameworks. Um should definitely use messages. Signals. This is a way to be notified when something occurs elsewhere in the framework.

Speaker 1: There's senders receivers, there's whole talks on this, but it's useful when, again, multiple pieces of code interested in the same event. So a good example would be sending email. That would probably be the most common example where we'd want to use a signal. I would say signals are They're really enticing when you learn about them. They can be very easily abused. And I think Carlton Gibson would agree that they're often abused. So use signals if you have to, but be aware that they can be abused. Um internationalization localization. It's fantastic that Django has this. And you can Translate in different languages, time zones, uh format dates. Um many sites may not need this, but many sites will.

Speaker 1: This is a key f component of Django and in some ways, especially in the you know in the United States and English speaking parts, not I think fully appreciated. Geo Django. You can do Geographic web framework, you can do maps, you can do all sorts of crazy things, spatially enabled data. Personally, I know very little about Geo Django. Like there's just so much to Django itself to learn, but that is a huge area if you need to do things with maps that Django has you covered. And then finally async. This is so asynchronous. This is slowly being added to Django with in 3. 0, ASGI. py, 3. 1, views and middleware, somewhat. 4. 0, the cache progress on that, and the most recent 4. 1 um class-based views in the ORM.

Speaker 1: This is a longer-term goal of Django, but having the ability to support both synchronous and asynchronous is important to modern frameworks and Django is working on it and um async gets a little wonky quickly. Carlton Gibson has a talk on it later. Later this conference I recommend you check out. So lastly, APIs. So how all thinking thinking of all the things we've covered in practice, I would say most professional developers are doing APIs. So not even using templates, not doing most people they're not doing full sites. They're part of a larger team. They're kicking off APIs. Um Django S framework is is the most popular third party package for Django. We do um surveys on this periodically. And Is essentially part of Django itself.

Speaker 1: So you can combine it to serialize your data, have API endpoints, and that's useful if you want to have a mobile app, iOS, or Android. You could also have a dedicated JavaScript front end. It's somewhat interesting that I think things are the pendulum is moving from you know from server-side templates over to React. Um it's moving back a bit with technologies like HTMX. Um Sort of like jQuery where you can use service um server rendered templates. Um but APIs, yeah. Uh It's it's you know it's it's like 45 minutes is a long time for you to hear me talk, so I appreciate you sitting through it, but it's also like I kind of need like 450 minutes to do any justice to any of these topics. So I recognize that, but I'm trying to just skim across and go, yep, this area, this area, this area.

Speaker 1: Okay, deployment. Can I just ask, how am I doing on time? Sorry. Oh no. Yeah, you probably showed them. Okay, all right, I'll go faster. Um so this is something that's uh tricky that we have our local computer and we want to uh local website we want to put online. Django defaults to uh local settings. So it's easily like 80 pages in a book to just show someone how to do this in a not completely insecure fashion. And it used to be that you'd use multiple settings files. Now there's uh let me skip. Production server. So we're gonna swap out our local Django server for most likely GUnicorn or U Whiskey. Um the Django server is

Speaker 1: Not made for production, so don't use it. You can pip install and point your your proc file or your Docker files. So production server, environment variables. This is my uh preferred way to swap between local and production. Um so you can have a single settings file and then load in different environment variables depending on what you want to run. This would be if you want there's multiple packages for environment variables. There's no default support. Something else that could be addressed in the future. This would if you use the environs package, which I like, this would be how you'd set it up and you would swap at a minimum the secret key debug allowed host and CSRF trusted origins. Production databases, this is how you do it with DJ

Speaker 1: database URL, which is very handy. Just flipping through static files in production, a whole nest, you're gonna need white noise, most likely. Uh you're gonna need to update your settings. So static URL is the is the URL location of where things are Our storage stacks tells us Django where to look. Static root is the actual folder when we run the collect static command. So that's a Django command to compile all the static files from all across your site into one place that you can deploy. And then static file storage is implicitly set. If you want to use something like white noise, you would update it here. Okay, media files, user uploaded. You're gonna need to create a media directory, update your settings files. You Don't want to store these on your computer.

Speaker 1: You want to use something like Django Packages, which is a third-party package, and store it on an S3 bucket or elsewhere because you can't trust users at all and they may submit nefarious things. Um performance for performance in in three seconds. This is what you want. This is the 80-20 rule. I think these four things will get you most of the way there. Um so you can optimize your your query sets, caching and indexes. These things can be abused, and I would highly recommend not Doing any of this until you actually deploy your site, because you can always change it uh in production in the real world, it's very tempting to uh perfect it in advance. Okay, finishing up. Security, run this Django deployment checklist. It'll give you a whole list of things that you need to do before you can deploy, especially around HTTPS. One quick one, your

Speaker 1: admin. It defaults to slash admin. Change that. Okay, last slide. Community. This is, you know, uh come for the framework, stay for the community. So there's so many people , many of whom are are here at this conference who do invisible things that make Django what it is beyond just the code. There's the official docs which are updated and maintains. There's a translation team. There's a Django forum you can use, forum Django Project. com. Third party packages, you can go to DjangoPackages. org to see that. Events like DjangoCons where we can all meet. Django Khan US Europe, there's plans for Africa, there have been past events in Australia and Japan. Maybe my single ad advice would be all the DjangoCon talks are posted online. Like if you if you're intermediate and up and you want to learn Django, like watch all of them.

Speaker 1: Like really actually watch all of them. That's probably where I learn the most at this stage in my career. There's a board, nominations are open. Talk to me next year. Promise. Django fellows, these are the two paid employees who make Django It is. They're both here. They do incredible work. Um the framework would not work without them. And finally, I do want to call out Catherine Holmes, who's here. She's the Django Software Foundation assistant. She works with DEFA. She is the glue that makes a lot of the Django community work, and she does it invisibly. She works with me in the treasurer role. I'm going to give her a shout out. Okay, thank you. I assume there's no time for questions? Yeah.

Speaker 1: Um

Speaker 2: do if do we have any questions in the audience? Uh

Speaker 3: yeah, so I guess the this is just kind of a like long-term lingering question. So how do you think about drawing divisions between apps within Django when they've got like shared model, shared functionality, et cetera.

Speaker 1: Sorry to say, can you be more specific? Like how do I Uh

Speaker 3: so like you'd say you've got like, you know, you've your basic user functionality, then you've got various other functionality that builds on top of that. How do you think about drawing like how do you choose when to split things out from a single app that has all of your functionality into Two more specific ones. Uh just like kind of a generic where do you draw like a boundaries.

Speaker 1: When it feels painful, take action. I th that I mean that is my rule of thumb is that I don't you don't I don't wanna necess just like have twenty small apps to start. Like when something gets Clue, that's when I would split it out. I mean you want to focus on what is specific to the user. So like what's a user profile thing, what um I'd love to talk to you more offline directly about it, but generally I would say wait until you feel the pain and then factor would be my default answer.

Speaker 2: And we have about a minute left if we have any more questions in the audience.

Speaker 4: Yeah, can you talk about that white noise uh and why you prefer it for serving static files?

Speaker 1: I think it's pretty much a default in the community um because it will Just do a bunch of things that the Django um static files uh compression engine won't on its own. Um Uh that's the that's the quick and dirty answer. I mean I've yet to see someone who doesn't use white noise for production because just in the way it packages it and compresses things, it's it's more advanced than the Django defaults. Um so Maybe someone doesn't use white noise. Yeah? U whiskey uh U whisky search static problem is Yeah, so it depends. I guess if it it depends if you're using a platform as a service, you're on servers. UWISG, so I'm I'm a G Unicorn fan, so I don't that's a blind spot for me. So you don't have to. I think a lot of people do use white noise, though.

Speaker 1: Again, it's just an extra step beyond what's built in. But static files are tricky. They're a total mess. It used it, I mean it compresses them differently and better for production. I mean that would be the big reason. The honest answer is I'm not a white noise expert. So even for me, it's one of those areas I'm like, yep, check that box and move on.

Speaker 2: All right, well if I can have one more round of applause for our speaker, well.

Speaker 1: Thank you, everyone.