Rewriting Django from almost scratch in 2021 | Emma Delescolle

Speaker 1: And hello, everybody, and welcome to this talk. Um So before we get started, first of all, who am I? My name is Emma. I am the co-founder of a small Belgian company called Levik. I have had the honor to be chosen to be a DSF individual member. And I'm also the maintainer of two projects, DRF Schema Adapter and Amber C Likeities. And I guess after this talk I might be also the maintainer of CORDI. So rewriting Django from scratch, huh? Why wouldn't one want to do that? Or as someone asked me m yesterday, is that even serious?

Speaker 1: So well yes, it is it is serious and uh Why would they want to do that? Django is a project that's 15 years old. So at the time of its uh creation, some decisions were made. And those decisions were made in regards to what was expected of a web framework at the time and more specifically for a expected of a web framework for a newspaper Those decisions were also made in regards to the resources available at the time and the climate in which these resources existed in. What is being done with Django today is far from what was initially foreseen by the creators

Speaker 1: Back then, a web framework, a website, or even a web application was centered mostly around request response cycles even if we still use those today and the talks of yesterday afternoon showed us that people want to keep using teas extensively. Um but the web has shifted to rely a lot more on APIs and WebSockets, which was really not a thing 15 years ago. APIs did exist, but they were not used to the extent that they are today And from my experience, and everyone may have a different experience, the Python world uh was also a lot less friendly back then. Pull requests were often ignored, package maintainers were often vooed by default, and documentation was lacking

Speaker 1: a lot of the time. All this to say that it made a lot of sense to write everything in-house for Django. And if you look at it, Django has surprisingly very few dependencies. With all that in mind, I had to wonder, but what if Django was being written today and leveraged the ecosystem, which is now available to us? Times have changed. Well, first of all, there's the obvious. If this was a talk I was giving 15 years ago, you would be all in front of me, live in the flesh, cheering for me Okay, maybe you would not be cheering, but uh at least you you would

Speaker 1: you would be uh politely applauding in front of me at the end of the talk. Um While now we've been stuck uh here uh at home for over a year now. Um Some people got bored, uh some people's life changed. We we adopted three cats. Um and now uh you are still going to be uploading, but you will probably be uh pasting some blob blob clap uh emojis uh in the chat instead of having actual clapping noise actually putting your hands together to to uh to to clap And um but the Python world has also changed uh for the better. And this is in part

Speaker 1: thanks to the Django community and its values. So if we look at what is different, I would say that first of all package documentation seems to be much better as a whole. The community, the whole Python community, not just the Django community, is friendlier, including package maintainers, big names. uh you've probably been able to uh see or interact with uh some package maintainers some former core developers of Django and things like that uh which is not something that you would have been doing 15 years ago, especially not uh interacting with Django maintainers since uh Django

Speaker 1: was just being written. But um As there was also a lot less in terms of web framework at the time, John Kogo had to sometimes rely on using Rails as a reference. If you scroll through the early commits and bug reports, you can see that Frails is being mentioned a few times But no, Django itself is used as a reference and it has inspired a lot of people, it has inspired some libraries, and it has also become a model of community spirits. So these considerations were enough to start me on a journey, an experiment if you want.

Speaker 1: to write a framework in the spirit of Django, but using the libraries that are available today. Now I would like to take you on a tour of the highlights of that journey. So let's start with the libraries. The ones I discovered and the one I rediscovered along the way. So for most of these, I will be showing some code examples. And I will not go through the code examples, but feel free to look at them. And they will be showing how things are done right now in Django and how things could be done using the library that I'm featuring. So let's start by the beginning, getting your Django project started.

Speaker 1: With Django, we do that by populating a customizable project template. But Cookie Cutter is the brainchild of a renowned Django contributor and book author, and it does just that. It lets you uh start project from a template, not just a Django project, any project. Interestingly enough Some other web frameworks use cookie cutter. If you have ever tried Pyramid, for example, Pyramid provides in the documentation several cookie cutters to start a Pyramid web project. The next step after starting a project is usually to define your models. Django Zorm is very friendly for you.

Speaker 1: And as far as I'm concerned, it's much nicer than to use than the mainstream Python RM, which is SQL IQ. And I think I'm not the only one to think that because I've heard quite a few times at uh Django cons or other conferences people asking if it was possible to use Django's RRM outside of Django. And apparently there are enough people who ask that question because some other people, or should I say, Django contributors Seem to think that it was a good idea to create an ORM inspired by Django, very similar to Django's RAM, and to publish it and make it available as an independent library.

Speaker 1: Up until last year I had never heard about P, but I'm really glad that I found out about it because uh using PWE is bringing the friendliness the friendliness of Django's RM to uh the whole Python ecosystem and you can integrate uh What looks a lot like Python's ORM into any of your Python projects. If you see the code examples, this is very, very similar to what you would write in Django. And the said most of the syntax for querying and things like that is also similar to Django.

Speaker 1: No, once you have written your models, um you have you enter a bit of data using the admin usually. And the next step is to write a view to display that data in a friendly way. And when you write a view, you write a template. And here again we have a library that was written by a Django contributor. And which some of you might be familiar with. It's called Jinja. Jinja is a templating framework. It is very similar in syntax to Django's own templating language. And it is also compatible with Django since version 1. 8, I think. But JinJi is also available as a standalone library and can be used in other projects

Speaker 1: But once you get a bit deeper into your project, you usually have to make changes to Django's default settings. I think things like uh third-party apps, middlewares, uh some configuration values and so on. Django's configuration system is once again one of the nicest ones around. nicest ones around. It is easy to use compared to other solutions and sometimes you wish that this was available for the Brighton project Well, it can be. Django inspired another library, simple settings, which works exactly like Django's Conf settings modules.

Speaker 1: Another file that you find yourself editing quite quickly in any Django project is your URLs. py file. As far as I know, Django was one of the first Python projects to adopt a router in the style of Rails or Laravelle. I'm not sure if it was an original idea or if it was inspired by those languages and framework. But what I know is that for Django 2. 0, the routing system got a serious lifting. to accommodate for uh frontier or URL patterns. And uh no, this means that you don't need to know about regular expressions to be writing a URL in Django. Once again, this is very similar to Rails and Laravelle.

Speaker 1: But it turns out that there is another library that does that very well. And it is simply called Frouds. And it is a built it is built as a re-implementation of rails routes systems, but in Python. But all of those are quite classic in term of what they do. I said at the beginning that's uh of the talk that uh in today's web a framework had to give an important place to APIs. And who says APIs says serializers Marshmallow is a popular serialization tool and as such it has a lot of extensions to make it compatible with other libraries like Peewee, for example.

Speaker 1: It also has some extensions that add features like autodocumentation of the API endpoints by taking information from the serializers. It can also be used to parse some data from different locations like the JSON body, from data, URL parameters, and so on. I've not followed the project closely, but for the ones who are interested, I know that some people put together a marshmallow extension to work with Django and Django Rust framework Once again, the syntax used by marshmallowlow , once you get past the fact of calling everything schemas , the syntax of marshmallow

Speaker 1: is very similar to the one of Django Rest framework. But back to the basics. Even REST APIs rely on the request response cycle. So is there a Python library to help make that easier? Of course there is one. WebOp is a quite little library that traps whiskey requests and responses into more friendly Python objects. Once again, they are very similar to Django's old request and response objects, not only in purpose, but also in syntax. Now here we come to one of my favorites, Click.

Speaker 1: Click is a common line parser library, which is often often overlooked It comes after the one used by Django , which is Arcbars, that I can never pronounce correctly. So just for that reason, I would wish to be using click instead. Although I guess that to say true to Django, you should keep using ArcBors, but I find click friendlier and more flexible as well. It's uh its syntax is different from the one uh used by Django's Management Commons. It uses mostly decorators as you can see in the in the code samples. And

Speaker 1: with those decorators you can specify options, arguments, or other information like help text and things like that. Thank you, Daniel , for liking click. And like Django, it is highly configurable, but comes with sensible defaults out of the box. No, at this point I have to make a small parenthesis. I am not the first one who thought about rewriting Django from scratch This is actually somewhat close to what is being done right now in order to better integrate WebSockets and async coding with Django. And I've talked about that with several people and during those talks uh

Speaker 1: there is a uh subject uh that came that came back and back and back It's uh the subject of middlewares. Uh why use Django middlewares when there is uh already a concept called whiskey middlewares And why rewrite a lot of things as Dango middle words when they already exist as whiskey middle words? So What is a whiskey middleware? It turns out that whiskey middleware is nothing else than a fancy wrapper. uh with a set interface. A whiskey middleware receives the environment. So basically the whiskey request and a handler.

Speaker 1: A handler is your your application, it's it's Django itself. And when executed, it has the opportunity to make changes to the environment, to the request, before it is passed to the application. And you can also make changes to the results, like the rendered web page, once the application has run. it is still your responsibility, still the application's responsibility to call the middleware. The application has to there needs to be code to call the middleware. It's not magically called by whiskey. It's just a convention to have functions that can act that way and that can wrap around your main application.

Speaker 1: The main applications role. The role of Django is in a I'm going to simplify this, but the role of Django is to match the URL in the environment in the request to a view and to call the view with uh whatever parameters it was able to get from the from the request URL and as well as the the rest of the things in the request itself like the body and so on But it is still the job of the application to uh wrap that handler, that handler of a request into the Whiskey um middlewares. But

Speaker 1: before we go any further into middlewares and seeing how Django handles things, uh I do want to mention two uh very uh useful middlewares. One is speaker. It is used to handle everything that is related to sessions. And it is indeed a very nice library that already exists. And there's also static , which you might have guessed from the name. It helps you handle static files. And I should have put my tablet, do not disturb. Static handles uh static files, uh probably mostly during development, since uh in production you want your uh Nginx or Apache server to do that for you.

Speaker 1: So Django middlewares are just and I am thinking just a fancy whiskey middleware wrapper. uh as whisky middle words uh they receive the handler so the the application itself the rest of Django um And uh it receives that uh with the request, uh it receives that at initialization time and at risk request time at execution time it receives the the risky request Or uh in the case of Django, it receives the uh the request object. Uh where it gets really interesting is that um The middlewares, Django's middlewares also provide other hooks to be able to interact with the request and response objects.

Speaker 1: Like uh right before the template is rendered, you have your response object You have the context, you have, but the the re the the response is not rendered yet. So you can inject things in your context and things like that. It allows for much more flexibility than whiskey with uh middlewares. And uh they're still compatible with uh whisky middleware since their uh interface is quite uh similar. So you can easily wrap an existing whisky middleware into a Django middleware. So the next other big thing that Django was not originally planned for is WebSockets. Web sockets or permanent connections

Speaker 1: that work uh asynchronously most of the time. And um depending on what they're meant to do, uh they can be linked to a pop sub system like Redis. Unfortunately, sync and async codes don't mix well in Python This is why a lot of effort is being put into Django to make it play nice with async native applications. and async native code. And for that we have a new standard which is ASCII and we have servers like UVCorn and Daphne. But those are still very young. Now if you're going to couple your web framework with a starsky

Speaker 1: application server I would rather couple it with one that is being tried and proven. And it just so happens that U Whiskey, one of the best established whiskey servers , Provides some proprietary, and when I say proprietary, I mean something that is not part of the WISCI specification. It provides handling of web sockets in a synchronous way. So If I was going to tie my framework to a specific Storsky implementation or Storsky provider, I would probably think that QWISKY is not a bad choice. But back to regular features now.

Speaker 1: One of the things Django is famous for is its admin and its ability to generate forms from model with very little code. So that too can be done with other libraries that exist out there. But since we are focusing on APIs, why not go all the way? VJSF, VIDI JSON Schema Form, is a view component that can run directly out of a CDN and provides form for REST API as long as the API can provide a data structure in the form of JSON schema. As I mentioned earlier, Marshmallow comes with many extensions. And one of them is Marshmallow JSON schema, which provides JSON schema information for marshmallow

Speaker 1: series. And uh in the way of uh doing JavaScript without writing any any JavaScript, uh you can use uh your API, your existing API dump the JSON of the that comes out of that API into uh a document and also load uh those libraries directly from CDM not write any code and have a form being rendered. So Is that it? No, we put everything in the blender, we turn it on, we pour it in a jar, and we have some new Django. Well, not exactly. It could not be that easy.

Speaker 1: There are some missing links. Um and there are things that are not provided by libraries, or at least there are things that I could not find. uh that were reliable enough and could be plugged into something else and existed like that in the ecosystem The missing links I found were those. I could not find any library that provided C cure CSRS in a framework agnostic environment. Authentication and authorization also seem to be the sort of things that you can't find in the library format. And but there is a there is a whiskey middleware that provides some authentication methods, but nothing close to what you would expect from a framework like Django.

Speaker 1: The admin. It's a subject that has been carefully avoided so far. And well basically there is no such library. The admin is unique to Django so far. And finally, putting everything in a blender is not going to be enough to get everything to stick together. We are going to need some glue code So are there solutions for that? Well, as far as CSRF and authentication are concerned, we can simply reuse the existing codes from Django. Remember the title. This is a rewrite almost from scratch. The admin, no, I know this is a touchy subject, but uh While being one of the most appreciated features of Django, the admin is also the least understood and the least trusted.

Speaker 1: Remember, never expose the admin to end users, we cannot guarantee anything. So I vote for getting it rid of it altogether and replace it by something that leverages the rest of the framework, something like Django admin 2 that uses regular forms and views to provide an admin-like interface. Finally, the glue code. Well The glue code is what I've been doing while I was bored during the pandemic. And it is called Cordy. And it even has a mascot that's to tell you how deep into the rabbit hole I went. So first of all, the name Cordy.

Speaker 1: It's an homage to uh Annie Cordy who 's a Belgian singer and actress who died in 2020. It's infitting, given that Tango is named after a guitarist. There's also a pun in there of course because uh cordy chord, uh like guitar chord, yep, sorry Um the mascot is simply a chord or rope that acts in a Python as well. And I find it cute. So Cordy, Cordy is the code I wrote to vope in, sorry, this is the last one, I promise, to vopin together all the libraries I mentioned before.

Speaker 1: It is not much code, all in all, uh, but it's about uh it's less than uh four thousand lines of code. uh excluding documentation and tests because I didn't write any documentation and test. But it deals with most of what I mentioned before and also a few extra things like migrations, for example. It all started as a thought experiment. I'm glad I did it and hopefully that journey taught me more about Chang. And I hope it is useful to you others as well. It seems very timely since uh the technical committee for Django 4 is being put together right now uh as far as I know. And maybe someone will think that

Speaker 1: my weird ideas are not so weird after all and that they might try to put them in practice into Django 4 So we'll show you a few good examples of working uh code for Courtdy In my opinion, it is very close to what you would write in the current version of Django. So here you have a models example. You should probably look more closely to the to-do model. Next we have controllers. As a side note, I I really couldn't resist and uh I had to go back to the MVC terminology, model view controller. Instead of Django's MV key model

Speaker 1: view template. But I did keep some of the usual Django class names, or rather Django REST framework class name, like view sets. The last controller on the left uh makes heavy use of decorators. I'm not sure I have a an opinion on that. Um it's Something that you don't do a lot in Django, but it's worth uh it's a feature and why not use it. And on the right you see a WebSocket controller That is quite similar to another controller. Its entry point method is connect and as from here it looks rather simple. Finally

Speaker 1: , this is a full URL. py file. It is not exactly the same as Django's URL. py, but I don't think it's hard to read either. Uh notice the star unpacking syntax uh for the two first uh URLs that um That are uh a way to use get routes, which will uh get all the routes directly from a controller. So controllers are what you would say are class-based views right now in Django. And uh the route before last, which is a WebSocket route, and it is just declared as any other route in the project. It doesn't care that

Speaker 1: it's a WebSocket. And uh with the code that I just showed you right now, um you what you can do is that you can uh write uh list views and form views like you would in Django. And you don't need to write any templating, the those templates are already included uh in CORDI. And um So all in all, it's not that different after all from the Django Admin. So in conclusion, what would be the pros and cons of rewriting Django from scratch and using those libraries I mentioned? Well, the biggest con, I guess, is the loss of agency.

Speaker 1: You are going to be depending on other library maintainers And uh I guess one solution is to fork those libraries, but that's not the friendly way to go. Um but That that con is also a probe because right now you have a lot of libraries uh that already have maintainers, people are working on it, and all those people would uh by extension be working for Django. And that would make maintaining everything easier too. But using those libraries, at some point there will be some loss of backward compatibility. And of course you would need to uh do a rewrite if we

Speaker 1: rewrite. But as I mentioned, CORDI so far is less than 4,000 lines of code, so it's not that big of a work Finally, um I am now going to uh go uh into Jitsi for the questions. But uh before going there, uh I mean I did mention that I adopted three cats, so I had to show those cats to you. So the first one is foot. is the smallest. Shell , she's the female ones. The other two are boys. And Curry. Curry is the fluffy one. So during the Q<unk>A in Jitsi, I will also be streaming

Speaker 1: a demo application. It's a game based on Splendor, for the ones of you who know that. And uh I played it with a few people already yesterday. I will paste uh the link to the game in uh in uh the Slack and you can all play uh the game uh it's a demo so don't exp there are some features that are obviously missing but it is a project that was written entirely with cordi and that seems to be working quite fine. Thank you for listening Hello everyone. I hope you enjoyed the talk.

Speaker 2: Yeah, it was very good. Thank you, Emma. It was really interesting.

Speaker 1: Thank you. I guess you're one of the people who who is going to be involved in the rewriting in writing Django 4

Speaker 2: Well, I I'm certainly I, you know, I'm there sweeping the floor. I'm like the Maris and I like the janitors. I don't know about rewriting. Um I think, you know, Jang Django is very stable, right? So one of the big consideration one of the big considerations we have is the backwards compatibility. Um I I my sort of My kind of one thought is is it with the API stability policy, is it at all possible for us to rewrite on this kind of scale

Speaker 1: Yeah, I don't I don't think I don't think so. Uh uh you probably won't be able to rewrite on that kind of scale, but uh as I understood there's uh some rewrite that has to be done for async uh compatibility at least. Um

Speaker 2: Yeah, I mean yeah the async is an opportunity to look at that core um request response handling and to look at the ORM and you know, um think about what we can do there.

Speaker 1: Yeah. So I guess a lot of people got here. Does anyone have questions? I don't see any questions so far.

Speaker 2: Uh God, I'll I'll ask you a question then. Okay, so um Just thinking about the the dependency on other packages. So one of the one of the sort of historically nice things about Django is you pip install Django. you don't have to then go and find the form library and the uh the middlewares and the uh no all the components. You don't have to go and separately find those and contrast that to the experience in the say Node. js world where you know it's nor the the norm is to go and pick you know craft your hand collected your hand picked package libraries and dependencies um Is that kind of a a change of that would be I mean that would be a change of style or or would do you envisage the um that list of being curated for you.

Speaker 2: So you've still got pip install cordial pip install Django and you get that you get everything you need.

Speaker 1: Oh yeah, that that list would be curated. Um I guess you could in envision uh if you want to go uh with the the the pyramid route I guess you could have uh different uh versions of that list. Uh like I just want Cordy, I don't want URM, I don't want templates, I don't want anything, I just want that I guess that that list could be created for you uh in in several versions. But right now I published uh Gordy yesterday uh or the day before uh on pip. So you can pip install cordi cody and it will install everything, TRM, uh the templating engine, everything. And yeah, it when you do that, it looks more like a a Node. js project where it does have a lot of dependencies

Speaker 1: that get installed. Um But yeah, I I I don't know. I'm not uh I'm not the maintainer of such a a big project as as Django. So um As I said, I think there are pros and cons uh to depending on other libraries. And uh yeah, what is sure is that right now Django does not depend on a lot of things.

Speaker 2: Yeah, no, I mean it's it's just interesting, is that that kind of uh that ability to find the packages. Anyway, but thank you, yeah, that's super.

Speaker 1: You're welcome. uh Pablo you're raising your hand

Speaker 3: yes thank you Emma for your talk was very very interesting uh I didn't know so many different packages to do what you have done and what you showed. I want to ask you a question similar to the one that Carlon uh Carlton um have done so um the you afraid to rely on so many different packages all around the Python uh package index. Uh it's something that's usually scare me and is the main reason and I prefer to contribute to the core of Django instead of

Speaker 3: creating different um packages more than one um uh had trouble updating uh and uh being able to uh uh up to date different packages. I don't know if someone here have ever used Plone. It's basically a very old uh framework and it it's The main reason I ended uh using Plone is is because it was uh release on so many different packages based on Zoop and XML and at the end Yeah, I I've spent more time

Speaker 3: uh um having all functioning together than developing new part. So is the main is um I think I like a lot in in Django is there is so few dependencies and rely a lot on standard library. So uh the question was are not you scared to rely on so many different pages?

Speaker 1: Well first of all Plone is is special I'm still not sure how to install Plone correctly. I'm still not sure what is the correct way to install Plone. I'm sure it's not just piping stall. So yeah, depending on uh being dependent on many uh libraries is uh something that can be scary Uh one solution uh I give if some library is not getting is not getting um updated in time and things like that, uh it's still a possibility to fork that library uh and to have a Django or a Cordy version of that library. Uh

Speaker 1: that's that's one solution. Uh because uh the the biggest benefit of using libraries is that you have um human time you have human hours that you will not be putting into developing into writing those libraries. So you have uh extra hand power to uh be able to do those kind of things like forking uh an existing library that has been trusted by the maintainer or uh instead of forking having a friendly takeover something like uh jazz band does Um and that's th that 's so some solutions I see to that problem.

Speaker 1: Um Given that everything is open source, uh I I don't see that it would be a blocker. I I I Can see that it would be annoying, especially if you have one of those libraries that but then you have to to choose your libraries. If one of those libraries is uh maintained by an unfriendly maintainer uh that doesn't um merge p uh merge pull request or doesn't want to hear about your project that's using the library. That that's one of the main cases I can see where it can be a problem of uh depending on so many uh libraries But I've also been working in in JavaScript

Speaker 1: and uh this is uh this is something uh that seems to be working for them. Uh so Why not? Um

Speaker 3: okay, thank you.

Speaker 1: You're welcome I see that uh Johannes is also raising his hand.

Speaker 4: I don't have a camera, sorry you can't see me. Uh let me let me start by saying great talk and great initiative, and I'm really excited to see what's coming out of this. Um I just want to point out one thing that um I like about Django and that is um I think hard to achieve in a library situation. And that's the cohesiveness of Django. In Django, every part feels like it's been designed with the same goals in mind and with the same uh structure in mind. So when I switch from the models to the forms, it feels very natural that these two parts go together. And that is already a problem if you go to even slightly different libraries like the Django Rest framework. It it's quite obvious that Django Rest

Speaker 4: framework is designed with Django in mind, but it doesn't feel exactly the same. It feels like it goes further or it goes beyond the feeling of Django. And this cohesion, this cohesiveness is one of the things that I like very much about Django because it makes it easy to switch from one part to the next. So I think this is going to be something that's very hard to maintain in a library situation.

Speaker 1: It is indeed harder to maintain in in a library situation, but uh If you remember the first uh three or four libraries that I mentioned, they are developed by either Django, uh Django maintainer, Django uh Cordie X Django core developers or uh they were inspired by Django. So they they all have that uh Django feeling uh that comes with them Um now one library that I mentioned that really doesn't feel like Django is the routes uh library. So the the the library that does the routing. But it feels like Rails, and I'm still pretty sure that uh

Speaker 1: the routing in Django is trying to feel like Rails. Um so Yes, there are there's gonna be some some differences like um marshmallow. I'm still not over the fact of calling everything schemas. That's That's something I have a hard time with coming from Django. And that that doesn't have a Django feeling. But Honestly, by selecting by carefully selecting libraries, and I'm not saying that all the libraries are mentioned have been carefully selected. In for a real Django Vite, I would have looked closer at things like

Speaker 1: does the library have a code of conduct? Is the maintainer nice? And things like that. Which I didn't do in this case. Um but by selecting carefully selecting the libraries and eventually forking the ones that don't meet the criteria, I think it's possible. to achieve that cohesion, that Django feeling uh for whole thing.

Speaker 4: Yeah, yeah, so I think I think it's possible to achieve that too. And Um I see this as a challenge and as an opportunity because as you say there are these impulses that uh come from outside or that that come from the other frameworks and that we should really think very hard about. So This is something that's both positive and negative. So yeah. All right. Thanks everyone.

Speaker 1: Yeah, definitely there are pros and cons. Absolutely.

Speaker 4: Great. Thanks.

Speaker 1: You're welcome Um anyone else has uh question?

Speaker 3: I have a question. Uh I I I'm a curiosity. Uh you are long time uh Chango uh user and so a lot of your presentation and talk I so I think you know uh Django pretty well but there is something you learned in this uh experiment to write in Django about Django itself. I don't know, trying to search for alternative packages to replace. feature and you uh found out new things about Django in this process.

Speaker 1: Yes, uh there are two things I I found out about uh well that I learned about I uh did a deep dive into the middlewares and what were middlewares and um I didn't know that Django middlewares were so close to the concept of whiskey middleware. I didn't know what the whiskey middleware actually was before doing this. Uh so I learned a lot about uh this uh middle order, the way middle orders work. And I also learned a lot about uh the request response cycle and how uh that is being handled in Django, uh the order of doing things and how

Speaker 1: How do you handle a whiskey request that that comes in? What is a whiskey request? How do you handle that? How do you turn that into an object? And uh then what do you do? Um how does the the routing and matching that request with the routes work um and all that the I had never uh really uh delved that deep into uh the uh um the ural pattern matching Uh so I I did a bigger dive in that. And uh yeah those are the two main things I guess I I learned about Django during this uh this experience.

Speaker 3: Thanks.

Speaker 5: Hi Emma, thanks. Thanks for the very interesting talk. Um I I was wondering, um I'm curious, have you considered um or have have you had a look at Fast API and and considered if that could be a starting point? Um Because you know it's it's API first, it's using Pydentic for um model validation and serialization. Um Have you thought about that? Um what what's your thought?

Speaker 1: I I did look at it. Um I have um so The the main thing I have uh against uh fast API is that right now it's um It has very little support for uh authentication, for example. Um and uh I've had some issues with the database package Uh so I I don't think it's ready. I and I think that's mainly because of the challenge of making uh everything a thing. And as I say, mixing sync and async doesn't work well uh in Python.

Speaker 1: And so uh this means that fast API um can have trouble uh integrating with other libraries, uh existing libraries because of the uh sync nature of those libraries So uh fast API can do both sync and async, and so if you're writing a sync method, you can you could you could use Peewee uh with uh with that, but if you're writing an async method then you cannot use PWE and you need something around that. And that that for me is uh is an issue uh with Fast API right now. I know that um Um I forgot his name now. Uh the the maintainer of uh Django

Speaker 1: Rest framework. Uh I know that he's working a lot on uh the package that's called databases to make uh to to to make that abstraction easier. But right now it's it's not possible. And uh regarding pedantic, um I like the concept, but I find it way less flexible than uh Django. uh that what Django has to offer. For example, you uh you don't have a type, you don't have a Python type for a URL But in Django you have the concept of URL field. Um and you have so many more uh fields that are

Speaker 1: uh easy uh to uh to uh to access field types that are easy to access that you are not uh getting by using uh strong typing only So I see the I see the need of something uh something like um like marshmallow to do the to do the serialization and the validation uh because that's something that's lets you do m things a lot more uh in depth that what you can do with uh pedantic or if you can do this with pedantic it will be a lot more work to achieve the same goal.

Speaker 5: Yeah, that that's very interesting to get your view on that. Yeah. And and I and I see, and I I I can see that, yeah, those those points that you mentioned. Mm-hmm. Okay, thank you.

Speaker 1: You're welcome. Anyone else? I think the the next talk is started.

Speaker 3: Yeah.

Speaker 2: I don't have any more questions, Emma, but I do want to say thank you. It's a really interesting talk and interesting discussion afterwards. It's you know it's Yeah, I I don't know how much we can rewrite the core of Django, but it's really nice to to take the um the possibility and think about you know how it would look and what would how that would go and you know

Speaker 1: yesterday yesterday someone asked me do you do you expect this to become Django four Django five? I said no. I don't expect somebody to take that code and turn it into Django. That's that's not that's not the the purpose of this. But yeah I think there are some ideas that are worth thinking about.

Speaker 2: Yeah super. Thank you.

Speaker 1: You're welcome

Speaker 3: It could be interesting to know which parts you found in other packages that we can reuse in Django in the core. Especially now that we are writing so uh new new code for the async part and there is Also new packages in the Django Foundation um group like Django channels and similar so can be interesting to understand which code to take inspiration from and not reusing but also uh being inspired to to to to improve Django

Speaker 3: or also to simplify some part of Django.

Speaker 1: Well to to simplify Django I think uh Pee-Wee is a really interesting package to look at because Pee Wee is being done to look like and feel like uh Django's RM It's been done by a Django contributor and Django's RM is uh is the one part that I've heard people asking the most if it's possible to use the orm, Django's ORM outside of Django. Um And next thing that I've heard people ask about is uh Django Forms Can you take Django forms outside of Django?

Speaker 1: Can you use Django forms outside of Django? And so writing Django Forms, rewriting Django Forms as a Pee Wee plugin, uh like there is a Marshmallow plugin uh for Pee Wee. I think that that could make things very interesting and that would uh that would help all those people who have been asking those questions about Taking the orm out of Django and using that, uh taking uh the forms out of Django and using that. Um I've I I've worked on another side project uh which is um a pot uh a podcatcher

Speaker 1: uh to listen to podcasts and uh When I realized that I needed a database, the first thing I did was use Peewee. So I think that that is a really interesting library. And uh being able to uncouple uh the RM from Tango, that that would I think that would be uh a super nice feature. And I've also seen some talks about uh people trying to use uh SQL alchemy with uh Django. Uh so Maybe uh seeing something modular as with the templates, uh with the templates engine right now and have the concept of a an ARM engine that could be pluggable into Django.

Speaker 1: I I think that that might be a very interesting idea. I think it's a lot of work uh but I really think that that could be a a very interesting idea

Speaker 3: okay thank you very much again

Speaker 1: you're welcome

Speaker 3: Bye.

Speaker 1: Bye.

Speaker 2: Right. Thank you again, Emma. I'm gonna chop on to the next one. Thank you. Thank you. So good.

Speaker 1: Thank you. Bye.

Speaker 2: Take care. Have a good day. See you around.

Speaker 1: Have a nice day.