Prakash Singh

Yeah. Sure. So yeah. Hi. My name is Prakash, and I'm having more than 10 years of experience in the field of Python. And, uh, I've I've worked on multiple frameworks. So majorly, I've worked on Django, uh, for more than, I guess, 6 years. Uh, almost 6 years, I have worked on Django Django as framework. And, uh, there there was, like, more than, uh, 4 to 5 good products that that I have built. Products which, uh, which were based on microservice and, uh, monolithic architecture board. So and, uh, lately, I've I've been, uh, working on on fast API framework. And this is also a Microsoft's architecture, but, um, yeah, I've I've I've I'm using FastAPI as of now. But, yeah, I have extensively used in Django framework and both both Microsoft and my, uh, unlimited application. And, uh, also involved in creating the database design, like, uh, implementing the normalization and denormalization techniques and deploying the, uh, application on AWS and Azure Cloud and, like, containerization and, uh, handling and managing those continuous services through coverness. So we are are are dealing with that as well. Um, so, yeah, mostly mostly, this is this is it. Thank you.

Okay. I got it. So, uh, uh, firstly, I will answer, like, how JWT works. So JWT works the the JWT is a, uh, tokenization technique, which has, uh, mostly, uh, inside it, I think it it has 3 components, which which, uh, uh, is a combination. Out of these 3 combination or 3 parts, a digital token forms. Right? So, uh, it has a signature. It has the SHA. I'm not totally recalling it, but, uh, I have kind of experience where we have implemented JW from scratch. And, uh, you can say, uh, the kind of, uh, like, role and, uh, the access to to that token we were adding. Uh, so let's say, in different Microsoft architecture, we are following this usability, uh, token authentication system, where the Microsoft needs to connect with different micro service through this JWT, and we were checking the rules and the the user identification. Right? Whether they have the current access to, uh, our our current authorization to access that particular resource. So that's why JWT is important. And so coming to the second question, why it is beneficial over simple token authentication? Because simple token authentication in Django with with when I talk about Django. So, uh, uh, Django does provide a simple authentication. Uh, also, uh, which which is kind of sufficient in them for us for a for a project, which is which is like a monolithic application that, uh, user, uh, is getting authenticated by providing the token. But JWT plays a very vast, and it covers a majority of your, uh, you can say, if if the serve if the service or the project is, uh, is a very vast, uh, project where we have a microservice architecture, and it had, like, so so much of, uh, so much of dependencies of of different authentication, uh, let's say, different authentication mechanism, then JWT is very crucial. Yeah. But I'm I'm really sorry. Like, I'm not able to recall, uh, the the all the 3 components that is involved for creating a deal with the token. But, uh, I I have, like, created JWT, uh, like, established a class a separate class for the, uh, for the JWT authentication part. Like, the authentication middleware using JWT authentication. We we have, like, uh, access token and refresh token concepts. The refresh token rule we have within the inside settings of here, and, like, in how many seconds it would, uh, get eliminated or or an access, and then we we then provide, uh, a new JWT token to the particular service or to the particular user. So in that page, the ability token we have used.

Okay. What is the difference between select learning and refresh learning in Django? Can I see an example when you would use each of them? Okay. Fine. So in Django's normal warrant query is where, uh, we can write a normal filter query for accessing foreign key relationships. So let's say, uh, we have, uh, we have the employee table, and we have, uh, let's say inside employee, we have profile table. Right? So profile is a foreign key, uh, employee's profile is there. So when we are trying to access that, it what it does, it it has an there's one problem. Right? If I query in one table, it has it will automatically hit 1 another, uh, untouched tables record. So whenever you do dot, so let's say mples.profile.name, it will be an mples. Right? That will happen. Right? So in order to, uh, manage or in order to boost up your ORM queries, uh, Django provides select related and prefetch related. So select related is mostly used, uh, with the with the foreign key relationship. And prefaced related, uh, can also be used, you can say, uh, that and and, uh, foreign key relationship. But mostly, it is being used widely using manage to manage relationship or accessing the manage to manage relationship case. And one single goal for that, it will eventually eliminate n plus one query. Uh, so how it does uh, eliminate n plus 1, that is something which is very crucial. So it but it does it actually loads, uh, the the object into memory. Okay? Uh, and then from that memory, we can access those objects. So we do not need to go again to the database and hit the database. So that is one thing. Yeah. So this is this is all about selecting

Okay. Um, so this is a very I think a basic question for for a Django developer where, like, which what kind of view views and model views it? Like, there are, like, different views, templates, and we have, like, API views and and so so many other views that, uh, that are getting inside Django framework. And, uh, I would mostly suggest to let's say, let's talk about a proper view. What is a view? A view is normal API where we are not using anything. It's just like, uh, a simple API view where you have to write your own, uh, set of load logic for, uh, get, post, put, and delete. Okay. These are the these operations, you have to write your own set of logic, and you have full control on on on these, uh, methods. Like, what you have to write and how the validation is going on, how, uh, the different communication will going on. This is this will give you a full control of writing your API. So this is the view, and a view set is and there are, like, multiple users. So one of the user is model user. View set abstract, uh, abstract the, you can say, these methods implementation. And it does provide you a simple, uh, simple 2 line or 3 line of code where you can, uh, create your API, and then it will walk, uh, out of nowhere. Right? And in order to in order to, uh, write this view and view model, you said we have the router service. We can't use a normal URL service. We have to use router service. So those routes needs to be associated with the view set or model view sets. But for the view, uh, particular API view, we we can we can attach it with a particular, uh, URL where, uh, a URL is one URL for get, one URL for post, one URL for for for updating, uh, the view. But for view and model usage, it is only one single router which will actually, uh, extract everything and it will, uh, give you, uh, the, uh, you can say, the implementation of check implementation of what we have, uh, been doing inside view. And the model you set is, uh, is something which I can directly use. So let's say, I am writing an API for employee table. So in employee table, I have, like, different fields. Right? So I can use those fields inside serializer. And through serializer, I can directly use model and serializer and, uh, let's do the model user and then it will again, like, it will give me every everything. Get put post delete everything. So that's the main difference. It's the implementation that how it works. And if I want a full control of how I can, uh, I want to implement my API, then I will prefer to choose view. But inside view side also, I can, like, override, get method, post my route. Uh, so and write my own custom logic inside it. But, yeah, that is something which we have to write. I did it slows down, uh, the the implementation and then it will eliminate, uh, the advantage that they are giving. Yeah. That's all.