 Hello, thanks all of you for being here. First, I will start with a little introduction about myself. So I'm currently the lead developer at OnTrack. I've been programming for over 20 years. 15 of those professionally and the last 5 plus of those using mainly Python. Just for the context of what I'm going to tell you, what's OnTrack. We are a startup, less than 2 years old, set in Madrid. And we are trying to put tech into the logistics industry, which is a very funny industry because it has both very technological stuff, like people doing self-driving trucks or fully automated robot sorting facilities and stuff like that. But then on the day-to-day operations, it still works mostly as it worked 30, 50 years ago. So somebody calls and ask for quotes from drivers and so on. So that's a bit problem we are trying to solve. So something like a year and a half ago, we started building the OnTrack platform and our CTO proposed us to use Django's framework. Since he had used it before with success, we analyzed it and we decided to go with it. It's a decision we have come to both rejoice and regret over the last year and a half. So lots of good things and bad things from there. So I will just try to show you some interesting stuff that happened to us during that time. So first that very simple knife assumption we did. So we started and we had our main core application and we had the views, the serializers and the models. And we started very small, very lean, and we said, ok, we will split them when we reach that point. Of course that point came a little late. So this was all quite big. So more knife assumptions one does. So we said, yeah, you know the pagination from the Django's framework? It doesn't suit us. We would like to have this option of setting a page size of zero and getting everything when we use that as a page size. So we went ahead and did it. Let me tell you people a very bad idea. There is a very good reason the Django's framework doesn't usually let you do that. And it's because when you are getting some thousands of heavy models, the serialization goes completely crazy in heaviness and time. So one of the things you hit when you do that is the famous N plus 1 query problem. Main way of solving that using prefetching and so on. So yeah, some of our prefetchings look like this. Yes. And one of the things I want to mention, the prefetching into an attribute that is a very, very useful thing to do. So basically as using some of them, we put it to a private attribute in the model and then we do some magic in the models. So we always access through that. So thanks to stuff like this and using silk, we managed to solve for N plus 1 queries problem or more like 50 N plus 1 queries problem. And we got some of those N points from over 3 minutes to just some seconds, which was very nice. Then next thing that happens is you have your very nice REST APA and you are very conscious about it. And then of course the mobile applications come and tell you, yeah, you know what, fuck auto discoverability. I want to reduce the number of requests I have to do. I want to have requests depending on other requests. So you start doing some different N points for the mobile apps. And then you might run into something like this. And you end up, since the mobile endpoint is, let's say, a subset of the standard endpoint, you might think of extending the mobile endpoint into the standard endpoint. That's the wrong way of doing that. And you will regret it later. So please when you run into something like this, don't do this. It's better to reduce your standard endpoint and have the other way around. I'm talking about in editing. Let's mention a little thing. So when you are trying to inherit the fields and extra quarks in the serializers, remember that you need to copy the dictionaries. It's very easy to forget and it can be a pain in the ass when you start adding random arguments to your original model. Then another thing that happens is when mobile tells you, yeah, what about giving me different data for the list than for the detail view? You could do two different views, but it's only just having a subset. So let's go ahead and just change it dynamically what serializer we use. You end up with something like this. This self dot action, it's very undocumented in the language framework, but it's very helpful for this kind of things. So basically when you have your view, you can use that action point because it is auto populated in it so you can easily use it, but it's very nice. I'm going with small things that can go wrong, which happens everywhere. There is this very funny point in the documentation of the English framework. I don't know how many of you are native English speakers, but for us it was a very funny moment when we realized that, what says there is not that the lookup URL is defaulting to pk as the lookup field, but it actually defaults to whatever value you put in the lookup field. That was some curious phrasing that drove us crazy for a while. Then of course, once you've dealt with separating your endpoints and doing all that crazy stuff, then you have to deal with strange requirements that come from the business side of the company. So for example, for us one of the craziest things we had to handle was that they decided at the beginning that they didn't want users and that kind of stuff. So basically they wanted to give a link to the people and make sure that whenever somebody would go through that link they would be logged in and be a proper user and whatnot. So we ended up creating this crazy authentication method that was just based on getting some parameter on the header and then would actually even create a user if the user was not already there because nobody was creating those users. So basically giving some random URLs to the clients. Believe me, this kind of thing tried to avoid it also. Then you might end up with strange validations like, let's make sure we do not change the past, OK, since reasonable, of course, since reasonable and then a week later business comes and tells you, hey, by the way, we need to actually be able to change the past in this, that and these other circumstances. So you end up having to build your own way of going over your validation. And then you might end up having strange ideas like, OK, this thing is not so well defined. Let's not structure it so much. So let's just go ahead and put it in a JSON field and then we will just give it a structure using the serializer. And you end up with something like this that does a lot of horrible calculations at the serializer level just to get some data that is in a JSON field. This, for example, has been not only a pain to maintain, but especially it was quite painful to then undo. That was some quite valid data that we had there and we ended up having to put in a proper table with proper structure and so on. So that's a bit what some of the funny and interesting stuff we've gone through over this year. I also would like to mention some of the tools we found helpful during this year of learning and finding out stuff. So, for example, we have this don't repeat yourself permissions framework. That works quite well. It has a strange thing that is that you define the permissions for your views in your models instead of in the view itself, which feels weird, and at least I feel that I end up repeating myself quite a bit, but it works quite well. Django push notifications is very nice and properly maintained library for handling push notifications and it integrates quite well with Django's framework. Django finita state matching, also nice and useful to have, gives you a very nice out-of-the-box finita state matching and even keeps track of stuff like the concurrent requests and stuff like that. Then probably the library I've ever used with the longest name, that is the Django REST framework, sofi alo out too, that gives you basically everything you might ever need related with authentication and user creation and all that stuff. And sick that I mentioned before, it's a really, really good profiler, it's very nice to use, it's very helpful, it's quite deep and it's quite pleasurable to use. So basically what I would mostly like you to get out of this presentation is that you need to use your framework. So a lot of things, a lot of times I've seen a lot of people that take a framework and try to use it however they want to use it. You need to learn your framework, you need to use the different parts in the way they are supposed to be used in general because if you are fighting your framework, then it will get on the way and then it's not worth the thought of using a framework. So basically try to find one that adapts to your circumstances and learn to use it properly for what it does well instead of trying to fight it over. Cos' there's a good reason why frameworks are out there, they give you a lot of nice things, a lot of speed, a lot of ease of use, in particular my experience with Younger's framework, we've talked about getting rid of it quite some times and for the time being the advantages have always surpassed the problems it gives us. Of course it has limitations, it has parts that could work better. For example as I said before when you are serializing big models it goes into quite heavy consumption of resources but in general it's worth the thought. So basically try to use hammers for your nails and screw drivers for your screws otherwise you would be screwed basically. So yeah, as a wrapping up, that was me one year ago, this is me after a year with Younger's framework and yes, both are company pictures. So please feel free to come and visit us, we have a stand downstairs, we have plan evers, we have challenges, we have prices and we have some very nice pink dress people to talk with. Thanks everyone for listening, any questions you can ask now or you can also email me at castilloatontrack.com Thank you very much for sharing your experiences, are there some questions, any questions? Hello, thank you for your talk, thanks. My question is, do you feel there are changes in how you use the framework and how you adapt it to your circumstances today as opposed to a couple of years ago? So first to clarify a couple of years ago I hadn't really used this framework yet so yeah, there's a lot of difference on how we are doing stuff right now and how we were doing it a year ago, a year and a half ago when we started. So there's a learning curve whenever you try to use a new framework and in this case I think it's been quite interesting the findings we've done. So for example when I was talking before about the order of inheritance there's a very good reason, for example this. We were in editing in the wrong direction so our specific case, the mobile, was the base for the standard case, that was the serializer, and it's already the main journal. And then when we changed this in the mobile one we were not counting with the other one in editing from this and it was completely absurd and something that everything broke suddenly and so on. So yeah, you learn stuff and you learn from your mistakes. It's important to iterate and make mistakes otherwise you are not really learning so much and it changes how you use stuff over time. Yeah, hi, thanks for your talk, it was quite informative. There's somewhat of an overhead of using Django REST framework just for making the models and stuff like that. How do you feel, would you use it for a small needs for example just needing a JSON output from a model for reading it or something like that. I myself have just kind of written a small method for the Django model to give me the JSON itself. Ok, so if I understood correctly basically you are asking about a smaller thing. So probably for a smaller thing I wouldn't go with Django REST framework unless you already know it. I mean, the thing is if you already, I had been working before with quite a lot of plain Django and adding the layer of Django REST framework on top was not so hard. So that's why we decided also to go with it. But probably for a small thing it's not worth the fort of learning all these layers because even Django itself it's not a simple framework. So for something simple probably you are better off using flash or something like that. I think there are even some linear frameworks out there. So yeah, probably for something small unless you already are familiar with the Django and Django REST framework I wouldn't go with it. Hello, hello. I want to ask you about permissions. Did you use permissions on different methods of the endpoints? Yes. So what permissions? And how did you implement them? So we use quite some different ways of having permissions. As I said, we use that don't repeat yourself permissions library which basically hooks up your models to allow you to define their permissions. So basically you do them at model level so you can play a lot with them. So for example we have for the journeys as I said we work in some relationships between shippers and drivers and so on and the journey is what a driver actuaally does so it's what loads he gets and so on just to give a little bit of context. And for example there the permissions are quite complicated cos a journey that is not assigned can be seen by any driver but if it's assigned then only its own driver can see but then also the shippers involved in that journey can see that journey also and of course all the super users can see the journeys and even we have some rules about when it was assigned so that you can see the last journeys that were available and stuff like that all of that is very easy to handle with this DRI permissions framework. It allows you to create very simple rules in just pure Python logic. I hope I answered your question. Any more questions? So if this is not the case thank you very much again Alejandro. Thanks everyone.