One more time about µDjango

Speaker 1: Yeah, I'm happy to be here and I want to present my talk, uh MicroJenga. And uh before I start, I want to say a special thank for uh my family for sabbat thanks to my wife Elena thanks to my children Mark and Paia thanks to my animals Marcel and Kisa And special thanks for my children, Mark and Maya, because they create full illustration for all my presentation in last two years. Okay, thank you, Mark and Maya.

Speaker 1: And short uh information about me. Who I am, my name is Maxim Danilov, and uh I am Python and Django developer many years and uh I love reactive uh front end frameworks and also m last only in last year I provided around six thousand five hundred minutes like a mentor for newbie developers, Python developers for free. It's around 25 minutes in a day without a break Don't forget empty slots are available. You can ask mentor again. Okay But what is microjango?

Speaker 1: The important idea. Important idea about microjango is we have project with single PI file. And we have full Django functionality and it's runnable standalone, it's runnable in uh monolith, and it's testable. How it possible? This is an example from mine PI. You can see there is we have import. We have declared uh we have declared view and we have uh declared uh uh oral dispatcher. That's all. How to run it We can use Ubicorn.

Speaker 1: We need to set up properly the environment settings and At first, don't forget to have settings. There, uh Django settings module should be finded. And this Jenga settings module is the same file, mine PI It means I don't have any settings PI. And after that you can run uh run it with uh Ubicorn uh with uh special uh with special flags and of course you can run it uh if it async with multiple workers and you get the async single file

Speaker 1: Jenga endpoint. That's all. You can see how it works and it works normally And um this is uh already already normal normal st uh style or normal standard To write teeny small entry points uh which build it on Django. And um if I start to compare, there is uh m with uh with famous uh different other Python. uh web uh frameworks of course we can compare it for example micro Django uh put it in uh in container In Docker

Speaker 1: , the image of Docker takes around 50 megabyte and in code it's written five lines of code. For example, for FastAPI, example Hello World, it takes uh 75 megabytes in Docker container and uh it uh um takes our also five lines of code. This is about the repository or storage, and this is about the code lines, quantity of code lines. But what about performance? In this case about code lines we have uh inputs We have also the

Speaker 1: view declaration and we have also the Ural dispatcher declaration. And uh what is about performance? Um uh I compare uh Django and uh different other Frameworks like a lightestar or robin uh Python frameworks which written on Rust And on the other live session, I compare micro-jungo paradigm with FastAPI. You can find it in the internet and I can say it's comparable. But uh don't believe me, check yourself. And history about micro Django. This is important. The birth of this uh technology happens in 2000

Speaker 1: 2014. And important is this technology was completely clear described in 2014 with in the book Lightweight Django. And this style, coding style with Django framework, uh takes a name lightweight Django. After I met this technology in 2015, because I came to project which builded on this technology. Autors of this project was Armin Wolf and Fro Florian uh Ernser and they start to work with standard standard dzanger project

Speaker 1: and after that they have they have simplified the structure of this project A little bit later I meet this this technology in different benchmarks, for example in benchmark from uh Kirill Klonov Um there it was the idea lightweight Django plus Sitapi. And of course a little bit later this idea takes the second birth uh Vincent presented it in twenty nineteen after it was created the repository and name transformed in Django MicroFramework. But idea was the same refreshing of light data Django

Speaker 1: ideas. And the Last important step which happens with this technology in 2023 Paolo Melchiora uh presented a sync form of lightweight Django and Paolo also mm offer the new name for this technology Micro Django. I like this uh name and that's why I use this way uh this name. Altruff, the normal is lightweight Django, already eleven years. You can meet also other names in the internet. It can be Teeny Django and a lightweight Django project. Or you can see the nano Django, probably you have uh hear it. Um it's all

Speaker 1: about the same Okay. MicroJenga in real life. I use Micro Django already two and a half years, also in grow uh big project uh sorry uh I live in uh Austria and I use sometimes dn German words I hope you understand me and the where we can use this technology. This example on the right side, you can imagine this is one huge messy Monolith from Django. Each can uh this contains around three hundred forty thousand lines of code. And uh it's uh uh really

Speaker 1: heavy to start to test and it was a problem. It uh this is example uh This is an example from medical observation data lake. And it was a problem we should make these projects more stable. And with uh lightweight Django sorry with micro Django we have we start to extract uh some small entry points in separate uh uh separate uh containers and run it to achieve stability exactly for these entry points This is medical observation. We should, for example, store uh information from heart frequency sta it should be stable, it should

Speaker 1: be uh achievable, and that's why We want somehow to extract entry points and make a guarantee this entry point what works every time. And this is segregated entry points as QRS -based project. Also, in modular monolith, you can use micro-Django technology. Please uh refer in internet the architecture pattern project uh pattern uh modular monolith. I like this idea. It's uh it was uh uh bunch of uh articles in twenty nineteen probably. And also

Speaker 1: you can use it in async oriented uh Django projects. Uh but um you can remember I say we have full Django functionality. How it works It's really easy. Pretty easy. We this is a simple one PI file to run admin site from project. And you can see I declare VSGI handler, but it's wrapped in uh lambda because I want to made it lazy. And at the second I define uh URL patterns and again

Speaker 1: I made it lazy. Simple lazy object. This is the hand uh helper Which created in Django and help us to work with objects which will be initiated later not on start of project. And execute from command line as a standard command, it means you can simply run as usual Python mine PI run server. It works. Try it yourself. All examples you can find on the end of my talk. And the next example. Standard model data series serialization sync. You can see I like to work with

Speaker 1: generic class-based views. I define the view based on the detailed view modul again wrapped in LaZerobject because we don't have models on start of server. They are registered later And in response simply I use to render in response I use standard Django uh serializer Django serializer framework. It's amazing powerful library which nobody uses, especially in projects which I have seen. And I declare URL

Speaker 1: patterns and it works somehow. You can see uh the Django uh serializer framework uh placed in Django core serializers. Okay And how it works? If you run it on server, I can roll back rollback. I run it on server and we get the serialized object from model users. Only one file, not more. Also, I can offer you async example. The sync uh example uh it works uh and we have a problem. Django 5. 2, it's still not ready

Speaker 1: to be a sync. Because uh I mean um not Django but uh class-based views not ready to be a sync. For every async operation I should overwrite uh any uh function in class Piew. For example, standard detail view calls getObject. But getObject call mate hit in database sync hit. In this case I should I instead getObject create the new uh new function r get object and after that I should await the result from a get object and uh if we I check our results, we can see it also works. Uh I run it with uh

Speaker 1: with Uicorn And uh if we see we have also our obstacles in uh Django. Uh if you use related fields If you want to serialize related fields, it's not possible, still possible with uh a sync It's uh this is not a problem. You can simply uh simply serialize pline objects and uh usually this is uh normal solution if you work with reactive frameworks. Uh but uh If you try to work right now to to solve right now some solution on uh in a sync uh mode, probably right now in Django five

Speaker 1: point two, it's not all possible but possible. Okay testing. With uh testing uh it works uh completely normally for example right now I provide The async test for view, which I presented uh on slides before, and uh important is to uh is for async testing. Don't forget Always you meet somewhere this transformer from sync to async or something back, and this is our legacy. We cannot uh still na till now we cannot avoid it to transform from from sync to a sync easily or seamless.

Speaker 1: But it works And right now some words about settings because settings PI probably it's a file which you meet in every project. Who has projects without any settings PI? I have. But in reality, settings PI is our core Core file, it's much more important than any other. And if we speak about settings, we have in reality 50 shadows of settings. Because on debug, in debug production, in debug we work with like a debug settings Probably you

Speaker 1: you have somehow local settings there. You have construction. If debug blah blah blah blah blah came some settings. Who has uh who has this construction? Yeah, everybody. And after that, probably we have we can have the test stage. And for test stage, probably we have special test settings. And also, if we start to run in production, probably there we have production settings. Who has this difference in settings? Of course. And probably you have also the different test settings. Test settings to work with Amazon, AVS test settings to work with clouds in the same way and so on.

Speaker 1: Or with different databases. And don't forget, Django offers us to have settings in completely other place of file system. It's not important to have settings in the same folder or in folder settings, settings, or project name settings, whatever. How it works at first we should at first uh at first Django offers us to works with different uh arts how settings can be declared We can uh uh use uh Django settings uh model like a

Speaker 1: like a variable in environment. Also, we can by run server we can um provide a settings flag there run server should should find the settings and so on. And external settings for single service. For example, how it works at first, you should check properly base dear in settings PI. After that you should set up in environment Django settings module path to settings and the final step you should set the new environment uh uh variable or new redefine uh new and uh redefine environment variable

Speaker 1: python path and you can add path to settings on your system after that you can run standard your uh developer web server, it works. But settings placed somewhere probably it's also placed somewhere uh in internet on the other machine. It works. It means settings pry you don't have uh you can uh don't have uh not in uh project folder and in this case Project folder with Micro Django paradigm contains only one PI file. OK. Micro Jenga: it's amazing because it can work as modular monolith.

Speaker 1: If you work with MicroJunger Paradigm, you can create the folder. There you place the first service projekt which can be run at standalone. After that you place the second service folder, which you can run standalone. And after that you have one small micro Django file. Which simply goes through f full folder automatically or right now it's uh written uh strict But uh you can find in the repository I created the auto discovery for every um mine PI and in this case the feneral uh mypi microservice

Speaker 1: file simply run any other service in one bunch like a monolith but this is modular monolith It's easy, it's funny, and don't forget to make your functions or attributes lazy. It should be calculated later and not on the uh import of the file. Okay, how it works with uh Docker? In Docker it's uh uh all fun and easy You can see also in my project I don't have any requirements text or settings PI because all requirements or settings I have in Dockerfile. Dockerfile installs for me all requirements. And it's also

Speaker 1: one possibility to reduce uh loading for developer who works in team and we remove the possibility to use different libraries because Dockerfile usually is provided from central repository, for example. Also, this command uh it works. Every example which I provide in my talk is uh works and placed in repository. Link I gave on the last slide, you can check it all and uh check Max you say true or Max you a liar And uh also what happens with uh micro-jungo in 2025?

Speaker 1: Because um Paolo presented Micro Django in 2023, and what what happens in these two years? In this case, I'm really happy to have in uh Django five point two a meta decorator uh Uh right now support me to decorate methods in class-based views and these methods can be a sync. Why it's important? Because I don't use middleware settings in settings. I wrap my small teeny uh services in dec I decorate my small teeny uh services which based on class uh with uh meta decorator But a Django

Speaker 1: also provides us a second decorator which calls middleware to decorator. It means I transform any middleware, for example, out of middleware in from from uh from middleware a transform decorator and after that with this new uh function in Django I can uh decorate only my single view with this middleware. This is important. We can discuss it later. It's a really game changer for async programming with Django. I like it, thank you. And uh also in only in uh previous version of ja uh uh previous version of Django it was not possible, but we have also uh

Speaker 1: cache decorator which works with uh async uh views or uh with async entry points it's also appears only only last year probably it's around And we have also many different async possibilities. It means I can write I can solve more tasks or business goals with async paradigm and improve uh quantity requests uh per second. Okay, and if we speak um if we summarize this all uh what I want to say Important is micro Django is only technology to work with Jenga. It means till now I don't install any other additional library.

Speaker 1: Also, to get Swagger user interface, I don't install any additional library because I know how it can be solved in a microjanga paradigm. And uh uh okay Ubicorn like external web server will be installed. Okay. And uh yeah, summary, key takeaways about micro-junga technology It's this pattern is already ready to work. Simply take it and use it. And you cannot forget it if you start to use it. This is a problem. And it's comparable with other technologies. Uh in my previous talk I already show how djangforms can validate the

Speaker 1: incoming data in the same speed like works paidantik Which written on Rust. I speak about Pydantic version 2. And uh also Micro Janga, for example, in my personal situation, Micro Django help us to extract the Django and uh endpoints from Messi Manolith and run it standalone Without any refactoring, without technology switching, this is important for team who support this code base And please don't forget right now in 2025 we are not still possible to solve all tasks with

Speaker 1: async uh programming in Django But right now with last version of Django, it's really really a huge part of tasks can be solved in a sync um paradigm And you can try it yourself at home. Simply open your love uh your famous uh project switch written on Django Find only one small entry point in your project. Extract it in a single file. Write it in micro-Django style. Check imports. Don't forget to check imports. Run and enjoy. It's easy. Thank you.

Speaker 2: So one question from the remote audience. What are the ideal use cases for micro Django and why would you take it instead of uh flask, for example?

Speaker 1: Uh what uh uh

Speaker 2: ideal use cases for micro Django and why why would you take it instead of uh flask?

Speaker 1: In this case, important pu important idea is if I work with five teams and I have Around four uh members in every team, and they all work in one paradigm Django in this case to switch for one uh separate entry point uh to use Flask there or FASTAPI or uh Django Ninja or um I don't know Lightestar. In this case we increase complexity of project and the problem for newbie developers who came in team It's gross because not everybody knows a whole bunch of technology. In this case, uh

Speaker 1: uh unification of uh code base it's made this code base easy. That's why we use this technology instead of probably any other framework. I hope I answer But we can discuss it.

Speaker 2: How how was your experience extracting extracting endpoints in relation to database migrations?

Speaker 1: Uh in this case you can see I always use uh m I always use already existed and imported models. In this case my micro-jungo entry point don't have any responsibility to work with migrations Responsibility is only to perform one small computation without without relations to changing the models or database schema. I'll truth the you can find the articles how your answer exactly researched Not from me, from other developer.

Speaker 3: How do you feel about the idea mentioned by Mr. Gibson in his talk about modularizing Django itself? uh how would that affect micro Django as a project? Do you think that then Docker image can be even more smaller and maybe uh lessons learned from Micro Django can be used as a reference for Django Core if we go that road.

Speaker 1: I uh already uh think about uh uh separating Django project on different uh modules I also created the additional library which means dependency instructor extractor. It means if my entry point uses some dependencies from Django. I can use this library to extract only single files from Django and run it in Docker container and it works without install Django. It's interesting, but uh problem from Django itself: they uh uh they use really often uh import module. And in this case, uh your dependency

Speaker 1: not writed uh deklarativ importul imports something från string. Somtimes du cannot imagina what should be importer. You should debug place uh you should be on this line and in this moment you can see which library will be imported right now. And sometimes it's completely not not obvious. Uh for example, this problem it's famous, uh you can see uh jung uh jjung can tripod mean uh sites uh import lazy uh the default uh site but this is a problem because It's imported from import string.

Speaker 1: It's not imported normally. I don't know why I know why. But I'm not agree with this idea in codebase And uh Django itself try to be written modular, but uh the these imports string imports or lazy imports can break full work. That's all But yeah, the is cool. Thank you.