Django Chat

API-First Architecture

Episode Summary

We discuss the multiple ways to architect APIs with Django REST Framework, including focus on authentication, front-end frameworks, and performance.

Episode Notes

Episode Transcription

Will Vincent  0:06  

Hello, and welcome to another episode of Django chat weekly podcast on the Django web framework. My name is Will Vincent I'm joined is over by Carlton Gibson. Hello Carlton Halliwell. And this week, we are going to talk about Django rest framework and specifically architecture, different approaches to putting it all together. Since this is a question I get all the time you probably do as well. And this will only be our second episode on Django rest framework. So it's worth more discussion. Yeah.

 

Carlton Gibson  0:32  

What did we talk about? The first one was like the base, I think was the basic All right, yeah.

 

Will Vincent  0:35  

Yeah. And also that was like, so that was about a year ago anyways, so

 

we can refresh it, which I should say,

 

what's happened to the year?

 

So broadly speaking, so let's just so just to tee it up. So how do you structure Django rest framework? And this I mean, because I see teaching beginners is a big leap and understanding, what's the difference? How does HTTP work? So broadly, speaking, So I'll I'll talk until I tap out because you're the you're the expert here. But I would say there's two main ways you can structure Django rest framework, you can basically have, you have a front end and the back end. And you can put that all within Django do a monolith approach. Or you can separate it out into a single page architecture where you have your back end running normally on Heroku, or wherever. And then your front end is somewhere else. But before we get into it, let's just tee up. Django vs. Django rest framework just for people out there. Because, again, how would you describe what's what's the difference between the two? If someone comes to you and says, how are they different?

 

Carlton Gibson  1:37  

Okay, so Django is the web framework. So its fundamental role is that core web problem of turning requests into responses, right, you send a web request, you get a response back, you ask for a HTML page, you get the HTML page back and it pops up in your browser. That's jangles job. And then there's a special, he does a great it's got everything you need for all aspects and you can do everything the Django rest framework. coffers with just Django. You don't have to use Django rest framework. But if you're going to build what we call an API, and that normally these days, it means you're serving JSON, which is JavaScript Object Notation, which is for a machine to consume. So it's like a mobile app is going to consume data from your website, it's going to it's not going to consume HTML, it's going to consume, like a schematic JSON document, and then turn that into something that will present on the screen for you. They call those API's and RESTful API as well that we can talk about exactly what restful is meant to be. But Django rest framework makes those kind of endpoints easier. So it handles rendering to JSON for instance, setting the right content types. I don't know content negotiation, so you might want you might be able to send out JSON, you might also be able to send an XML you might also be able to send out HTML, you might also be able to send out I know yamo Well, who knows what, but it has parsers which take incoming data It could be in JSON format or multi pipe for multi part form post, like an HTML form, or any other form of XML data you might send across to your web server, it will pass that data it has it does content negotiation about which which types of requests you want, which type of response you want to accept, and it will render that back for you. So that's the kind of core bit that Django doesn't have that out of the box, right.

 

Will Vincent  3:24  

And I think the even better way to say that is because I think sometimes people confuse URLs with endpoints is at the end of the day, we're dealing with the web. So it's, it's sort of the same thing. It's an endpoint, if it's serving up JSON or data. And it's a webpage if it's serving up HTML, CSS, everything that you see.

 

Carlton Gibson  3:43  

So one of the original things in this idea of rest being restful was that the resources that the our was for resources, resources were meant to be addressable. Like they had a specific URL, which was their address and you were able to say, this address and Then you do use the HTML verbs to to get to retrieve the representation of the of the object post to create a new one put to update it Delete to get rid of it. These were

 

Will Vincent  4:13  

the

 

Carlton Gibson  4:14  

the idea with rest the core ideas with rest were that it's an addressable resource that you can use these verbs. More.

 

Will Vincent  4:21  

Yeah. And I think part of it is that if you're dealing with a normal website, you don't have to really you have don't you don't have to know about HTTP at all really, or the verbs. But it is a little confusing because the verbs are in the header. So if you go to look at a page and API endpoint, you can't necessarily just see what the verbs are on it. I mean, you can if you use postman, or if you use Django rest framework comes with a web visualization tool, but sometimes a little bit harder to see what all is happening there. Yeah, and in the standard browser, you only really use GET requests and then POST requests when you submit a form or something like that. So they only use two of the of the verbs. And it's only in a kind of API environment that you usually use put or delete, as well. And then there's head, which just gets the sort of metadata for the for the, for the endpoint and

 

Carlton Gibson  5:13  

other things option. Yeah, stuff.

 

Will Vincent  5:14  

So if you have a, if you have, let's say a to do list in Django, and you want to turn into an API, broadly speaking, you install Django rest framework, you need to create a serializer, which will transform it into JSON, and you need to point to the URL you wanted at. That's basically it in terms of,

 

Carlton Gibson  5:32  

yeah, so serializers like a fool, right? It validates incoming data and it takes your whatever you want to send back and serialize it DC realizes the incoming data turns it into an old Python object representation so that you Python can do stuff with it. And then on the way out, it will serialize it back to whichever format your your renderer uses. So JSON array

 

Will Vincent  5:53  

probably JSON. Doesn't have to Yeah,

 

Carlton Gibson  5:56  

I mean, J. It doesn't have to be but JSON is the sort of default And then you have it you have a view. So rest framework has some great views it has. So instead of the base, generic view class, that pipe that Django gives you, which is view and then detailed view in this view, it has API view. And then it'll have

 

Will Vincent  6:14  

a whole list API lists to generic

 

Carlton Gibson  6:15  

retrieve API view or delete API view or create update, retrieve IP API view, are these generic classes, class based views, which they're really fantastic. I, the other few weeks ago, I was done cracking open a new project that you know, really excited blank slate, cracked open rest framework generics, which is the module where all of these generic API views live. And I was just like, wow, I love this. It's just so nice. It's so very everything you want. It makes. It makes crafting API's just just a delight. And so I was just had a little geek moment. Yeah,

 

Will Vincent  6:52  

well, and we're going to talk a little bit in the abstract about code. If you want to see real examples. I have a whole book on it Django for API's, and also, if you're Struggling with the DRF tutorial, I also will link to I have a beginner's guide to the tutorial where I hold your hand and you build the exact same amount of code. But it's very beginner friendly. It doesn't assume any sort of knowledge. So those are two resources if you're hearing what we're saying, but kind of want to do it yourself. So the structure that let's talk about the structure, I mean, do you agree with this saying broadly, there's sort of two options, you can put the back end the front end, within Django itself, basically, you put it in the static files, we can talk about that, or this SP a single page app where they live on different domains. You just knew, you know, we will dive into those. But I mean, I think the standard thing of someone's talking about a single page app or they're talking about API's in front ends, they're talking about something that's living, you know, the back end is living at app dot example. COMM And it's serving up stuff two, or excuse me, living at API, API, example COMM And it's serving stuff up to a dedicated on end, which is that, you know, app.example.com. And then you, you know, you deal with course headers, but you doing cross origin requests back and forth. Yeah.

 

Carlton Gibson  8:09  

I mean, that's that's common. So

 

Will Vincent  8:11  

I think that's most code I say.

 

Carlton Gibson  8:13  

Yeah. I mean, these, there seems to be this massive.

 

I think because JavaScript, real front end development has become become so specialized and so difficult. Yeah. That there's this tendency to think, Oh, it's the back end is just an API. Now there's, there's a, there's another way of looking at it. And the way I do it doesn't matter whether you serve different domains or not, you know, you can serve it at API and app or whatever you can. You can have your single page served at a single URL from your Django application and the API served from the, you know, other URLs and that same, it doesn't have to be different domains. It's just, you know, that's a pattern that some people that's popular, but the way I like to think of it is are you generating doing single page apps where you're literally it's, you know, you basically load a single HTML document. Which is almost empty, and it just loads in the JavaScript, which then builds the application by fetching from the API. So that's the single page application model where, you know, you never leave that one URL. I mean, it might get updated, but you never refreshed the page. Right?

 

Will Vincent  9:12  

And that's the tricky thing. Because with like, React router and stuff it, you know, it makes it look like the URL changes, but it actually doesn't.

 

Carlton Gibson  9:19  

Well, the URL changes, but they never refresh the page. That's what Yeah, right. You never do a whole page page, right? Because the tie into the browser history, so you can click the back button that works, right. Maybe that's

 

Will Vincent  9:31  

a separate discussion.

 

Carlton Gibson  9:32  

You can bookmark those URLs and go SEO

 

if it's Yeah,

 

Will Vincent  9:36  

yeah. If it's built whether Yeah, that's a trick. It's sometimes tricky to do that.

 

Carlton Gibson  9:40  

And then, and then contrary to the so the distinction I make isn't so much are you serving it on different domains and these subdomains, and that is between are you doing that kind of single page application? Or are you serving HTML pages that are server rendered by Django, say, and then sprinkling JavaScript on top of that, which then in Han says in a lot of times that JavaScript or will, you know, say you've got a form. And that form is rendered as a static HTML form. And it's fully functional as a static static HTML form. And if you click Submit, it will do a page refresh. But then you load some JavaScript on top of that, which takes over that submit event. And we'll submit it to the API directly without doing a page refresh. So if you look at I don't know, I won't pick a particular example, because no doubt will be false. But a lot of sites that might that I think have done very well, they will be functional, even if the JavaScript doesn't look, yeah,

 

Will Vincent  10:33  

it's a best practice, because JavaScript doesn't always work. So for various it's a bit more

 

Carlton Gibson  10:38  

work. It's a bit more work to do it that way.

 

Will Vincent  10:40  

Yeah, because you're building for both use cases, basically.

 

Carlton Gibson  10:44  

But you can also be for me, you can get remarkably far building a static HTML site and sprinkling JavaScript on it much further in a single developer with a small team then needing the full expertise of the heavy JavaScript, right.

 

Will Vincent  11:00  

And that's how it used to be when it was when jQuery ruled the land. It was, you know, you would sprinkle in the JavaScript and jQuery was like, the library that you would use to do that. But it was very much you sprinkle it in as opposed to Nope, we're gonna toss it all over to dedicated front end land. And it was, yeah.

 

Carlton Gibson  11:16  

And but what is it was a nice evolution as well, because you there was, was this thing called backbone that was built on top of JavaScript. And so jQuery is built on top of jQuery. And it was great, because it enables you to maintain state of these views that, you know, they were complicated, yeah, state, in a view, sort of maintain it. And then there was this nice, slippery slope, it just got bigger and bigger and bigger. And then, you know, React came along with the virtual DOM and all of that, and kind of changed the world because that was a much more performant. And,

 

Will Vincent  11:46  

yes, one way, once you're, however large, the initial load gets in there, then it's good. But there is a bit of a bit of a load time.

 

Carlton Gibson  11:54  

But so the so that's how I do it, rather than saying it's a monolith where it's deployed as a single Application versus two applications, two different subdomains. For me, the distinction is are you doing SPI? Or are you doing largely server side rendered, or the at least the initial render server side? We then JavaScript layered on top of that.

 

Will Vincent  12:14  

Yeah. And if you're doing the the ladder, which is more of the traditional gengo approach, so you have your static files and your static directory, you use something probably white noise in production. And, yeah, there you go. I mean, you, you try to think there's one other step you need with that, I think, but yeah, forget off the top my head. Maybe you don't? Well, are you you? You can cache it, right. So you can you want to cache your static assets that maybe gets into the performance aspect we could talk about, which actually, I wanted to ask you, that's a slight tangent, but since you maintain Django compressor, well, I've helped I don't really help us I've helped

 

Carlton Gibson  12:51  

I've helped out in the past and, okay,

 

Will Vincent  12:54  

you're still used, you're involved with that, which, I believe broadly speaking, third party package, it will minify your front end and do some stuff on the images, right? That's basically

 

Carlton Gibson  13:04  

Yeah, well, no, there's so

 

Will Vincent  13:07  

I mean, it won't optimize your image specific

 

Carlton Gibson  13:08  

to its specific task is for CSS and JavaScript. So let's assume that you. So let's assume you're loading your you don't have to do it this way anymore. But it still works. And it's great. You can, but let's say you're loading all your CSS in a single block at the top, and you might have three or four CSS files. And it will, what it will do is combine those into a single CSS file. And if you're using pre processes like sass, or post CSS or anything like that, you can run your CSS files through the pre post processor, then it will combine them then it will minify them, and you then it will stick them in a known location. So next time, it doesn't have to do all of that, all of those things. And it will do the same for your JavaScript and you can even load you can load your JavaScript at the bottom that you always used to do used to put it right at the bottom. But you put it all together, but you want it in a single file on HTTP one, it's not so simple and HTTP

 

Will Vincent  14:05  

two separate,

 

Carlton Gibson  14:06  

you know, we're all still, we're still way ahead of the curve, just do the old stuff for now until, you know, the new stuffs proven.

 

Will Vincent  14:13  

Yeah, exactly. Yeah. Well, so my question is, I mean, so but you

 

Carlton Gibson  14:16  

can, you can now all the all the modern browsers allow you to use this defer attribute where you can, you can stick the JavaScript at the top, you can start it or async loading is rather than defer, you can start sticking it at the top and it will load parallel to your page rather than blocking it, which you used to do, which is why you put it at the bottom.

 

Will Vincent  14:32  

Yes, because your page loads from top to bottom. So like, I think the biggest performance thing around all this is caching. And you know, people not using a CDN. So I guess my question to you was, if you are using a CDN, so CloudFlare or something in front, does it also make sense to use Django compressor or is that a little bit of overkill?

 

Carlton Gibson  14:53  

Yeah, yeah. So the way I run Django compressor, this is this was gonna be a DRF.

 

Will Vincent  14:58  

Well, it's related. We're talking about The front end, okay, front end stuff we'll

 

Carlton Gibson  15:01  

cut back there in a minute. So the way I use compressor is it's got a compress offline setting where you, as part of your build step, as part of your deployment step, you run the compressed management command, and it generates all the compressed files. And then you can put those wherever, wherever you want. And there's a manifest, which it will quickly look up what the what the finished files were called, and insert the right link element into the HTML as it served. But what's good is you get you get a single asset come conjoined, compressed, minimized. css file. And, you know, if you're using other tools like purchases, which eliminates your unused, unneeded CSS, then you know, you get a nice small package in your page loads loads quickly.

 

Will Vincent  15:48  

Yeah, why and so to bring it back to our DRF discussion, part of I think part of why the, you know, single page app structure is popular is also in part because now you Have, it's rare to have truly full stack people, full stack teams, you have such a divide, it's sort of nice to have separate code bases for back end and front end. Yet if you're solo or small developer, you know, two or three, you know, maybe that's overkill, right? I mean, if it's you or me building an API driven site, you know, I would probably start with serving it within Django. And then if I needed to, and I really needed to, I would go SPI, even though just because it's a little bit simpler, you know, hard to say, but the cultural thing that I think is an interesting take on why would you choose one over the other and you know, you don't want JavaScript engineers touching your back end and probably vice versa large setting

 

Carlton Gibson  16:40  

Yeah, and so this Yeah, so this is this is nothing is JavaScript engineers don't want you touching the the front end stuff.

 

They want to build their app and they want to build it.

 

Will Vincent  16:48  

Where are they What are they?

 

Carlton Gibson  16:50  

Yeah, well, no, that's totally legit. What I like about Django compressor is it I'm, I'm, you know, I'm happy to go all the way to you know, Photoshop if I have to, but on the back end fella when it comes right down to it, so what I like about say using Django compressor is it enables me to do get to a point where if I have to hand over hand off to somebody who's a front end professional, a solid front end professional, what I hand them isn't embarrassing, you know, it's like, yeah, this is fine. I'm, you know, I'm just I'm able to use you know, Webpack or post CSS, or whatever, it's, whatever your whatever your tool they like, I'm able to do that. Um, so yeah, here's my build steps. You know, I just run it via this compressor tool, which runs you

 

Will Vincent  17:31  

know, yeah, you can you are doing

 

Carlton Gibson  17:33  

Yeah, yeah. And I've got all those things and it's not Yeah, no, it's fine. Yeah,

 

well, then they can go off and build their thing. Without me feeling that i've you know, I've got about my face.

 

Will Vincent  17:44  

You know, I find the older I get I truly less I care about others opinion of me, but it is true. It's nice to have some professional respect for someone else. I was gonna say, if you're curious if a site is truly an SPI or not, if you go look at the few views source, if you see just a teeny bit of HTML and then just some long glom of JavaScript, that's an SPI. If you actually see HTML elements being laid out, that's probably more of this, you know, JavaScript sprinkled in. But sometimes, you know, if you go and look at view source, because sometimes people say, Oh, can I want that they want to build such and such a site, or I'm just curious. If it's, if you can't make any sense of it. It's an SPI. It's just a whole glob of hopefully encrypted but compressed JavaScript, or not not encrypted. What do you do you? Will you minimize? Yeah, I minimize but actually, for a while you were also you could do the thing where you was you could kind of obfuscate it, but you could also

 

Carlton Gibson  18:38  

it wasn't Peter, ship source maps, source maps is the thing. So when you when it's totally compressed, all the variables have renamed so like, yeah, I've got I've got a nice meaningful variable name that gets renamed to

 

Will Vincent  18:49  

it. Yeah, exactly. Exactly. Yeah, you look at like, it's it doesn't mean anything because it's all been processed.

 

Carlton Gibson  18:56  

The, the web inspectors, they're all able to interpret source maps. So if you If you I think Basecamp do this, I think they, you know, they, I think David had my Hanson was calling someone out for their bad single page application or something. And, and someone's saying, well, but what about your JavaScript, which is all minimized, and no one can make head nor tail? And he was like, Yeah, good point. And they started shipping their source maps. So you can, you know, view source on there, and you can actually then get into the JavaScript and it will be pretty printed with the original source code rather than Oh,

 

Will Vincent  19:26  

that's nice. I don't know if I've, I've used that I didn't realize browsers do that now. Yeah, well that and that's a great analogy of I mean, I this happened to me all the time that I'm you know, opinion ating on something rather someone and then that and I sort of either I think oh, I should do that or they you know, asked me like Oh, are you doing that here? I'm like, well actually I'm not but now that you mentioned it good. I should I do want to mention and hat tip to

 

Carlton Gibson  19:53  

angle Hang on. Hang on. You asked the question I didn't get well I'm sorry. Is this like so I so i think that you know, you you pass something like

 

What do I think people should do? And I think, yeah, okay, I understand this whole drive towards the single page application. But there are, you know, 4 billion people on the planet who have devices not capable of running a full react app on networks that aren't able to download them quickly. And for me, server side rendering is still the way forward. And that should be your first option. And progressive enhancement on top of that, which is harder to get right than it is to build a single page app.

 

Will Vincent  20:31  

That's, that's the goal.

 

Carlton Gibson  20:33  

That's what you should be aiming for. And it's just better and richer and nicer and more in tune with everything you want. And when in your app will display on an Apple Watch, and it will display on a Samsung Smart television and it will display everywhere. Whereas your your rich JavaScript application, you'll suddenly find that over the rubbish mobile network, the JavaScript page didn't load and they get blank page.

 

Will Vincent  20:56  

Yes, that's very true. I had two things I wanted to add Or not even add just digress from what you said. So, the first is, there is another option for structuring things which I have to give credit to Jeff Triplett for mentioning this, which is if you're using Docker, which I often do, you can run it all within Docker. So you can have in your Docker compose file, you can have a separate image for the web, and then for the front end, and run it all in one container. So you can basically do an sp a within Docker, I was looking for more a code example or some guides on this and I don't think I don't know of them. If anyone does let us know in the show notes. But, you know, since doggers, to box around everything, you can also do it within Docker. And but I don't know if that's necessarily that much easier, because then you're in Docker land, but I want to mention that but the other thing is when we were talking about Django rest framework, initially part of why what trips people up i think is, authentication is a lot more complicated. In an API world, because basically, because traditional web app uses session authentication, we have a cookie. So you user logs in session object is created, and the ID is sent back to the user and stored in there stored as a cookie. And then that's passed back and forth on every request. So that basically, one ID can be used to unlock, you know, 2040 attributes that are stored in the server. So the server is the source of truth. The problem with that, of course, is if you have multiple front ends, so you have a web app and a mobile app or two mobile apps at the same time, sessions kind of breaks down. So then you go to tokens, or JW T's and, you know, this all is confusing. I have a whole Django con talk on it. But I think that's another thing when people switch over to DRF land that they go oh my god, because the official docs list for built in ways to do it.

 

Carlton Gibson  22:53  

Yeah. And then there's third party option is third party so Olson, Sutton the other

 

Will Vincent  22:57  

Yeah, and actually, I've um, I'd love to get

 

Yeah, the author of some of the leading JW t package, Dave actually just invited him. I don't know if you listen to the podcast, but Dave, come on. Let's talk about. It would be nice though. Part of it though, is the ecosystem JW T's is not core Django or core DRF. So while they work well, longer term, that would be nice. They should be rolled into Django just as two factor auth should be rolled into jenko itself at some point. So yeah, I mean, what can I say? It's a powerful word. But you know, so I guess I just want to mention in the context of what

 

Carlton Gibson  23:35  

Okay, so so Okay, so here's an interesting thing with DRF is why is it that there aren't more built in authentication options into DRF itself, like into the core direction as time goes on?

 

Well, no, the answer is because it's a question of maintenance. So

 

there's so much capacity to maintain Django rest framework and keep it going and keep it you know,

 

largely bug free up Is 100 tickets or whatever but there's no,

 

you know, it's it's got a regular update cadence and it's, you know, evolves over time and it's, you know, serious bugs are few and far between Now, most of the remaining tickets there are, you know, there's a bit of vagueness about the contract in you know, if you get in this really specific use case, it's not quite clear how it's going to behave with nails and you know, false Bradley's in the case. But yeah, it's it's a mature package now. But there's there what there isn't capacity to do is take every possible extension and bundle it inside Django rest framework. And as soon as that started would start to happen, Django rest framework become a maintainable and so it's much better that there's a third party package for I Wolf, and there's a third party package for JW T. And there's a third party package for you know, if you need to map your your serializer keys a camel case because that's what your Angular JS client requires, then, you know, there's much better there's this render is outside of Django rest framework itself that you can use.

 

Will Vincent  25:10  

Yeah, no. I mean, it's it's, but you know, it's pros and cons. I mean, it's better than that. It's not unmaintainable. But you also are shifting the burden of maintenance to third party apps. I mean, for example, JW T's our friend Jose pedia had the dominant one for quite a while and then his life complicated. And then there's a new one simple JW T's and this is pretty core stuff. That,

 

Carlton Gibson  25:31  

yes, you know, it actually be okay, right. But here's the thing. If it is cool, then it'll, it'll end up being maintained.

 

I would say, because there's a demand. So there's companies using it. So there's companies that stump up developer time to make sure that the package works.

 

Will Vincent  25:46  

And we should ask you Justin asked Jose a little bit about why he sort of mean Yeah, I know he got busy and he wasn't monetizing it directly, but he had, you know, the dominant JW t package for quite a while. Thank goodness there's a simple JDBC one but you know the number of issues on Jose is one that

 

cropped up. I mean this so that so that's attention.

 

Carlton Gibson  26:10  

Yeah, was it? No, but we don't always end up talking about open source but it's ultimately, you know, lots of people opening tickets and not so many people doing the work to fix them.

 

Will Vincent  26:20  

Yeah, well, we're gonna at Django con Europe, we're gonna I'm gonna be at the sprints, we're gonna, you know, get more people on board and maybe improve the docs a little bit around that to make that easier. I did want to add to so I recently while two things, a lot of two things for me today, we haven't recorded in a while so that's that's why so one is you got a backlog? Yeah. I so i, i soft launched my learning English comm site. So there's some stuff on there and I'm slowly porting things over and we'll do a whole episode on building that and things learned. But I put a blog post out actually again with Jeff Triplett on 10 most use Django packages basically Just pi for the last 30 days, and we'll link to that but it was interesting to me and first in that so it goes Django, obviously Django rest framework. Django course headers, which our friend Adam Johnson maintains because you, you know, if you're using an SPI you have to set the course headers you have set. Cool. So

 

Carlton Gibson  27:18  

you're done

 

Will Vincent  27:19  

doing a filter, which you are involved with as well. Number four, yeah, Django Redis is number five, which was like, that's pretty high. Finger extensions, which makes sense pi test Django. Django storage is debug toolbar. And then actually, I want to ask you j know, app cough is was number 10.

 

Carlton Gibson  27:36  

Yeah, yeah. So that's used by Django compressor, but who else is using it? That's it. That's so that's quite

 

Will Vincent  27:41  

high. I mean, I, I haven't used it personally, I looked at as like, yes, but

 

Carlton Gibson  27:46  

where does but it's enables you to do puts off per application. So if you write a third party reusable app, and you want settings for your reusable app, Django app comp is a nice little wrapper around that. So that's you. Somebody big must be using that though, because it's used by Django compresses I don't know who

 

Will Vincent  28:00  

else, huh? Yeah, maybe it's really I mean, maybe it's wrapped into something. It must be. It just seems way too high on the face of it.

 

Carlton Gibson  28:09  

No, but it's like one of those infrastructure once. Yeah, well, it's an infrastructure package. It's used by its package and said package and they sum up to a lot of downloads, huh?

 

Will Vincent  28:21  

Yeah, to unravel that.

 

Since I'm in a publishing mood, I also published my super opinionated, essential third party packages, which was 18, it was 17. And then people of course, the floodgates open with advice from people and I think I added one or two but my personal, highly biased takes on things I build everything with that, regardless of application. So anyways, though, there's some plugs

 

Carlton Gibson  28:46  

in there. It's really useful. I remember post it must when I was starting out with Jang, it must have been on like, I don't know, Jacob cabins mosses blog or something like that. They were some of the early people in Django and I was like, you know, you're getting into Django. And there was this post about, you know, these five top packages.

 

Will Vincent  29:05  

I didn't know that look

 

Carlton Gibson  29:06  

at but this was a long time ago. But you know, I think Django debug toolbar was on there or something like that. And I'm still using that today.

 

Will Vincent  29:13  

Yeah. Well, on the on the Django forum, there's a whole discussion on top five third party packages. And you know, everyone, of course, is like, Well, here's five. But then here's another 10. So that kind of brought about because really, five not enough. So that brought about decision to

 

Carlton Gibson  29:27  

go make you choose, right. Yeah. And I mean, you love five people at your party who's a good and

 

Will Vincent  29:33  

at the same time, I mean, I still have a awesome Jenga repo with where, you know, it sort of like layers of curation, where there's way more packages, but all ones that I think are, you know, seem valid to us, in my opinion, but maybe I don't use all of them myself. So they sort of like top five essential and then. Yeah, it's a good question. And I think it's helpful. I always like to hear from people. I respect the NGO community what they're mentioning, I mean, You know, even just just last week, you mentioned Django sesame package by Emmerich on magic URL opening that I didn't know about that's been around for forever, and is perfect for something I need to do. So there's always more to always more to learn.

 

Carlton Gibson  30:16  

Yeah. So you just mentioned Django read. It's there.

 

Will Vincent  30:19  

And yes,

 

Carlton Gibson  30:20  

about five minutes before that. You mentioned the importance of caching. And of course, that's where Django Redis comes in. Cuz everyone's using it for their Django

 

cash back end, right.

 

Will Vincent  30:30  

Yeah, I think it you know, caching. I mean, how much time do we have, we're going way over. A couple of things, you know, you so there's two types, or I think of it and you can dispel this but there's planning of caching. So one is just use it use a CDN. So you throw CloudFlare in front to serve up your site if it's basically a static site. So my learning.com site is essentially a static site. So I have Heroku I have Django hosted on Heroku and then I port CloudFlare in front of That it basically loads, you know, instantaneously. The Redis stuff is when you're doing caching, you know, on your back end on your database, basically. Which is a more real world use case. Yeah, be interesting. I mean, there is a whole discussion of, you know, Redis versus mem cache, I think we've talked about Yeah, we talked about in the caching, one where basically Redis is a little bit simpler these days, and seems to have the mind share though. memcached works fine as well. But Redis

 

Carlton Gibson  31:26  

I haven't seen a performance.

 

Will Vincent  31:29  

I saw one but it's it seemed pretty, but they

 

Carlton Gibson  31:31  

gotta be basically the same. No,

 

Will Vincent  31:33  

yeah. Yeah. was great. This is great, though, to see that Jenga Rice was that high? Because I always kind of wonder, and again, Django doesn't really track anything. So what you know, what's the mix out there in the wild? Like how much is students for beginners just tossing stuff up? How much is big production companies somewhere in the middle? It was I was I was glad to see you know, pi test. be up there. Django Redis be up there because I mean, those make sense in large applications, but I don't know if I'm, you know, beginner, intermediate people wouldn't use those. So I don't know, be nice to know what the full ecosystem looks like.

 

Carlton Gibson  32:10  

Yeah, I would the thing I see these numbers come up. And one thing that I always want to know is how much of it is ci? You know?

 

Will Vincent  32:16  

Yeah, well, that's true pie pie,

 

Carlton Gibson  32:18  

because as soon as you've got, as soon as you've got people downloading of API for ci, it's like that boosts the number. Right,

 

Will Vincent  32:23  

right. I mean, if if someone was inclined, you can totally game pi API. And there's actually Jeff, Jeff is gonna talk to us earnest ad Python, because there's some sort of another level of steps to see like, the real downloads versus just the public ones or some other filter you can add to get a little more accurate, but yeah, hard to say. I mean, who knows, but ballpark probably accurate. So, all right, what else? I think that's, that's it. Hopefully that helps people. We're very open to questions. I think there's probably a lot more episodes we can do on Django and APIs and DRF. So do let us know as ever, at chat Django on Twitter. You could also nobody's done this, actually. But if you want to send a voicemail and we could put on air Jango chat podcast@gmail.com you can send us a voice memo. And if it's a good question, we'll play it and respond to it. Anything else, Carlton?

 

Carlton Gibson  33:15  

No, no, I just I wasn't the episode. I thought it was gonna be. We talked about front end apps and single pages. Yeah, well,

 

Will Vincent  33:24  

we had a short. We had a couple of short ones. So I feel like I need to, you know, pad this out a little bit.

 

Carlton Gibson  33:31  

Now, that's fun. Good. All right.

 

Will Vincent  33:32  

Join us next time. All right. Bye, everyone.