Transcript: Django REST Framework (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, Will?

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.

So, I just used Ajax 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 the 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 big thing that came up was mobile applications,

which aren't necessarily web-based.

And so, 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 also talk to multiple clients.

So, you 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 know, 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 bit?

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 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. 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 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 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 OK 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? You know, dealing

with a 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 dot

com, it'd be API dot Google dot 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. Verbs here, like these, this is the key point for me is like all the other

stuff, the stateless and whether it's kind of interesting.

But the key point for me is that the HTTP, how many T's was that?

The HTTP verbs correspond to the methods of CRUD

normally understood. So you get to retrieve a resource.

You can post or put to create or update.

You can delete 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 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.

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.

OK, 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 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.

So that's why it's so important to 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 it.

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

the 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 a django rest framework and i was building a django rest framework

um 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 a tool 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 stackover though the mailing list is too hard so i got onto the mailing list i got onto 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 i'm closing tickets and

merging pull requests and it's all you know and that was that was how i got started in open source

was i was using django rest 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 you've already yeah you know

i needed i needed to build apis and django rest framework was and is just a super way of doing

that yeah and i i think in if you 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

api is not so bad you know standard functionality uh you know it's 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 uh excuse me web api

with a minimum of code i haven't seen really a lot of people who have done django rest framework

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 try doing this with a 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 um which was

when i met in person for the first time i think we 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 could 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 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

yeah which which which is that http and please correct me on this but http contains header body

message typically so the 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

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 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 yeah 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 then 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 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

jwt or all of tokens of some kind and be aware that it is it can be very complex yeah and there

are and there's like a dozen third-party ways to do it it's that you know if you go to the official

page there's there's a reason why there's tons and tons of pages to do this partly because the

technology around this is is a changing space with javascript web tokens and other in oauth

for 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 jingo rest framework is the concept of cores 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 you know site a.com i 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 yes which will link to uh take by adam 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 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

and then there's a back-end,

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.

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

it's 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,

and we're in the process of doing that right now,

and we can generate an OpenAPI schema now,

and that will improve,

but the inbuilt docs,

which were built into Django REST Framework now,

they are based on OpenAPI,

and in the next version, 3.10,

they will be deprecated,

and there's another tool called API Star,

which is by Tom Christie,

who's the creator of Django REST Framework,

and it's all integrated,

and that will take an OpenAPI 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

and how you can generate it,

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 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, that's what I'm...

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

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 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?

Yeah, you've described it very well.

So the exciting thing about GraphQL, I think,

is that in theory it enables clients

to create their own query.

They can specify what objects they want

and what fields they want.

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 a back-end engineer a little bit crazy.

So that's another nice thing,

saying, oh, you just say what you want.

I don't need to customize it.

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 making 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 GraphQL endpoint.

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.

For me, what I like to do

is I like to create a utility endpoint,

which if I need a nice nested 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 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 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 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,

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

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,

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,

I think maybe people aren't aware

of that proxy endpoint approach too

that you're mentioning.

Yeah, perhaps I need to write a blog post about that.

But what I'd like is Django to bring its,

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

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

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

you're doing and you'll have a good idea of what you're doing and you'll have a good idea of what

of what you're doing and you'll have a good idea of what you're doing and you'll have a good idea of

can offer and then start building your app start building your endpoints and just try and for me

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 the 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 that's you need to know javascript

you need to know the front-end framework you need to learn about how to pass like the

auth tokens back and forth and so i'm often asked which 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 you know someone came

to me total totally said which which one should i learn i don't really know much i would say the

big three are react view 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 bro yes like but yeah i love that i love that i love that main i love that main

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 this 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 man again 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 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 uh i don't

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 you're going to be specializing um and yeah

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 a good idea to do that and i think it's a good idea to do that and i think it's a good

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

add 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 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 um so how can companies help support

django rest framework okay so they they can sponsor it right and so um tom christie runs a company

called encode i'm going to show you how to use encode and i'm going to show you how to use encode

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 um django rest framework docs and

you can get some some publicity from that especially if you're hiring the world that's

useful i see companies on there all the time that i didn't know rojango 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 not going to be able to do that

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 uh 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