Keynote: All The Ways To Use Django with Zags (Benjamin Zagorsky)

Hello, Django Khan. I'm here today with a very hard job. I am here to convince all of you, the people who care enough about Django, to come to DjangoCon US or to watch it online that you should be using Django more. Let's see if I can do it. So I'm Zags. If you're wondering where that comes from, that's a last name, nickname, in case you haven't seen those before. And I am Chief Technology Officer at Zagoran. We are a Boston-based software consulting firm. I'm one of the founders, in case you're wondering about that name similarity. And I've been doing this for over 12 years. We do full stack

web and mobile development. And in that time I've worked on dozens of software projects. And Django is our primary but not exclusive backend. So I've gotten to see lots and lots of uses of Django, lots of uses of other technologies. And some of those cases were cases where Django would have done better and often a lot better. And so it's from that set of projects that I want to share with you my experience. And ways that Django can be used in sometimes unexpected ways to still get a lot of its power Now this is my fifth year speaking at DjangoCon, and I would like to start a rumor uh that DjangoCon US does have a there's a secret special. I'm gonna I'm gonna release this secret. It's a it's kind of a buy four get one free. Give four talks, get a keynote. Uh

Whether or not this is true, talk to the conference organizers. I'm sure they can clear that up. Now the reason I want to give this talk in particular is because I have heard over my years from very experienced developers A lot of misconceptions about Django. There are ideas about Django that it's it's this monolithic framework, and as a result can only do things that fit within the paradigm of that monolith. So for example, people saying I'm using React, I should use Next. js because that's designed to work with React. Or Django is a monolithic framework, I need to use it to build a monolith. And I can't I'm using a microservice architecture. Or I'm not even building a website. Why would I use a web framework?

Or even the more pernicious, well Django is Python-based and I can't use Python. I need too much asynchronous or concurrency. Obviously all of these are false, that's why the title of the slide is myths, uh, and I'm here to debunk these and more. I want to help clear up some of the misconceptions about Django and show you more ways that it can be used. Now to do that we have to first start with what is Django, and that's an opinion question, so I'll give you my opinion. And then I want to show you how Django and all of its pieces Can get taken apart and used as viable subsets in a number of different ways to help serve JavaScript, to work in microservice and multi-service architectures.

To work in non-web contexts like background processing, to work with other databases beyond just Postgres and MySQL. And then with all that, I want to give you some ideas for how you can get to Django if you have a project that would be a good fit but isn't built in it right now. And then to finish I want to give a couple thoughts for how Django itself can do better to help address these use cases and these confusions. So what is Django, at least according to me? I see Django as these seven pieces, and this is by no means a complete list. Glaringly, not on this slide is Django's test framework, which is very important and I will be talking about a lot during this.

There's also a lot of smaller pieces that fit into these. But the reason I want to go with these seven is because these are the seven pieces that I see building up that monolithic stack of Django. And these are the pieces that you can still take away some of them and have a very useful framework that can give you a lot of leverage So at the bottom we have Django settings. This is that swappable configuration that underlines Django's modularity. And allows you to use these pieces in such versatile ways. Next, the ORM, Django's ability to interact with your database in a Python native way. Django migrations, the ability to manage schema changes to your database empowered by the ORM, routing, accepting incoming HTTP requests and sending them to your back-end

logic. Templating, taking that data that your backend has and pushing it into dynamically generated HTML forms, a two-parter, both rendering forms with information from your backend, and then also validating The data coming back in from the front end. And then finally the admin. The ability for you to auto-generate from your models an interface for skilled and privileged users to be able to directly view and modify the database. Now when you have the whole thing, Django is awesome. Django is awesome because it's powerful at giving you functionality without you having to write that much code. Django 's greatest strength is what I would consider boilerplate reduction.

This is the ability for you to write code that is just what your application is doing and not all of the stuff that's generic. of moving data around between the front end and the back end in various places to make that work. So as a very specific example of this, Django Model Forms lets you take your database model that you've written in Django. Push that all the way to the front end. Generate a form for users to enter data into that and then bring that back. all the way through form validation, all the way back to saving your database, and pretty much all you have to write to use those by default is here's my data model, and then here are each of the pieces in that process I want Django to take care of for me. And then Django also gives you the ability in that to customize the validation or the rendering

as much as you want And on top of that, in the process, it gives you time zone support, translation support, authentication, session management, security at every layer of that process automatically. And it lets you build tests. Told you I'd mentioned tests. against every layer of that with per-test database isolation. This is something that having worked in other testing frameworks is a really important part of Django where your database gets reset after each test so your test can be written independently without having to worry about what the other tests are doing and more. This is why I love Django. This is why I have spoken at DjangoCon US five times now, because this is great. And you can still have some of this greatness, even if you're not using the whole thing.

So as an obvious viable subset of Django, you can take away the Django admin and still get most of this power. Why you'd want to do this? Well maybe your privileged users aren't necessarily so tech savvy and they need a little more workflow, a few more guardrails And so you can take away the Django admin and actually still get a lot of the power of Django from the rest of it, even in your admin replacement. You can still use Django forms and templating and routing to build you a beautiful custom admin workflow for your less technical admins. But let's push it further. Let's talk about JavaScript. Oh, didn't get boot off the stage for that. All right. So Django's a web framework. In the modern web, you kind of need to use JavaScript. And Django is conspicuously silent on the topic.

Django's opinion is that JavaScript's, it's just static files. This isn't good enough. Well, it's good enough if you take what I would describe the classic approach. If you say, okay, my JavaScript is JavaScript is going to be my front end. I'm going to have this JavaScript front end that let's say a single page app using React, Angular, or Vue to just build my your entire front end. Django can handle the back end. It can handle the API powering that application. And this is a great approach if you have more than one front-end technology. If you're going to have a mobile front end as well, maybe even a desktop front-end. Right, some array of front-end clients built in different technologies. Django ha managing a central API for these front-end clients actually gives you a lot of leverage. Because that is the common point of interface for all of those disparate front ends, and then Django can still do all of that data layer management.

So we have this viable subset of Django that is just the backend. This is routing down through the database. Now routing, I want to put a caveat here. By routing, we're not actually handling the user-facing routing. We're just handling the routing of the API. Your front-end technology, for example, your your single-page JavaScript app does need to handle the routing of the actual user navigation, and Django's routing is just handling the API requests that are hitting the back end. But even in this subset, Django gives you a lot of leverage. First and foremost, you still have the ORM and you still have migrations And I'll say it now and I'll probably say it several more times. The ORM is the best part of Django. It is the most powerful part of Django and the part that enables Django to do so much else. For example, even if you don't have Django Forms

auto-generating swathes of your interface from your database, you can still have the same thing with your API. Now for this we need to use a slightly Big tent view of Django considering Django and the ecosystem of libraries and community support it exists in. So if you're using Django Rest framework or uh Django graphing. You can auto-generate your API and your API validation from for from your models for either REST or GraphQL, and there's libraries to support other API styles as well. And on top of this, Django is still giving you its native authentication and section management. So this is great. This is totally a viable subset of Django that gives you a lot of power. But there's also something missing. And to understand what's missing, I want to look at the competition.

I want to look at Next. js in particular. And the reason I want to look at next, philosophy aside of whether or not it is a back-end framework or a back-end for front end or whatnot, it is a web framework. It is code that runs on your server in order to generate web front ends, and it does stuff that Django doesn't. What Next does for React in particular is it does native backend of React components. So what that means is you can take your back-end context, push it straight into your React components, and it makes it seamless for you. And it can go the other way. It can take your React components and do server-side rendering, so you can take this whole front-end you'd built in React and suddenly make it indexable by search engines and various other things. And you can do shared front end backend form validation. If you pull in a JavaScript form validation library like Zod, you can have one form validation get run on the front

end for that instant feedback for your users, and then on the back end. For that trusted validation before that data hits your database. Now this is not to say that Next solves all problems, where Django has this huge blind spot of JavaScript. Next has a huge blind spot of the database. It just says the database is your problem. I don't see either of these as good enough. We Django can do better. And I want to give two ways that you can do it. The first is that Django can, with a little bit of help, embed JavaScript components. So this is just an example. Both of these are ex examples. This is not to say this is how you should do it, but more to say that you can do it. This is an example using a library that my company has made and maintains called Django React Components.

And this is not a very large library. This is mostly just a wrapper around some other libraries and Webpack to take built React components and embed them on Django templates. But the most important thing is that last line and it's that last argument. to this React component template tag. That prop equals var. What that innocuous little argument is doing is taking a Django template variable, var, and passing it in to a React component prop. Which means that React Component, in addition to being embedded in the Django template, is getting Django's backend data loaded directly into it, which means we don't need to build an entire API for our React components. to be loading data on initialization, we can just pass it straight in the same way that we do with Django templates.

And this gives us so much back. This gives us so much more of Django to use. We can now use Django routing fully. Django is now controlling the user experience and the APIs. It gives us the ability to control the static parts of our template. And then just within those static parts we can put here are the React components where we need front-end dynamism. And because we control the routing, we can have the admin again. This gives us so much power. There's one caveat here, and the one caveat to this approach is that this doesn't work great with forms. That's not to say it works poorly. You can still use Django forms, even though I have them grayed out. But you can only use Django forms for static forms. These are cases where you have a form that you don't need any front-end dynamism.

But if you do, if you have even so much as a single yes and no, and if they pick yes, they have to fill in some details that you want to show up and have managed by your front-end framework, you have to, if you're using React, re-implement that entire form in React. And that feels bad. So I'm gonna give you another option. React isn't gonna work great for this because React likes to control everything that it's managing. Angular and Vue, on the other hand, work more with HTML tags and attributes. And As a result, are going to blend much more seamlessly with Django forms and Django templating in order to be able to give you front-end dynamism on top of what Django is already doing. So here's an example of Django With Vue using only Django Crispy forms, we can add in the relevant view attributes for Vue

to control our form in a front and dynamic way. So this is in this form we have a reason field and if we pick reason other we want a details box to show up. So what we're doing is we're just sneaking in a V model attached to that reason field and then wrapping that details field in a div that's v if reason equals other. And in order to render this form, we don't do anything special. That's just the regular CRISPY form rendering. And then we add in a view app so that when we load this page, Vue wakes up and takes over front-end control And then when you pick reason other, that details field shows up. This is all you have to do. There's a little more if you want to sneak in initial data from your form into the the context that that view is holding, but at least as a minimum viable example.

That's it. And here we don't even have a subset of Django anymore. We can use the whole thing. We can use Django forms. We can use the full stack Django monolith and all of its power and still get all of the power of front-end frameworks. And this is my view for the future of Django. That I'm gonna come back to at the end. But first, more ways you can use Django So, Django monolithic framework, not just for monoliths. You can use it in multi-service backends. And I'm going to show you how, but In order to talk about multiservice or microservice architectures, I have to answer the question, what is a service?

This is also an opinion question. There is not general consensus among the development community as to what a service is. So I'm going to give you my definition And my definition is the set of infrastructure that is co-deployed from a single repository. Ideally, the set of infrastructure owns its own data storage. For example, database and file storage. And that data storage is only touched by the infrastructure powered by that code repository. Any other services that want to talk to that data have to come through an interface defined by this surface. And the reason for this definition and for this guidance is data governance and in particular change management of your data schema. By having a repository that owns this infrastructure and this data storage, what we can do is have this repository be responsible for the schema of our data and for the changes that need to happen to that schema.

Now if that sounds familiar, that's because the Django implementation of those concepts is Django models and Django migrations. But these are generic concepts that many other languages and frameworks have. Now, from this view of a service, note that we can have multiple potential server environments running as long as they're code deployed. And all you have to do in order to maintain This management of our your data schema is deploy schema changes, for example, migrations, and then just deploy the infrastructure. with your new models too, each of those environments. And this paradigm gives us incredible infrastructure parallelism. Just to bust the myth that Python doesn't do async or concurrency, beyond the fact that you can run Django in async mode. You can have worker environments in your service. And

both web and worker environments can be massively parallel from an infrastructure perspective, global interpreter lack or not. Load balancers on modern clouds are elastically scaling, and then behind them you can have as many servers as you have budget for, each of which can be running as many processes of your Django app as they have memory for, multiplexed by GUnicorn or some other web server. The same is true of your worker environments, which can use celery or similar to get massive parallel processing using Python, which is single-threaded. Now it's not. There is one bottleneck here though. It's the database. If you are using a relational transactional database like Postgres or MySQL,

Which is not to say you shouldn't. That is still the bottleneck. There are huge advantages to using those, which is you get data consistency guarantees and availability guarantees, but that is still the fundamental bottleneck of this architecture. Now a quirk here is that when people say, well, I need multiple services so that I can scale. We have to think about what kind of scaling we're talking about. If we just cut this into multiple services, each of which own their own databases, that's not actually gonna get us a scale. Maybe if we cut the database perfectly, we might get some constant factor increase. But when we're talking about Microservices providing scale, what we're really talking about is engineering scale. What we're talking about is the ability to have an engineering team that's hit the 50, 100, et cetera person mark be able to get split into teams of 5, 10, 20 that can work in parallel.

That's the kind of scale that microservices actually enable. So monoliths are incredibly efficient. They're incredibly efficient from a coding perspective. Every time you make a split, function calls turn into API calls, and a single coherent database turns into multiple databases that need to agree on state or potentially manage replication. There's architectural cost to every split that you make. And you should only do that when the coordination overhead of make managing this in one service with all those engineers and merge conflicts and whatnot is outweighing that architectural cost. And you want to split in places that are easy. So what this ends up looking like is businesses as they grow frequently start with

Here's a monolith and then they split off places that are very easy to to cut architecturally. Front ends are often the first thing to go because those tend to just not hold any state. So that's a fairly easy integration point. Data pipelines. Usually only need asynchronous replication, another easy thing to pull out into its own service, and interfaces with third-party APIs, there's often a lot of code to manage that nuance that can also be pulled out with a fairly minimal architectural penalty. Now in this view, the question is where does Django help? And the answer is almost everywhere Having just told you you can use Django with JavaScript, perhaps the one quirk I want to point out here is that the front ends do not have Django on them. Um and that's because well Django absolutely could power your JavaScript front ends. In this case, we're declining

That benefit in order to have engineering parallelism. And this is the trade-off that you're making when you split your code base into multiple services. Instead of the just reduction of code that we could get by having this all in one, instead we're going for the parallelism of engineering that we can get by having different teams work on these. And so Django in this context, we're now back to a subset that we've already looked at, which is Django is just a back end. And I've already mentioned why Django can do this well, but there's a couple extras Django gives you for this multi-service context and for the engineering parallelism that you're gonna want. Even right off the bat, right off the bat, Django is actually very well set up to start with a monolith and decompose it into multiple services from the nature of Django apps

You can start with the Django project and essentially demarcate where you want those service cut points to be in the future if your engineering team grows by making those separate apps. And beyond that, Django has help for many of the things that you want for those engineering teams to be able to work on their own. So not only do you want APIs for your services to be able to talk to each other, you want documented APIs. Wouldn't it be great if your engineering teams can just do their job and not have to set up a series of meetings every time they want to do an integration? Well, I mentioned Django REST Framework and graphing Django for auto-generating your APIs from your Django models. How about you auto-generate your API documentation too, so nobody has to worry about keeping that up to date? You can do that. Graphing Django actually does that for you.

DRF Spectacular or DRF Yazgi can do that for Django REST framework. And now you have auto-generated API documentation and your engineering teams can just be off and running. How about independent testing of services? Wouldn't this be good? Um Django tests do give you all of their power for a test within a service, but for testing services that and parts of a service that need to interact with other services The typical approach is that you're going to set up either a test or a dev or a mock environment of your cluster so that engineers don't have to run a full copy of the cluster every time they want to just test changes to one service. And Django supports this very well. Django settings give you a lot of power here, especially combined with something like Django Environ to give you swappable settings and so you can run

copies of your software ecosystem with different configuration. You can say okay here it is running in production mode, here it is running in a mock mode or or dev mode. And there's a couple things that I want to be different. And all you have to do is use Django settings to do that and swap out settings for a couple settings for those different run modes. And on top of that, Django is natively compatible with API gateways like Amazon API gateway or Apollo for GraphQL. If you want to take a whole bunch of those services, like your data connectors, and group them together into one virtual API that downstream consumers can use so that they only have to swap one setting to say, okay, I'm using all the data connectors in test mode versus production mode. Finally, one of the keys to making all of this work, that data schema management, Django migrations, if you've done your architecture well and services do own their own databases, Django Migrations just works.

It works great. So Django helps so much with at least a healthy microservice ecosystem. You do not need microframeworks to do microservices. Now so far we've been talking about web web. What about the other stuff? Now Django is a web framework. At least that's that's how I think of it. But it also can do really good work even if you're not using it for web. And just to hop back a few slides, I do have the data pipeline, which is not at all web, labeled with Django back here. Um so in order to look at this, we're gonna go back to the diagram of a server, of a service, and I want to talk about the right side. Right? So far we've been talking about the left side, those API servers, whether or not they're serving.

front-end templates to the user or an API to be consumed by other services. Here we're talking about the left side, those task servers that are either doing stuff on their own or consuming tasks from a queue. And to give you some examples, we could be talking about asynchronous tasks. Django works very well with Celery, if you want to have it running tasks on demand, or with compute as a service, things like AWS Lambda pulling tasks from SQS. Django works very well for scheduled tasks. Here, Django management commands are can give you a lot of leverage. You can combine them with plain old cron, or you can use celery or equivalent to manage scheduled tasks. Django can do one-off jobs. You want to run some eight-hour job or two-day job. Make a custom management command and run that on either some container as a service

like ECS or just on some persistent server with No Hub. And Django is really good as an inter database migration tool. If you want to migrate data from some old database to a new one and do some schema changes while you're at it. Django can manage both database connections natively, and you've got Inspect DB to pull models out of your old database's schema. And then you can use Django's beautiful, powerful ORM to do Python native translations of your data and push it to your new database. Now what we're talking about here is Django as just the ORM. And really the disservice that I'm doing on this slide is the word just. That's not a just. Django's ORM is great, and on top of that, like I would use Django for just its ORM, and on top of that, you still have the migrations framework. If you're doing any kind of ongoing infrastructure, your data schema will change and having Django able to help you do that is really great.

And you get even more power if this non-web infrastructure that you're managing is working alongside web infrastructure. So if for example this is a worker environment in your service, That also has a web environment, the code sharing you get from having these both be in Django and both be, you know, in that in that same repository can be enormous. Not only can you share the models, but you can share everything on top of that, any computation you're doing on top of your models. any of that other code you have that's interacting with that data, there might be a lot of benefits for that code sharing. Django's test framework still helps quite a bit. Do you not want per-test database isolation for your background tasks? You do. And Django

settings and the swappability helps for managing multiple environments running off of the same code base. So if you have a web and a worker environment, all you have to do is change whatever few settings need to be different about those. And those can be powered by the same code base. Or if you have multiple worker environments, one for short tasks, one for long tasks, or various other styles. Django and its settings can help you do that. Now having just said that the ORM is the best part of Django, what if we take that away? What if we're not using Postgres or MySQL? What are we left with? Well what we're left with is actually still a very good framework. We still have forms, templating, routing, we still have security mixed in with that, translations, time zone support. There's middleware, there's so much good stuff in this part of Django.

That you shouldn't overlook, even if you're not using a database that works with Django's ORM. But Before you go pull that lever and eject the warp core that is the ORM of Django, you might not have to. Because Django's ORM is pluggable. Ah, modularity strikes again. Django has, at least in the community, backends for a whole variety of other databases, many of which are actually supported by the makers of those databases. So if you want to use SQL Server with Django, you can. If you want to use Redshift with Django, you can. If you want to use Snowflake with Django, you can. And as of one week ago, if you want to use MongoDB with Django, you can. That's finally out of beta. That's important.

And even if you're not using one of those, Django will still give you help on the storage side. And this might sound peculiar, but let me give you some examples If you're managing a lot of files on some cloud file storage like Amazon S3, you actually might want to include a database and use something like Django Storages in order to manage those files. What Django Storages does is it augments Django 's built-in file field to store files, the actual files on some cloud file storage like S3, and then what it stores in the database is the path to those files. And so what you can do is store against those file paths, any other data that you want to be searchable, any metadata, any relational data, and so on. But even if you're just managing files themselves, having a small database And using Django storages makes it much easier to find and manage those without having to do just path magic and and searches on S3.

If you're not storing data at all, all of your data is in some other system, you're just building a companion application for a third-party system, for example Django can still give you session management using Redis or file-based sessions. You can still have users log into your Django app and have a coherent session as they're navigating through it, even without a database. And if you're managing a lot of JSON data, you may still want to use Django's ORM. If you set manage to false, that tells Django, okay, don't try and make tables in a database off of this model. But you can still have that model and still connect it to other things in Django, like say, model serializers, in order to build an API and auto-generate API validation and things like that. In order to manage your JSON data and still get some of the boilerplate reduction that Django's ORM would give you, even if it's not going into your database, or not going into a database that Django

is managing. Now hopefully at this point I've given you at least one new idea for a way that you could use Django. Now how do you get there? If you already have a code base that isn't built in Django or you've taken on some new software ecosystem, be it You know, you've switched jobs or or switch teams or something like that. How do you get to Django if you're not there and you want to be there? Well the easy answer conceptually, not practically, is total rebuild. We got our old infrastructure over here. We're gonna build new infrastructure. We're gonna over a weekend migrate the data and swap over. Okay, people coming on the old system on Friday, new system on Monday.

All right. Total rebuilds are certainly the most straightforward way to do it. They are often practically infeasible. There's often just too much logic built into the old system. the system's live, you can't get that much downtime window, you can't get that much engineering time to do it. So two ways to do it in pieces. If you are doing if you're starting with a non-Python ecosystem or service that you want to get over to Django. You've got your old system and we're gonna build a new system that's gonna run in tandem with the old system. This is the strangler fig pattern. And so in this case, the new infrastructure is gonna be working off of the data storage of the old infrastructure. structure it. If there's an API that's good enough, we'll use that. If there's not, we're going to at least temporarily violate that service boundary, connect directly to that data storage so we can run these two pieces of infrastructure in parallel.

And the goal here is to over time shrink the old infrastructure, grow the new stuff. So any features that are new, new infrastructure. Any features that are getting changed substantially, pull them out of the old, put them into the new. And then once that old infrastructure gets small enough, we're going to do a push to get all of that over to the new infrastructure, deprecate the old infrastructure, and then we can clean up the data model. We have to wait until the end to clean up the data model because the new infrastructure is still constrained by whatever the old infrastructure was doing data-wise so that they can run in tandem. If you're working in Python, it's even easier. Because you can do it in place in the code base. And here's where we really lean into Django's modularity. We're going to set up Django settings, first of all. You need those to have a Django project. We're going to bring in Django models and then swap over to Django models for managing our database

either one model at a time or one chunk of related models at a time. You could also do that all at once if you really want to. And then move up to the API layer. Change the views to be managed by Django and Django routing, either one view at a time or one chunk of views at a time. And then you could even just leave the templates. If you're working in Python, they're probably Ginja 2, and Django natively supports that. Or you could pull in some other. you know, some other library to support other various Python templating, or you can convert them to Django templates if you really want to. Django gives so much support in a transition of this kind. Its inherent modularity, first and foremost, lets you bring in Django in stages. Also, Inspec D B, I've mentioned before, but Django can auto-generate models off of an existing database and Django

migrations Can get you started on an existing database. All you have to do is migrate fake for your initial migrations because the database is already set up, and then migrate normally from then on, and Django can take over schema management. And so many other pieces of Django are pluggable or modular or swappable. If you've got some legacy legacy authentication scheme you need to support. Do it. Swap out Django's authentication backend. If you need some other templating system you need to support, do it. Swap out Django's templating system. If you want to be replacing your your pages in stages with URL namespaces, great Django can just say, okay, this whole app has this URL namespace as a this URL prefix, and that can manage whatever you're doing in terms of rolling it out page by page.

But you can't always use Django. Sometimes there's technology constraints, sometimes even a rebuild in parts isn't feasible. So in this case, what I urge you to do is even if you can't literally use Django, Philosophically use Django. Django has five big pieces of philosophy that I want to highlight that I think are what gives it its power. Oh, we're giving away secrets here. First and foremost, use an ORM and migrations. It's that tandem that really gives you so much control over your database, the ability to write those those back-end native interactions with your database. And the ability to auto-generate other pieces from it. Nearly every language and ecosystem has an ORM, although almost none, if not none, are as good as Django's.

And one of the big reasons you want to do this is the second point, is so that you can auto-generate other pieces of your application from your ORM. Auto-generate your API or your forms and your validation for your API and your form validation. Auto-generate that from your database schema. I was working in a project recently in the node ecosystem and I really missed this from Django. And so using Prisma and Zod, we built Not quite as beautiful, but at least close enough on approximation of Django model forms. And it made working on this code base so much easier. Having centralized settings that can be changed per environment. This is just a good idea. You should do it if you're working in a framework that doesn't have it. Having interfaces for admins to self-service view and modify data. This is just a good idea. Really cuts down on support requests so you can focus on doing the actual interesting work.

And as much as possible Auto-generate or dynamically generate these so that you can get them up as as fast as you can. And then finally resetting the database between tests. That per test database isolation. Django tests do this for you. Not all testing frameworks do. It's really appalling. If you have a testing framework that can't do this easily, there's always the infrastructure hammer of creating and dropping a database before and after each test. All right, I want to switch for the last section. So far I've been talking about how you should think differently about Django. This is how Django should think differently about you. Now, while this this is advice for Django contributors, don't zone out if you're not one. This is also advice for potential Django contributors, and maybe this will be your call to action.

First a warning Django is losing This is according to Stack Overflow trends, which is a measure of how many questions or what fraction of questions on Stack Overflow get asked using various tags. And according to Stack Overflow Trends, Django beat Ruby on Rails in popularity in 2017. Congratulations. And we were on top for six years until 2023 and we are now losing to Next. js. Now there is one major compound to this, which is this is the questions people are asking on SAC Overflow, not to say these are people actually using the technology. So maybe it's just that Django is better documented. Or maybe it's that Django hasn't added that many wild new features and most of the features have already been discussed on Stack Overflow.

Or maybe it's that Django needs a JavaScript strategy. Django is 20 years old as a framework. I would like to see it make at least another 20. And in order to do that, I believe the Django needs to accept the JavaScript as part of the web. So First and foremost, the most urgent and most straightforward change that I believe Django should make is to support JSON APIs. And this is not just for JavaScript. This works great if you're having a Java JavaScript single page app. This is necessary if you're building even inline JavaScript that needs to make backend calls. you know, to some API. This is necessary if you're doing mobile. This is necessary if you're doing a multi-service backend.

This is necessary even if you're building a monolith and you need to present an API to other third-party infrastructure. Django should do this. People want to do this in Django. And Django is so close. Django forms are actually really close to doing what they need to do to generate JSON and validate JSON coming in. That's not the only way to do it. If it were up to me, I would say let's push Django Forms that little bit extra to be able to do JSON work as well. We could also make a separate set of classes, maybe call them serializers. Just maybe. And then Django needs a set of class-based views in order to manage REST APIs. This is proposal one.

Now if this is unpalatable because the community has already solved this problem with Django Rest framework, then let's absorb Django Rest framework. There is precedent for this. This happened in Django 1. 7 when Django absorbed South and it became Django Migrations. Thank you, Andrew This was a huge upgrade for Django. Django could do it again. Django should do it again And even if that is too politically complicated, option three is not my preference, but it is on here for completeness. Django should at least officially endorse Django REST framework as a solution. The Django docs currently have zero. Mentions of Django Rest framework, despite the fact that it is currently the community's answer to this problem.

Alright, this is the easy one. It only gets harder from here. Next up, Django should have some way to actually support JavaScript on your front end. People want JavaScript front ends with Django. It is a little harder with React than say Viewer Angular. And whether or not Django, it would be complex for Django to do this itself fully, but that is not to say Django doesn't have any responsibility here. I think what Django should do is have some infrastructure to do this, the scaffolding, those plug points that third-party libraries can hook into, and then officially endorse some third-party libraries that do this. And the model that I want to suggest here is the way that Django does static file handling. Static files is a pair of things. You got a management command and a template tag.

And this works great for static files. This doesn't work great for JavaScript because JavaScript is more than just static files. So the management command would be something to do your JavaScript build. And this should be configurable because people are using Webpack, they're using Vite, they're using all kinds of things to build their JavaScript assets. I don't assume that the JavaScript community is gonna settle on a on a builder anytime soon. So that should be pluggable. And then Django should have Some infrastructures have template tags to embed these types of front-end components or directives onto Django templates and pass them back-end data. And this is really easy for Vue and Angular because passing back-end data is often just passing in data as HTML attributes. So Django is pretty good at that. But the reason to have this pair and the reason for Django to actually be responsible for the JavaScript build process is the same reason Django

is responsible for the static file collection It's so that Django can know where those files are and what form they are in in order to have them integrate seamlessly with that template tag. My last three ideas, a little less well specified, but not to say less important. Django should have more guidance on how to host a website. This is one where it's slightly embarrassing that we are behind Next. js. They have an entire hosting menu on their docs, despite the fact that Next. js is made by a hosting company. They actually recommend a whole bunch of options beyond just hosting on the company that makes Next. js. So if they can do that, so can we.

My last two ideas are really out there. But I wanna I wanna still want to put them out for completeness. I think that Django Forms would be so much better if they thought about JavaScript. And what I'm talking about here is The type of thing that I showed you back with combining Django forms with Vue. If Django actually had some intentional JavaScript support built into Django Forms directly so that you could do front-end dynamic forms and shared front and backend form validation with those forms. Again, not necessarily building all of this into Django itself, but at least having the hooks there in Django. So that there are third-party libraries that could tie into those, and then having Django officially endorse whichever of those third-party libraries the community builds consensus around

could give Django forms. a whole decade or more of new life. My hardest idea and wildest would be for us to partner with one of these front-end frameworks. And explicitly become a recommended or official backend, like Next. js is for React, both to get the referrals from people saying, oh, well, I'm using this front-end framework, I should check out Django, but also to get the tighter integration that would come from one of these partnerships. But bringing it back to you, you should help Django get there. But you also shouldn't wait for Django to get there. Hopefully I have shown you in this talk ways that you can yourself, through Django's modularity and pluggability, address these use cases yourself with Django in its current state.

You can use Django with JavaScript. You can use Django as just a backend. You can use Django in a multi-service environment. You can use Django with other databases, and so much more. That's all I have for you today. I'm going to be out in the hallway afterwards for questions, but if you don't get a chance to catch me, here's my email. Here's a link to my slides. Happy to talk about anything in this talk or beyond, be it the future of Django or the future of how you use Django. And if you do need professional software help, I do run a software consulting company, so feel free to reach out to me about that as well. Thank you