Transcript: Django REST Framework (Ep5 Replay)

Hi, and welcome to another episode of Django Chat.

I'm Carlton Gibson, and I'm here with Will Vincent.

Hi.

Today, we're going to talk about Django REST Framework,

one of the main third-party add-ons in the Django ecosystem,

and the main one that you'll use for building APIs with Django.

Yeah, and as we've discussed previously,

I would say the number one third-party application you're likely to use.

So as you mentioned, it's how one builds APIs.

So we're going to talk about why you would do that

and get into the specifics of Django REST framework.

To keep it simple, like we've introduced this term API,

what's an API?

So an API, it stands for Application Programming Interface,

which isn't that helpful.

But I think of it as the way in which two computers talk to one another.

And the key difference between a website,

A traditional website has all sorts of things.

It has HTML, CSS, JavaScript, all working together within Django to give you a web page.

An API is just the data.

So you often have to combine that data with those other HTML, CSS attributes.

But why don't you give it a shot?

I don't think that's the clearest explanation.

Okay, well, so the way I got into APIs was building normal websites.

and then i was using web forms and then i wanted to create a fancier form that used ajax to to to

submit the data and update the page without doing a full page refresh so you would encode form data

in json send it off to this server the server would give you back some other json and then

you'd use a bit of javascript to put it back into the dom and then from there the other the other

big thing that came up was mobile applications which aren't necessarily web-based and so they

They want to talk to a server, but they send off JSON.

Normally JSON, it can be any encoded format, but they send off JSON, they get JSON response

back, and then they use that to update their user interface some way.

So it's like, as you said, a data-only communication between the server and the client.

Right, yeah.

And I think that, you know, to repeat what you've said, if you want to work with a front-end

framework, so something like React or Vue or Angular, you'll be better served to use an API

internally, but you can also use an API to talk to multiple clients. So the example I like to give

is with Instagram. Instagram is one database that has an iOS app, an Android app, and a web app.

So how do three clients talk to one database? With traditional Django, you can't do that. It's

more all in one box. But if you create an API, and in that case, it would be an internal API,

so an API only that Instagram programmers or applications can use, they can all speak to

one another. And you can have multiple clients, multiple front end interfaces with one code base.

And this is really the direction that most websites are going these days. You can start

with just traditional Django, but as soon as you want mobile, or as soon as you want to add these

front-end frameworks to your own application, you're probably going to switch to an API.

Yeah, that sounds about right. So if you want to build an API with Django,

what are you going to use? You're going to use Django REST framework.

Today, you're going to use Django REST framework, yes.

Right. So what's REST about? What's the REST? We know what Django is, and we know what a

framework is. Django is a framework. It's a framework, it's a toolkit. But what's REST about?

Right. So REST, here's another acronym, Representational State Transfer,

which I don't, just like application programming interface, I don't think is that helpful.

It is an architecture style only from the year 2000. Roy Fielding did it as his dissertation.

It's basically a set of rules or suggestions for how to structure an API. So there's some

continuity to it. There's, and really what it does is it makes you learn HTTP,

hypertext transfer protocol. That's the thing that goes at the beginning of URLs, right?

That's right. That's right. HTTP. Yeah, I look up in your browser and you'll see HTTP or probably

HTTPS. The S stands for the encrypted version. So because we're on the web, you can build APIs for

any, you know, anywhere. But because we're in a web context, we're using HTTP, which is the way

that information is sent back and forth. And REST has a number of properties that make something

RESTful or not. So that would be there's a client server relationship, which is what you have on the

web, a database talking to a user. It is stateless, which there's much we could say about that. So

each request is independent, which means that it's okay if a message doesn't get all the way

through, but it makes it harder to know things like, is someone logged in or has something

changed to a shopping cart? Dealing with state is really probably the fundamental challenge,

I would say, of the modern web. It's cacheable, uniform interface. There's really a whole list

of restful things. But generally, you know, and I guess I would add on top of that, when you're

using it, you're, so if you think of a web page, a web page just gives you the HTML, CSS, JavaScript,

you have a, what's called an API endpoint. So it's also a URL. And it'll be something like,

you know, so instead of google.com, it'd be api.google.com. And at that endpoint, you can

use http verbs or excuse me method well methods verbs same thing um such as get post push put

delete right verbs here like these this is the key point for me is like all the other stuff the

stateless and whether yeah it's kind of interesting but the key point for me is that the the http

how many t's was that the http verbs correspond to the methods of crud basic as normally understood

So you get to retrieve a resource, you can post or put to create or update, you can delete.

And these HTTP verbs say how you use it.

So each resource will have a URL unique for that resource.

And then the action that you perform will depend on which HTTP verb you use.

Yeah, and I mean, you know, I'd like to do a separate episode just on CRUD, because I

feel like CRUD, which stands for create, read, update, delete, is something that web developers

internalize quickly and understand. But if you ask an average person or you explain to them that

every site basically just has crud with authentication, you'll kind of blow their

mind. I think because if you really, you can say to them, let's look at Twitter, let's look at

Facebook, let's look at Instagram, Pinterest, Google. It's the same thing over and over again.

That's a real aha moment for people. And so if you, once you start building APIs, you will get

that. Even with traditional Django, a lot of that is handled for you. So you might not necessarily

know about HTTP. You might not know about these verbs. It's really when you build an API that

it will become real to you. Okay, fine. I mean, you know, that's all very abstract. But what does

Django REST framework give us, DRF? What does DRF give us? Right. So Django, Django REST framework.

So Django, you build a website and you say, right, I want an API. Django REST framework's

third-party package so you can easily install it. And because it intentionally mimics Django

conventions, it will transform a traditional site into an API for you with a tiny amount of code,

largely through something called a serializer, which I think of as really the magic, which will

transform instead of sending a web page back and forth, it will send just data typically in the

form of json so i think serializers is the number one thing that's along with http that differentiates

an api from a website and that people need to understand you know what a serializer is and how

it does what it does because django rest framework really just kind of magically transforms your site

into an api but it's doing that largely through the serializer yeah and the generic views as well

so if you want to create a view which just retrieves an object there's a retrieve api view

And if you want to create an object, there's a create API view.

And if you want to update an object, there's an update API view.

And then there's generic views, which are create, retrieve API view, like combine these.

Yeah, very similar, you know, intentionally similar to Django's generic class-based views,

which is why I recommend people start with Django and then Django REST framework.

in the same way that building an API,

you shouldn't build a website first

because Django REST framework, you'll appreciate it more.

It'll make more sense.

You'll see that it's built upon Django itself.

So I definitely recommend

building a couple if someone says to you your boss says to you go build an api with django s

framework build a build a site or two in django first and then you will see that you can quickly

add on an api but it will make a lot more sense within the context of you know this is all meant

to be very django like in terms of its structure yeah and i think this the basic structure of drf

is you take the model which you've which you've got and you're very familiar with from your

building your normal django site so you've got a model and then you create a model serializer and

then it's basic all you have to do is declare which model it uses and it will automatically

create all the right fields for you and then on top of that you just put a view in place

and then the framework bit of Django REST framework it does all the rest it handles encoding

the model data into JSON for you it handles parsing incoming JSON data if you have a post view

so it's just super for that reason yeah and you still have the URLs right so the so you have your

model you have your urls and then and you have views for a traditional django site we also would

have templates there's no templates with django rest framework because we're dealing just with

data the difference is instead of templates you have serializers and the views are a little bit

different but the models are basically the same and your urls are the same that relies on django

itself so it's really the serializers and the views which are different yeah i mean and under

the hood there's these things called renderers but the users normally you would just never get

there you tell it that you want to support json and it would use a json renderer and unless you're

getting right into the advanced stuff you never need to see that layer that's what's super yeah

so just just like django you really you can get it and use it and then if you need to go deep you can

but you don't have to right off the bat um we should mention i mean you are a core maintainer

of django rest framework so you know that of which you speak right certainly more so than i do yeah

well i got into it long time long time ago so um i was building uh ios apps um for in a freelance

environment and agency environment and um clients needed not only an app they needed an api to go

they need something for the for the mobile application to talk to and i knew django and so

i was like well i can build the back end and looking for something at all which enabled me

to build apis with django and django rest framework popped up and this was version one days and then i

was following it along and using it and tom christy who was the creator of django rest framework he

came on the mailing list one day and he's like look i need help there's there's too many issues

to triage there's too many questions on stackoverflow the mailing list is too hard so i got

on to the mailing list i got onto stackoverflow and i started answering questions and helping out

and all of a sudden tom's like oh you know you're here you can be a maintainer on the framework and

I'm closing tickets and merging pull requests and that's all, you know, and that was, that was how

I got started in open source was I was using Django, I was using Django and Django rest framework

and Tom needed help. And I just, I just chipped in, you know, I just did my bit.

Yeah. Yeah. Well, and it's interesting cause you, that you got it, you know, cause you're

currently a Django fellow as well, but you got into the Django world through Django rest framework.

Yeah, entirely. You know, I needed to build APIs, and Django REST Framework was and is just a super way of doing that.

Yeah. And I think if you've built APIs with other ways, with other frameworks, and then you try Django REST framework, you'll see how fantastic it is. If you just use it, you'll go, oh, API is not so bad. You know, standard functionality. You know, it's really, I don't know how much, you know, there's a benefit in learning how other things are harder.

But Django REST Framework is about as easy as it gets these days to build a powerful, secure website, excuse me, web API with a minimum of code.

I haven't seen really anything that comes close.

Maybe Ruby on Rails, but maybe.

I mean, we get spoiled, I think.

If we just start with Django and Django REST Framework, we think that's the norm.

And then when something's difficult, we complain, oh, this is hard.

Well, yeah, but if you try doing this with another framework.

Yeah.

Yeah. So what else does people need to know? So authentication is a big one as well with APIs.

And I actually did a DjangoCon talk we'll link to all about this, which was actually where you and

I met in person for the first time, I think. We'd spoken online. So with authentication,

so Django itself and most web frameworks use sessions where you have an ID that is created

for the user and then stored on the server.

I'll link to the docs on that.

We'll probably do an entire episode on authentication.

When you're dealing with an API,

you can also use tokens

as well as JavaScript web tokens.

So instead of passing a session object back and forth,

you're passing a token.

There's a whole number of ways to do this.

And again, the talk I go through

and I give full examples of the main ways

to do that within Django.

But this is a big sticking point for people.

I think after understanding serializers, authentication is what really hits people because you have to understand how HTTP works to understand authentication.

Which is that HTTP, and please correct me on this, but HTTP contains header, body, and a message typically.

And the header is where the information like authentication is included because that is passed with every request.

because HTTP is stateless, you have to include it. Otherwise, you can't be sure that someone is

who they say they are. Yeah. So how do I know that this HTTP request, which has nothing to do with

the previous one, is from the same person? Well, it's because they have the same token or the same

identifying feature. It could be a cookie. It could be a token, as you said, of some kind.

And that's the key, right?

It is HTTP.

The underlying protocol is stateless.

So it has no concept of a session.

So we have to put this on top of it.

Right, so just because you log in on the login page and then you're taken to the homepage,

the site doesn't know that you then can reload it, for example.

Yeah, it's exactly the same with a traditional Django application.

You have to have that cookie.

You have to log in and the backend sets the cookie for the next request to know it's you.

What I would say that if you're using an API to augment your website,

so like you're doing it in that example that I gave at the beginning of enhancing a form submission with AJAX

or anything where they're in the browser, just use SessionAuth,

the same as the default SessionAuth, the same cookie authentication that you always have in the browser.

And then if you need some other client to come along, that's when you need to go to one of the token methods,

be it JWT or OAuth tokens of some kind.

And be aware that it can be very complex.

Yeah.

And there's like a dozen third-party ways to do it.

If you go to the official page,

there's a reason why there's tons and tons of pages to do this,

partly because the technology around this is a changing space

with JavaScript web tokens and other in OAuth for social authentication.

so it's unfortunately it's a bit complex right now for everyone yeah i think that's the key point is

it is complex and when you get into authentication for multiple clients you just have to be prepared

to spend the time to do it properly and to understand what's going on and to dot the i's

and cross the t's yeah and you don't want to get authentication wrong well no right because

yeah uh so what else another key point when you're learning about apis and

REST, Django REST framework is the concept of CORS, C-O-R-S, cross-origin resource sharing,

which is a fundamental security feature of the web. It basically means that you can't by default

make cross-domain requests. So if I'm on site A.com, it won't by default let things come from

site B.com because that would be a way for a hacker to basically take over your website. So

you have to explicitly give permission, which you do through cores. So when you're setting up your

API, that can often live on a different server than your front end. So you need to specifically

say, this front end can access my back end API. If you don't set that, it won't work. It's a small

thing, but it's something people may not have thought about if they're just coming from a web

framework world where that's sort of handled for them. Yeah, and there's a third party package to

help with that, right?

Yes, yes.

Django, of course,

which we'll link to.

Maintained by Adam Johnson

who's a core contributor

and...

Yeah, you have to use that with Django REST

framework. Yeah, so the example

is right. You've got app.myproduct.com

and then you've got api.myproduct.com

and app.myproduct.com

wants to talk to the API. It can't do that

without setting the right

headers, the right course. Right, and again, this

is understanding HTTP where headers

is this, it's almost like the metadata

on a normal page where

you go into view source and you

see meta, the title is in there and the

author and maybe some other stuff.

It's sort of secret information that's really important, I would say.

Documentation.

What to say about this, Carlton?

Because an API, you need to have a roadmap so someone can understand how to use it.

And you don't necessarily need this with a traditional website.

People just click around.

But an API, because it's for another developer, you want, for example, if you're building

a Django REST framework backend, and then there's a front-end engineer who's someone

else who's going to be consuming it, you need to tell them what's what.

Yeah, what parameters are available, what endpoints are available, what HTTP verbs are

allowed, what methods are allowed.

All of these things need detailing.

And back in the day, there was this idea that they would be hypermedia APIs, that they'd

be self-discoverable and self-describing.

And whilst that's a noble dream, it hasn't appeared.

um we're left with well how can i describe it we're left with apis which each one is kind of

slightly bespoke and patterns like rest and let them be familiar and let let them be largely

similar but there is no there's no automatic way of learning about an api you have to open up the

documentation and look at it and read and write your client for it so django rest framework introduced

some documentation so the ability from serializers to generate api documentation

that's all in flux now because over the years what's emerged is probably the standard is a

thing called open api which used to be called swagger and there's lots of tooling and this is

this is this there are other options out there but this is the key one that's got most of the

mind share and to be honest at this point that's the one we need to integrate with so we're moving

from what was um a tool which was called core api to open api and we're in the process of doing that

right now and we can generate an open api schema now and that will improve and but the inbuilt docs

which were built into janga rest framework now they are based on open api and in the next version

3.10 they will be deprecated and there's another tool called api star which generates um which is

by Tom Christie, who's the creator of Django REST Framework.

And it's all integrated.

And that will take an open API schema,

which Django REST Framework will generate for you.

And then that's a separate tool to generate the doc site.

So for the next release, that will all be documented,

how you use API star,

and the tools will be in place to implement that.

But that will be part of the 3.10 Django REST Framework.

And when's that coming out, or when's the estimate?

The aim for that is April.

So, you know, it's always liable to slip, but only by a matter of weeks, not by a matter of months.

Wow. And then API star also has async stuff included, right?

No. So, okay. So API star is the tooling suite around APIs.

There's a client that will be involved, but the async stuff is a framework called Starlet, which Tom Christie's been working on.

Oh, that's what I'm, okay.

Right, and so that is a, how to describe it,

that's a kind of micro-framework for using Python in an async,

async Python to build web applications.

Right, so just as Python 3 has async, which Python 2 didn't,

and Django itself in 3.0 is going to, later this year,

is going to start in some form down the async roadmap.

Exactly when Django has async support is an open question

because it depends when it's finished.

Yeah. Yeah. As with all things. I think it's also worth quickly mentioning GraphQL,

which if you're learning about APIs today, these days, you're likely to hear about GraphQL.

So GraphQL, it's different than REST. I'll take a shot and then you can try to explain it.

You can use it with Django right now. There are a number of packages. It's a little bit early days,

I would say, but it's very usable. And so why would you do this? So there's a little bit of

waste with a REST framework. For example, if you want, you have to do three separate calls,

for example, to get a user to find their posts and then to find their followers. So that's three

separate call response, call response, call response over HTTP, which has headers. And so

it's a little bit expensive with, again, because each of those is a distinct API endpoint with a

REST framework. Whereas with GraphQL, that all can be included in one query. So it sounds like a magic

bullet of just the front end person can specify what they want and then just get it you don't get

you don't waste seeing you know hitting an end point with all the users if i only want one

but i would say we're not quite there yet but you know if it does what it says it does and it

then it will be the future but i think it's a ways off yeah what do you think i have like yeah

you've described it very well like so the the exciting thing about graphql i think is that in

in theory enables clients to create their own query they can specify what objects they want

and what fields they want and right so they don't have to badger the back end right they don't need

a custom api endpoint for every little tweak that they want which can drive you know a back-end

engineer a little bit crazy so that's that's another nice thing saying oh you just you just

say what you want i don't need to customize everything for you but there's a cost to that

in that it still has to come out of the database and there's still problems where you end up

triggering the n plus one queries i.e if there's a foreign key to an object it not only looks from

an object it not only looks up the object but all of the too many that it has and you can end up

yeah very expensive queries and then those have to be hand optimized and it turns out

at the state of tech that we have today that the back-end engineer is doing just as much work

getting the graph qln points to run efficiently as they were creating so at this stage i have to

describe myself as a bit of a graphql skeptic at this stage yeah for me what i like to do is i like

to create a utility endpoint which if i need a nice nested um rich response which has got the

user plus all their posts from the last week plus a follow account i create a utility endpoint which

fetches all of those and interesting returns those as a as a single package so the client's still

only making one call but it's making it to a utility endpoint which is um easy to craft and

it's done on the back end and it can be optimized and for me the really exciting thing about all

this async python stuff is these kind of proxy endpoints because yeah they're nice and lightweight

and the async stuff really can get a benefit there which i don't necessarily see in the more

traditional endpoints so to speak at this stage again um but i like to create an endpoint like

that yeah yeah it's good to know the costs i mean i you know my so after i gave my talk at

jango con i was asked for advice and i you know i don't i'm not currently working on a project at

scale so i'm not sure how how um if it's my place to say so but i would say i would not change an

existing project from REST to GraphQL. If you have a new field thing and you want to try it out,

I would say give it a try, but I wouldn't do it on a major project and I certainly wouldn't switch

something over to it because I think maybe people aren't aware of that proxy endpoint approach too

that you're mentioning. Yeah, because I've heard a number of posts about that. But what I'd like is

Django to bring it to get the least async in the view layer so that it was easy to write these kind

of proxy endpoints in Django itself.

And then it'll be super derived.

I'll post about that.

Yeah, so the takeaway is

REST isn't dead yet.

There are lots of tweaks.

There is a cost to GraphQL,

but it is a very cool technology.

And I've seen some really

mind-blowing demos,

but it's a work in progress.

Yeah, and you know this wave of technology

as it advances,

and they always say

that you want to be slightly boring

or slightly conservative

in some of your choices.

For me, GraphQL is just a little bit too near

the breaking edge of the wave at the moment

to be jump onto for a major project yeah yeah for me for me so yeah yep so how does one learn this

carlton there's the official documentation what are you often asked this question or are you more

like high level dealing with you know the pros making making you know commits to it um

most people who come on to the github issue tracker already have used it so because i hang

out there that i don't get to answer questions about how i learned this but yeah the official

tutorial i always say look go through the official tutorial we've talked about in previous episode

about how it can be a bit high level if you're an absolute beginner but if you you know if you

if you're intermediate if you know your stuff then go through the tutorial and by the time

you've done that you'll have a good idea of the of what rest framework can offer and then start

building your app start building your endpoints and just try and for me the there's certain

patterns or anti-patterns that i see where people put too much logic in views or they're not extent

using the serializer api in the right way i think you've got to learn those with time but ask

questions there's a mailing list there's stack overflow again there's all the other resources

but just try yeah we'll we'll link to the mailing list and yeah in terms of so i wrote a book on

this last year in part because at the time i wasn't aware of any books on the topic there

have since been a couple which we'll link to but you know my book's a good resource the first couple

chapters are available for free online rest apis with django.com i think the challenge when you're

learning is you build the api and then if you're building something solo then you need to know a

JavaScript front-end framework. So you need to know JavaScript, you need to know the front-end

framework, you need to learn about how to pass the auth tokens back and forth. And so I'm often

asked, which one should I choose? Which is a tough thing to answer because you really just need to

pick one and go with it. If someone came to me, totally said, which one should I learn? I don't

really know much. I would say the big three are React, Vue, and Angular right now. There's also

ember there's some other ones yeah i'm a big fan of elm which is a whole different yes like but

yeah i love that i love that i love that mainly because it keeps me out of the whole javascript

churn battle i can just stick with elm and i don't have to worry about what the latest changes in

javascript land up yeah there's something to that i mean react in particular is changes dramatically

so if i had to give advice which i would be hesitant to do i would say picked react or view

knowing that they change really fast and you just need i would just recommend sticking with one for

a while when you're a professional developer often you'll be on a team and you won't have to do the

back end and the front end the challenge is if you want to you know build a blog with django and

react or view you kind of have to learn all this and there as far as i'm aware there isn't a great

guide to all that because it's really two three separate things it's django it's apis and it's

the front-end framework of your choice yeah it's too so be aware that it's too much so you know be

aware that just knowing how to do apis is a huge skill and while it's fun to try to do stuff with

front-end frameworks that's real there's a reason that's a separate job yeah so for me for me there's

the exact distinction you drew was is between if you're doing it professionally on a team you won't

be building both parts yourself so you can focus on the api or you you're on the front end and you

you the interesting discussions you'll have exactly what the end points are and what the

data transmission formats what the json looks like like that's all great stuff but you won't

be building both bits if you're building a solo project i'm going to end up sounding like an old

manning it but like do you really need an api like can you just get away building a django site which

does a static request response return renders the page on the server gives you back the page

and then sprinkle on some javascript and the odd api endpoint just to enrich it a little bit

but to drop as a solo developer on a solo project to drop everything to go for this single page full

front-end thing, I think you're just biting off way more than you can chew. If it's a learning

exercise, no problem. But if you're trying to build it as a viable, actually get something done,

consider the traditional approach. It's not so bad. In fact, if you get something built that

works versus not get something built that works, it's much better.

Yeah. As with so much technology, the challenge is how do you iterate on it? And I also urge that

caution try try it out but do you really so certainly a solo project do you really need an

internal api yeah think about it and maybe you just need a couple couple a couple things not

the entire site to be switched over um it's it's a challenge i mean i i was one of my takeaways

from django con last fall which is my first major django conference was it struck me that

most Django people don't know JavaScript well at all. And that's because they don't need to.

I've worked more very early stage. I've worked on solo projects. So I'd say I'm intermediate

level with JavaScript. And I was feeling, wow, I'm surprised these folks don't know JavaScript

better, but it's because they know Django and Django rest framework and all the rest of that.

I'm sure much better than I do. It's really, you know, once you, once you go in a professional

role you're gonna you're gonna be specializing um and yeah for a solo project keep it simple

no one cares if you have an api or not on your project and there's a reason why teams work on

this stuff it is a lot of work even a simple site to have it be super smooth and fast and performant

yeah so are you looking at you know half a dozen people on the back end half a dozen people on the

front end and there's no way you're building it all yourself and somebody who is a is a react

specialist and they their whole job is building that front end and getting that right and

to expect to do that and to do the api and you know and deploy it yeah it's just not feasible

you're gonna be swimming in the deep end and you're gonna be confused so that i've i'll link

to i gave a talk at django boston last year talking about how to use django and react together

and actually in my book i do give an example of how to add react which is the same way you would

a front-end framework so there's a little bit there but it's very rare to find something that

covers both an api and a front-end because they're different worlds and they move so fast so just be

aware of that when you're learning this be aware that maybe you want to you know don't blame

yourself if it's confusing because it's confusing for the pros as well and and for each project

decide is this a learning exercise in which case i can be more experimental or am i am i trying to

ship a product because if you're trying to ship a product keep be conservative stick behind the

curve, go with the known technologies, and you'll get further. Yeah, 100%. So let's try to wrap up

here. So how can companies help support Django REST Framework? Okay, so they can sponsor it,

right? And so Tom Christie runs a company called Encode.io, which is sustainable open source

software development. And you can become a sponsor of that. And you can get your logo on the front

page of the Django REST Framework

docs and you can get some

publicity from that, especially if you're hiring

in the Django world, that's useful.

I see companies on there all the

time that I didn't know were Django shops

that I, you know, I think that's

the number one way to hire

a Django developer, I would say

is to sponsor Django REST

Framework because chances are if they're doing Django, they're

doing back-end work, which means APIs

and everyone is checking that site, the official

docs, all the time. Yeah, and

it gives you a good

profile boost

within the community, I would say.

Yeah, it's good karma because there's

many more people using it than sponsoring it.

But it's more than that. It's more than good karma.

It's good business in that for a very small

sum, if you're a company

of any size at all, you've got payroll every

month. And for a very

fraction of that, for loose change, basically,

you can add to the sustainability

of one of your core dependencies.

And that costs

nothing. That's just good business.

Yeah. Anything else we want to mention?

We'll sponsor the Django Software Foundation as well.

Yes. Yes.

All right. Well, as ever, if you have questions about this episode,

please let us know on our website, djangochat.com.

Give us inspiration for future episodes, and we'll speak to you next week.

Okay. Bye-bye. Join us next time.