Transcript: Django REST Framework

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 will need to, 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.

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.

Yeah, 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, 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

such as get post push put delete right and 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 each 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 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

create retrieve API view

like the common 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 you know 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 passing 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 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 Christie 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 too

many issues to triage there's too many questions on Stack Overflow the mailing list is too hard

so I got on to the mailing list I got on to Stack Overflow 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 because you that you got it you know because 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 maybe ruby on rails but maybe i mean we

get spoiled i think if we if we just start with django and django rest framework we think that's

the norm and then when something's difficult we complain or this is hard well yeah but if you

tried doing this with another framework yeah yeah um so what else does people need to know so

authentication is a big one as well with apis and i actually did a django con 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.

and 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 was because they have this same token or this same identifying

feature it could be a cookie it could be um a a token as you said of some kind um

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 right so just because you log in on the login page and then you're taken

to the home page the site doesn't know that you then can reload it for example it's exactly the

same with the with the you know traditional django application you have to have that cookie you have

to log in and the cook and the the back end 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 right so look 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 session off the same as the default

session off 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.

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 CORS. 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 yes yes which will link to uh take by m johnson who's a

you know, 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 names.

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, you know, an API, you need to have a roadmap to understand, so someone can understand

how to use it.

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

People just click around.

But an API, you know, because it's for another developer, you want, you know, first, for

example, if you're building a Django REST framework backend, and then there's a front

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 of how 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 them be largely similar.

But there is 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 OpenAPI, which used to be called Swagger.

And there's lots of tooling and there are other options out there, but this is the key one that's got most of the mindshare.

And to be honest, at this point, that's the one we need to integrate with.

So we're moving from what was a tool which was called CoreAPI to OpenAPI.

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 Django 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 which is by Tom Christie who's the creator of Django REST

framework and it's all integrated in that 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?

The aim for that is April, so

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.

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 generate using Python

in an 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 is a different, 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

then define 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 waste hitting an endpoint with all the users if

I only want one. But I would say we're not quite there yet. But if it does what it says it does,

then it will be the future. But I think it's a ways off. What do you think?

You've described it very well. The exciting thing about GraphQL, I think, is that 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 the more traditional endpoints so to speak at this

stage again um but i like to get 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 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 i

think maybe people aren't aware of that proxy endpoint approach to that you're mentioning

yeah because i've heard a number of about that um but what i'd like is django to bring it um to get

at 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 certainly 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 gonna 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 well way more than you can chew um if it's just

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 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 it's well as with so much technology the challenge is how do you iterate on it and i

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 for each project, decide

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

product? Because if you're trying to ship a product, be conservative, stick behind the curve, go with

the known technologies and you'll get further. Yeah. A hundred percent. So let's try to wrap up

here. So how can companies help support Django REST framework? Okay. So they, they can sponsor

it, right? And so Tom Christie runs a company called Encode IO, which is open source, 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, 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 that 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 you for a very

small for a very small sum if you know if you're a company of any size at all you've got payroll

every month and for a very fraction that for loose change basically you can add to the sustainability

of one of your core dependencies and that that costs you know that's nothing that's that's just

good business yeah anything else we want to mention we'll sponsor the django software foundation as

well yes yes um all right well as ever if you have questions about this episode please let us know

on our website django chat.com give us inspiration for future episodes

and we'll speak to you next week okay bye-bye join us next time