StreamSparkAI

speaker 1: Thank you. Thank you. Thank you. Yeah, so that's start, as you said, it's about trying to modernize even more application using jungle ninja. So let's start about how I'm going to present it. So first we are going to see jungle ninja. If you don't know it yet, what are the challenges that I faced with large scale applications? Then my vision and kind of potential solutions, spojungle, ninjkra and detailed examples. Also how I tried also to not only improve the developer experience in order to develop endpoints, but also the testing experience. And then finally the future directions, conclusion and maybe final thoughts. So first, who am who am I? So is it working? Yeah. So first, Yeah I grew up in Normandy in France, the north, and then I moved at Toulouse, other south for my studies. And I stayed in order to work at pixela. It's a little startup with a couple of friends where we are developing AI tools for computer vision. And in my free times, I'll bring football, music, painting, and developing, of course, and use the web or mobile applications and recently, open source. So you see with two packages, and for now, Yeah, it's been five years that I've been using jungle and jungle ninja for two years. Yeah. So next introduction to djungle ninja. If you didn't see it two years ago, Vitaly kushyai, the creator of djgo ninja, made an introduction, but it was remotely since because of the pandemic and stuff. So a little summary about it. I'll all of you maybe know. Like it's kind of first api developer experience where you have easy serialization using bidentic schema and an open api documentation like automatically. It's not a big deal since you can do it with other frameworks too, like jungle rest framework, but it's kind of cool to have it. And let's start the fact note. I mean, it's a joke because it really like what I'm trying to say. It really depends on you. I mean, each one of you can have some preferences. It's not like framework is better than anyone is. Okay. So for example, what do I personally love about jungle ninja? It's the abstraction level, like taking this serialization and this alization layer just a little bit higher so you don't have to do it in your g function. So Yeah, it's done in the middle way layer. So Yeah, I really like it. You just have to define Yeah just like the example. I don't know if you can see code re adsanow, but Yeah just an example. So it's visual. And Yeah, I'm not just talking like that. So Yeah so what are then if the you know the developer experience is quite increased with jungle ninja, what are the problems that I faced? That's okay. Just like any frameworks you would be using, you have a certain moment, a lot of models, a lot of repetitions in the services that are using it, updating it and also at the end point. So for the services service layer, it's quite easy. I mean, it just function and you're doing quite everything you want. With before endpoints, I find it quite difficult. I mean, even though I was referred to my code all the way I wanted with the services, I had a lot of repetition on the enpoint player two. So duplicate duplicated logic, sorry, increases, of course, the risk of inconsistencies. So my next question was, how can I fix all of those problems? How can I minimize as I've written or play code and repetitive endpoints? How can I do it in order two? Yeah, just be less frustrating when you are developing all of this stuff and when I don't know, sapeople are asking you a new vertical in your application. You have to repeat a lot of stuff and how to not just rush. So Yeah, a lot of questions that I try to basically try to respond it. And all of this started one year ago when I was vacation in palramada mariorcaso. It's kind of fun that it was in Spain and back here. So Yeah, I was trying to think about how could I fix all those problems? So one of those he was okay, there's some components, some sorry, some views that was repeated a lot all over my application. Sometimes it was, for example, a concrete one, the read operation. I had a lot of get pentions over an object that was repeated for different schemees. Sometimes you just want a little bit information, sometimes more, sometimes only ids and listing ids of specific objects. You have a lot of revisions and existing solutions like view sets in jungle reprimox, for example, didn't offer the flexibility of defining several crowaction, for example, than you had with inarritgance, only one possible implementation of each view. So I was thinking about how to how can I treat them as components like an notion, a word you obviously often see in front end development, but we are only taking the good side of it, right? The JavaScript and the key specifications include Yeah so plabased view components, even though it doesn't exist in djungo ninja, and that's not exactly what I'm trying to do or implement, like expose class based views for every people using jungle ninjaba, just that I need it in order to declare my views as modular as I ever wanted to. And Yeah so easy of creation of cruise. The goal is to ease the way of the way for people to create their own modular views. It depends on your specific your specific business logic is not always repetitive Fred and points out everyone ever saw. So first, how to create these potential core objects. So as you may know, Yeah the basic way of creating a gate operation, for example, in order to read, let's say a department object is really a basic object, right? Just have an idea, an autophill and a title you want to get it with as simple as chema. You just get the object. Okay? From this, if you check the code of the get method on the router, you see that it's just really about api operation with methods get, okay? And from it, if you read the code of jungle ninja, you see that it's just wrapping up the method at api operation in a decorator. So from it, okay, I could create an object called api view, make the method path all the attributes in it, and abstract away the view function that I could just return with a key method called as as operation as a dict, and use it when calling router api operation with the return rases as a dictionary. So we have a method to your way to define an object, realize it and use it in order to add the operation. So we just need the router, the object, and we can add a view. But then how to compose it in what I called api view sets, how to manage them and group them with, I don't know, maybe unsurely with I know Yeah similar properties like model, of course. So Yeah, first I had a look at insaclass. It's kind of in it for instances, but for classes. So as soon as you're enherrating this api view set mail, I can access all the surplus, all the class atates of it, and especially the instance, the subclasses of api view. So you just have to iterate from api view, put it as a class attribute to api view set, and then I can just iterate over it though to change, of course, the view function name two, because it's going to be generic, of course, to the class attribute name. So at the same time, I'm dodging like the conflict possible with view function name. I'm then accessing the ipr view set from each modular view so you can access similar like same properties on the api view set in the module views and then call the function the method Add View to that is doing what I just talked about previously, like serializing your api view in aoperation ation and call the router when but then it was a little bit too abstract. Like I could not expose this to every one of you, every users, and just say, okay, let's go. You can create now your own api views. I had to take some really fundamentals that were both repetitive and common to everyone. And thanks. There's like some advice. Go create, read, update and delete the crowd that was first interested in 1983 by James Martin. I hope you maybe read the book, but Yeah don't like I refound with those the exact kind of empress I needed in order to showcase how to declare your views are model or like as components. So it was kind of the introduction of the package so I could expose it to everyone, make it understanding understanding and see exactly directly how you're gonna know how you could have the declarative and intuitive syntax to kind of every endpoints you see easily with crud and you can easily think about it for your repetitive and common logic inside your proper business logic. So Yeah, just like that, I have defined like five classical classic views and be able to compose my view set as I ever wanted, even, for example, use the list views several times. As I said, for example, you can list a department with a simple schema and an extended one with related objects and a simple one with just the ids. You can do whatever you want, but you identified correctly that those endpoints were kind of the same and could be possibly refactor at the top level. I mean, at the definition. Okay, little bit to abstract. So everycode, what is directly doing? What we are writing it, you just see that I've leveraged the inherritance of values in the api view set. So you just have, for example, you know that the view set linked to department object is going to have views that are going to use the models. If I access it and access the default scheas, I could easily create list sts, create read and update delete views. So just like that in several lines of code, you just abstract a way kind of the botle plate code you know to expose a new model that you just integrated in your application. And Yeah, a keypart d is that rethe same in same views, in the same view sets. So for example, if you have migration of schema, for example, the head of the exposition of your new field, or rename a field for certain in clients, you could just add A V two path and just expose the same schema without the need to rewrite another endpoint. So Yeah, again, a lot of abstract talks. So we need concrete examples like what does it really look like? But first, some Vanya Jungo ninja code. So you see when you are reading a classic list endpoints, for example, I'm going to do exactly the same for all the five endpoints you have the basic one, let's say it's your proper business logic endpoint, right? Not a credit endpoint. You have to identify around all the use of it what's really similar in order to find the perfect interface. Like it's a general problem. Okay? You have to define your own function. I could not do that, but I kind of done it for basic credit d operations. So Yeah, once you found the basic request components, maybe some method around it. Paonage class, of course, even though I put a default. Like jungle ninja has done with limit offset paginations. So Yeah, you could easily write some complex endpoints, but also really easy to read. For example, here I'm easily defining a list. Employeendpoint is really just a list related to department. Yeah I didn't introduce the jungle models, but you can easily know that employee as a foreign key to department object. So you're from direct path where I know the ID is from the model defined, that is in the view set and in the view that Yeah, the ID is the one from department. And then you can easily define your schemas and have your hand point. So we declaative and kind of really usable one time. Again, I'm really defining the tools to define it. You are free to not use the once I've like the product views my implementations of crowviews, you can extend them really easily. The key here is that you just have to define them as class attributes. So if you are creating your own custom view is going to be another class. You don't have to change the api view set. You just have to added it as the class attributes. And just like that, have your you compose your view set as I've said. And Yeah, you can do the same for the other one, like create what's changing like in it model. Maybe you're asking why because sometimes you could have like with so with the listing employees, some path paraters like, okay, if you specifying ID and then something else or even name or even any path parayou ever wanted, there's going to be some past managers and maybe you are going to use it in your Indian model, for example, even the request in order to link. I don't know if you are doing the create by user Yeah and other presave and post save like I proved to do it and you maybe should do it here in the endpoint o in the service layer instead of the signals and joinside the models. But Yeah, since it was kind of a little bit opinionated to force users to have the full clean method, I put it in a prere save that you can easily override if you want to use directly implementations of my views here at creview. And one time again, Yeah it's in the blue one are always written like the request components. Yeah. So once again, you can easily define some complex but same view. You just have to define a little bit more parameters. So Yeah, as I said in the init model method, I know if you're very far from the screen, you can see the code, but I share the slides right after the init model. You just have to rebuild the past generators ID in the department ID in order to, as I said, override the init model. So you have everything you can want to and we can do the same. But Yeah ask keep this part because I think you understood the idea. You just identify what could be customized in order to be used. We largely and minimize the code wherever it's possible. So I've done the same for updates and then you have it. And Yeah, something I just talked about previously was the possibility of defining just a new schema for the same operation really easily by just specifying the path, like just path ID V2 and you have it, just link it to the right schemas and finally delete kind of the same. I suppose, predelete and positive operations and a get model that I never never overwritten, but I'm just exposing it in order to say that Yeah, I'm allowing any kind of customization, but you're free to do whatever you ever want and Yeah, maybe not more. Yeah and let's get it. How Yeah some key component in the package is how can I abstract away the link and know which parameters it is of what type? It's really easy. When you have the path and the model, you can easily extract all the strings from your path, like the path narators name and linked it with your model in order to know exactly which field is it. So you have kind of accessing get field from the modest meta arguments and then you have it, you can dynamically generate, sorry, around time, your pdentic schema. And Yeah the keyparts, as I said, you can easily add your custom views because it is about like creating some component like views for you proper to your business logic. Not only credit d operations, so Yeah, I've talked about it, but how to do it? Yeah, again, a lot of code, I hope, really far away from the screen is okay. As I said, you just have to enter it from the api view class where you define the interface you want to. So it's probably it to your needs. But I've done an example using the subdelete operations where you could do it with an update, but it's not an update. And sometimes you wanna Yeah just define your repetitive operations and you just have to define an inner view function. And Yeah, it's just easy at that and you can use it with one line everywhere you want across several view sets all inside the same one. So no, if you make rating schemas, as I said, so Yeah, really easy to define your own one. Just use api view set and your custom view and it's okay. So Yeah, now that have showcased all the features kind of of the package, what's coming after of course, a little bit of fix because I have one issue that abstract too much the api view class. I've made it too opinionated around the crowd operations. Like I've really made it with as inputs only three parameters the request one pathway body when you could potentially have fried edder or cookie. Like it's kind of a light to say that today we can compose any custom view, but it's going be recent like here matter of weeks before I got this. And Yeah of course, implement the most ask feature, like showcase how to create some I think views to Yeah make people happy about it and you know just be on the trend. And then I couldn't maybe think about A V one that I'm waiting since one year and maybe provide some other common credit operations even though it's maybe not. The goal of this package is to showcase how to do it, but not like use all the tourists I will provide in the future and maybe extend the vision of the framework. What does that mean is at first, I really wanted to make this available. As I said, it does not deepend on the framework. So maybe adapt it easily to jungle rest framework or first api or anything just in order to defend some composable approach. But I don't know yet. I just see the V1 and then we are going to see but Yeah, my experience here didn't stop too trying to enhance the developer experience on the specific task of defining endpoints. I also tried to tackle the testing experience was a little bit harder because Yeah, it was a lot of also repetitive. At first I was really nave because I tried to kind of repeat the same pattern, like having some component like test objects. While it kind of sounded quite right at first, one year after, I would never do that again while because it was just hidden, it was just Yeah some code was hidden. You were not probably aware of what you were testing all the your applications just using a random test component like object. And it will not take the responsibility of saying to you that, okay, you are really testing everything. If you put this in your test, it's okay. I was not really convinced then. It was really bringing a lot of more problems there solutions. So Yeah, that's what kind of the thing I try to do, like link the wow, Oh, sorry, three actually, Yeah, but I tried to link all the tests together like that with the names. It was kind of working, but as I said, kind of lack of flexibility and kind of really rigid. So Yeah, it was not. No generalization was possible because I was constraining the status code and stuff. Yeah, I just skiit to you because it was really a mess. The important part was is that I successfully like flatten all the eras of made and just throw them away with an object called scenario where I'm just it's really just the black box with inpurequest components. And expected statement on your response for now, it's really basic, just abstract away the need to do the htp code and the use of the client. But Yeah, I find this interface way more easy in order to manage all you scaled tests over your big application. And Yeah, I really like the way it goes. Only one test for specific dpoint where we you are testing a lot of scenarios together. And the key e here is that you can test it, for example, with several users with different permissions and on different objects. And every scenario are completely isolated with a database fallback as I've written. And Yeah, it was so after the ration and the complete rewrite of and inspiration of jungonninja, it was just depending on jungle. So I was like, okay, maybe it does not have a spot like in this package. So I separated it even though it's kind, I say a little bit small, but Yeah, it's the little brother of jungle in jakra. I've named jungle rest St testing. And Yeah, take a look. So Yeah, that's a conclusion. Yeah, it was real time consuming to do all of those, the two packages, the maintenance and think about the features kind of alone. So it was really hard and time consuming, even though it's a really valuable learning experience. Yeah, I've improved the developer experience for me. So why not for everyone? I hope this is going to work. So Yeah, I just want to thanks all the staggezer contributors and sponsors of the packages. Really great. Without you, it would have been a lot of more difficult. Of course, thanks to GitHub, rme and jade brains for the open source license, even though GitHub is kind of natural, but we are kind of not aware of all the advantages of GitHub. And of course, thank you, John, who can organize us for.