Transcript: Third Party Packages

I'm Will Vincent, joined by Carlton Gibson.

Hello.

So to start things off, um why do we have third-party packages, Carlton?

Why would you say?

You know, Django is a batteries-included framework.

It comes with a lot out of the box.

Why not have everything in the box?

And for m 80% of projects, they wouldn't need 80% of the functionality.

So batteries included is it's the 80% case.

Almost every project should need everything that comes with the core framework.

And then in order to keep it maintainable, but also to keep it relevant, extra functionality lives outside the core.

Partly because Django, with its projects and app structure, lends itself quite well to separating out functionality for these things.

So if you build it for yourself, you can make it available to other developers, and then you know, can be community projects.

So now we've got 10-year history of people being encouraged to build third-party apps and then building third-party apps and making them available.

And so there are just there's so many.

Almost everything you can think of, there's a good app out there that does it, or there's one that's at least good good enough for you to think use as a kind of um inspiration to copy it in your own project.

I I think it's often it's a great way to learn if you're to if it doesn't do exactly what you want, to look and see how someone implemented functionality.

Because again, with the web, almost nothing is unique.

Um it's someone's had the problem and tackled it before.

And um

Um, because what can happen is you install a third-party app and it works great, and that's fine, but it doesn't get updated.

And over time, then when you want to upgrade Django, you can't upgrade Django because you're tied to this third-party app.

So just just vet them before you install them.

I mean, in the weight of, you know, how do you know something's active?

I would say it should have a fair number of stars, so probably a couple hundred.

Um, and you should see some action within the last three to six months, if not daily.

But Django appconf, which is a um uh a package I maintained, it's used by Django Compressor and and a few other um applications.

But it I this week I released um a new version which just changed the um packaging metadata to say it supports Python 3.7 and the latest Djangos and things like this, but it hadn't been updated for two years, but it had zero issues and zero pull requests.

Yeah, fair enough.

But anyways, all the packages we're gonna talk about today are vetted, and so if they're what you need, um you should feel as comfortable as one can using them.

Um and we should note we're not gonna be so there's also what's a third-party app?

There are additional things like Wagtail, Django CMS, which um I guess they're technically apps, but they're really more like

So we're not

Oh wow.

You know,

Um so let's let's start right at the top.

I mean, I think everyone would agree the number one third-party package, and most people probably don't know that it's a third-party package, um, is Django REST Framework, which is how one builds RESTful APIs with Django.

It is what the majority of uh Django, professional Django developers, I would say, use when they use Django.

Um, and yet it is not part of Django Core, which you know, you're a co-maintainer on it, so perhaps you can speak to why it's not part of Django itself.

Um to create JSON responses was, you know, there's a JSON response class, and then there was a um uh a package called Tasty Pie, which um enabled you to do uh RESTful APIs, which was a third-party package and then come long came REST framework, and it was never it was just it just is was built as a third-party package and it survived as a third-party package and it continues to this day.

Um but it's yeah, I mean for me, Django, Django Rest framework, right?

Now what else do I need?

So it's um that's probably the number one third-party app that everyone will use.

Um and we will we'll do an entire episode or episodes on on it.

It has its own third-party packages um that we're not gonna talk about today.

Yeah, but that's um, you know, another big one.

So we'll actually in in the in the news is Django channels, um, because you've um you've taken on a new role with this, right, Carlton?

Um, so hopefully that gives him a bit of capacity to work on bringing async support into Django Core itself.

Um, but he stepped back from the maintaining maintenance role in Django channels, and I've stepped up to do that with a couple of other people.

So we're just keeping that ticking over.

But that gives async support to right.

If you want a WebSocket thing, then Django channels is the way to go.

But also if you want to build async applications using Django, you can do that right now with channels, and then we'll see what happens with the work that Andrew comes in perhaps over the next six or twelve months.

We'll start seeing how Django itself will provide support for async gold.

But Django channel, if you want WebSockets, Django channels.

Um moving on.

So I would say the one that I use on every project is Django debug toolbar, which is a way to view your your requests so to see how efficient you know your your blog list is.

This is a small one.

Um it's I can't think of why you wouldn't want it on every every project.

This is just super, lets you view your SQL requests, lets you I I know you can and you can create plugins for it.

If you want to view extra bits and bobs, you can um

So both to you know hop into well, your own project or a new project and see yeah, that what is the template structure, and especially for performance, you can really see um you know how many queries are involved.

So that's a that's really a must-have.

I can't think of a project I've worked on that didn't have that.

Um another one is that I especially like is uh Django extensions, which is a way it's a it's a several tools, but the really nice one is you can add um uh what is it, plus, right?

So you can do Python run server plus.

So if you want to go into the Django shell, it will automatically preload all the things that you'll need.

Um it has a whole bunch of it, it's really a Swiss Army knife of sort of additional tools that as you become more experienced with Django are just really nice to have.

And you you can edit that and you can it's one I use a lot.

So Django extensions, super.

I should I should look into that.

Um well what which ones do you have?

We we've got a list of things.

So, you know, if I I put in you know size equal size equals I don't know bit large and I want to filter my query set, well you don't just want to expose that raw user input and then feed it into the ORM because that's dangerous.

So Django filter will create a form which will then validate that the the value was sensible, it will then take a fit a quilter set and it will filter it, and you can create these, you can very easily and very declaratively create filter sets for um your models which enable you to filter by the parameters that you want and you can filter across relationships and things like this, and then and Django filter integrates with Django itself, but also with Django REST framework too.

So it enables you to create very easily filterable endpoints on your APIs, which is kind of cool.

So, you know, I want to I well I've got a list of blog posts, I want to filter by those that are tag Django, easy peasy.

Yeah, and that's I mean that's a separate you know security thing around just with for example, you sort of alluded to it with URLs, you know, why you'd often probably don't want to include the primary key um, you know, for blog posts, because it'll give away the number of blogs that you have, right?

Like you would use a a you UUID or you could slugify it.

I d uh so Oh I

don't I don't know.

And it can and it's reversible and that that's great, but it's it's that's slightly longer than one, two, three, ten, yeah,

Yeah, I mean, you know, in slugs, the problem with slugs, if people haven't experienced this, is you know, what do you do if you know your URL structure is you know mywebsite.com slash blog slash the name, and I write one called Hello World, and then Carlton writes one called Hello World.

They can't exist at the same URL, URL endpoint, so you have to deal with um the complex collisions of that sort.

So that's why um so

So you put a um in the URL you might have 2019 for February, and then you might have a slug which is unique for that month, and then it's like it's not unique forever, but uh only one that month.

And I I kind of quite like using that sometimes.

And that's an option on model fields.

You can if you've got a date time field on the model, you can give unique for month and say it has to be unique on reference to this date time field.

I mean, there's also uh an argument around not putting the uh you know, not time stamping things in the URL.

Lots of people don't like that.

There's no harm then that being grouped by month or by year or yep.

Anyway, um so what else do I like?

I I like Django Watson, which is um a super package uh which enables you to um make use of your database's text searching features.

Um it's slightly perhaps viewed as slightly out of date now because Django has got more uh full text search features built in, but Django Watson is is very good and worth looking at, and it supports all the different backends.

Oh great.

Well, it's great.

So you might say filter by a tag, then search for a string, and then filter again by you know publish this, whatever you wanted to, but it it's it's super um Django Watson, that's called.

The other one by the same uh author is called um Django Reversion, and this enables you to keep um model histories of your models.

So say you've got um blog posts and you wanted to be able to go back in history um and say, Oh well, I've edited it and then it's been edited again, it's been edited again.

But actually, the version two ago two hours ago, I need to go and look at again.

Django reversion lets you do that.

That'd be very useful.

Well, another one, a next on our list that I really like um is called Django Alloth, which is what you would use for authentication.

Again, because the the challenge is that Django does not come with a built-in um user registration signup form.

Um so there's a couple of packages out there.

I like Django Alloth the best.

It does, I guess, two things.

One is it enables social authentication.

So if you want to add Google, Facebook, Twitter, um, it's very straightforward to do that.

The other is that it provides a whole ton of um customizable features.

You can swap in email instead of um username.

Um additional settings.

So, you know, it's it is a third-party package, so you know, like for example, with email, this is a common, common one.

The Django default is to have username, email, password, which is a little bit outdated right now.

Um more common on websites is to have login or sign up be with um email and password.

So you can do that yourself.

You need to dive in and um use the model managers, which is a little bit of an advanced feature for people.

Or you can, if you know that you need social or you want some of these additional features, you can just use Django All Auth and it's um a bit faster to get up and going.

So in my my first book, Django for Beginners, I show how to do, I we use Django Alloth in some of the later chapters.

Um and I think in my my new book, I'm gonna show, for the example, with email, I'm gonna show how to do it with model managers.

But we're gonna end up using Django All Auth because if you do want to have social authentication, which a lot of people do, um, it's a great way to do it and not have to roll your own solution.

So, you know, if you've got Twitter login and you want to add Twitter features to your website, you've got the the right credential to then rec make user requests of the Twitter API on the user's

You can you can see in the admin.

I mean all that auth stuff is is is a bit of a minefield.

You really don't want to roll

One thing I was I was gonna say about OAuth was that it needs a decent a better tutorial because it is quite opaque, but then you've just said it's in your book.

I there you are.

There's one of course there is one, you know, there was one from I think four or five years ago called the missing all auth tutorial.

Yeah, do a Google search for Django All Auth tutorial, see what comes up.

Right, okay, because

I get frustrated and I write it up.

And it is a package that I use, and uh I was thinking, well, it needs tutorials, but of course you've written one already, well then.

And um you know, as I sort of mentioned with Django Alloth, you know, I've gone full circle on it where I, you know, I didn't I didn't initially know how to, you know, years ago how to do email instead of username.

I found Django Alloth, I sort of you know clued together how to do it, and then I wanted and sort of learned how to do it the raw way, and now most cases I use Django Alloth um because I understand what's doing and it's managing the complexity, but it's a bit of a a circle in the same way.

Um, you know, I would say generic class-based views are versus function-based views.

If you if you need to send a user notifications, they want to say, look, I want notifications to this email address, not that one.

And it enables them to add multiple email addresses and choose which one's their primary and things like that.

So it's what something that I like about it.

Anyway, we should move on.

All right, moving on.

Um, so we have ones for deployment, which are or static files, which is uh static files, yeah.

Yeah, so white noise.

Do you want to talk about that?

So there's two strategies here.

Static files can be a pain.

So the the white noise uh

But let's explain.

You want them on a CDN for performance reasons.

Yeah, yes.

Um the thing is you can have that within Django.

I I don't I sort of go I go progressively with it.

Right.

And so they've get they've got this little if debug that we've all use.

And that's perfect, but you can't use that in um in development.

So then white noise comes along and it gives you a view which will serve your static files and it adds the right caching headers and it does all these nice things for you.

That's so that's one strategy sets called white noise, and then the other option is Django storages, which if you want to put your static files on S3 or as your storages or Google Blob Store, you it gives you the tools to do those.

Um, another big one.

Those are ones use all the time.

Um environment variables.

Uh this is something you should use in your projects.

And Django Environ is sort of the default.

Well, that yeah, there's also.env, but Django Environ is sort of managing your environment variables.

Do you want to add I don't know I'm blanking here on how to explain the package properly, other than it helps you manage your environment variables?

It helps you control your environment.

We want to keep we want to use um, we want to do the right thing and not put uh environment sensitive variables into our um into our settings files so we keep them in the environment, but then we've got to remember that we need to export them into the the um the calling process before we can launch Django, it's all a pain.

Django Environment help you manage.

And you don't want to put that in source control.

For example, like your your secret key or your um you know your Stripe ID if you're using payments

Yeah, or your database, you know, your database.

Yeah, yeah.

Um what's it called?

IAM access key thing.

Like yeah, you need to keep that secret, so environment variables for that.

Um okay, fine, we'll skip on that one.

Um Django Guardian is another nice one.

So if you wanted to do so, Django has a nice permissions system, um, permissions um system, which by default the Django Control.auth permissions will say, yes, you can access blog posts, yes, you can access um, I don't know, uh the the the sales catalog.

But if you want to restrict object um access to individual objects, then um Django Guardian will help you do that.

So you can create object permissions for this specific blog post or this specific um item in the sales catalog.

Uh and that's that's a useful addition.

Um Django doesn't provide that.

And um that's a again, every project you're doing that.

So another one that well I'll t I'll tee this up.

Uh Django Compressor is one I really like that you maintain, which is for compressing your uh static files.

Yeah.

So it's so that's uh you shouldn't do that.

And what you you do is you just create a uh template block which has got you with the compressed tag, and then you put your script tags in them as normal.

So you might put your your or your link tags for your CSS or your script tags for your JavaScript, but you give them a special media type, um, which will be like for SaaS, so content uh style sheets slash SAS, and then when it sees that, it will run it through the process pre preprocessor and convert your SAS into CSS so that you can load it straight into the browser.

And in development, it keeps them separate so that you can trace it back to the individual style sheets.

But then for production, you run a compressed command and it compiles them all into one file, and you can minimize them and you can gzip them and you can run it whatever pipeline you want to, and then it puts them into the static um static files folders for white noise or Django storages to deploy, and job done.

And it's pretty.

Yeah, and so anyway, I I really love that.

And I'm not a front-end developer.

And so if I work in a you know a team where there's a a prop a you know professional front-end developer, they they will replace Django Compressor with their own build system and their own whatever and we'll work out the deployment.

But for me, as a Django developer, I can do something that's semi-respectable, quite more than semi-respectable, just using Django Compressor.

And then when people need to go that bridge further, they they can do that.

No, it's a really nice op uh optimization.

You know, maybe so one more, this is sort of a fun one.

Um, Django admin honeypot.

So a best practice is that um one will notice that every Django site has the admin at slash admin.

So if you were a malicious actor, you could write a script and find out if a site was a Django site, and then you could try to hack it.

Um there's a couple ways you can safeguard that.

Number one is um change the URL.

So don't change don't have admin at admin.

Um Django admin honeypot lets you see people trying to break into your admin.

Um so it's a you know it's sort of a fun one.

It's a good reminder that you should harden your admin.

Um there's actually a number of steps to do on that.

But that's sort of a fun one if you want to see someone in particular trying to break in your site versus just random bots or on the internet.

Brilliant.

All right, okay.

Well, that's a whole long list, right?

Um but uh check the show notes for more on those.

This is a just a quick run through of our favorites.

There are, as we said, millions or thousands of others.

Um, there's a group on um GitHub called Jazz Band, which maintain a whole group.

And so the the danger with a third-party app is it's difficult to maintain over time.

And so Jazz Band take on packages which need help maintenance, and then they maintain them as a group, and so they keep these packages going and they're lively.

So anything in Jazz Band you can rely on as being well maintained.

Check out Django packages, as Will said.

You can do that at DjangoChat.com.

There's a way to contact us.

We're also on Chat Django, and we'll see you in the next episode.

Okay, bye bye.