Prakash Singh

Hi. My name is Prakash, and I have more than 10 years of experience in the field of Python. And, I've worked on multiple frameworks. So, majorly, I've worked on Django, for more than 6 years. Almost 6 years, I have worked on Django as a framework. And, there were more than 4 to 5 good products that I have built. Products which were based on microservice and monolithic architecture. So, lately, I've been working on the FastAPI framework. This is also a microservices architecture, but I'm using FastAPI as of now. I have extensively used Django and both microservices and monolithic application architectures. And, I've been involved in creating database design, like implementing normalization and denormalization techniques and deploying the application on AWS and Azure Cloud, as well as containerization and handling and managing continuous services through DevOps. We're dealing with that as well. So, this is it. Thank you.

Okay, I will answer how JWT works. So JWT works as a tokenization technique, which has mostly three components inside it, which is a combination. Out of these three components, a digital token forms. Right? So, it has a signature. It has the SHA. I'm not totally recalling it, but I have kind of experience where we have implemented JWT from scratch. And you can say the kind of role and the access to that token we were adding. So let's say in different Microsoft architectures, we are following this usability token authentication system, where Microsoft needs to connect with different microservices through this JWT, and we were checking the rules and the user identification. Whether they have the current access to 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, when I talk about Django does provide a simple authentication. Also, which is kind of sufficient for a monolithic application where the user is getting authenticated by providing the token. But JWT plays a very vast role, and it covers a majority of your needs if the service or the project is a very vast project with a microservice architecture, and it has many dependencies of different authentication mechanisms, then JWT is very crucial. But I'm really sorry. Like, I'm not able to recall the three components involved in creating a JWT token. But I have created JWT, established a class for the JWT authentication part. Like, the authentication middleware using JWT authentication. We have access tokens and refresh tokens concepts. The refresh token rule we have within the settings, and in how many seconds it would get eliminated, and then we provide a new JWT token to the particular service or to the particular user. So in that case, we have used access tokens.

What is the difference between select related and prefetch related in Django? Can I see an example when you would use each of them? So, in Django's normal ORM query, we can write a normal filter query for accessing foreign key relationships. Let's say we have the employee table, and we have a profile table inside it. Profile is a foreign key to the employee's profile. When we're trying to access that, it has a problem. If we query one table, it will automatically hit another, untouched table's record. So whenever you do a dot, like mples.profile.name, it will be an mples. Right? So in order to manage or boost up your ORM queries, Django provides select related and prefetch related. Select related is mostly used with foreign key relationships, and prefetch related can also be used with foreign key relationships, but it's mostly used to manage relationships or accessing the many-to-many relationship case. One single goal for both is to eliminate the n plus one query. So, how it does this is actually by loading the object into memory. Okay? And then from that memory, we can access those objects. We don't need to go again to the database and hit the database. So, when to use each? You would use select related when you're dealing with foreign key relationships and you want to load the related object in a single query. On the other hand, you would use prefetch related when you're dealing with many-to-many relationships or when you want to load multiple related objects in a single query.

Okay, so this is a very basic question for a Django developer where, like, which type of view is it? Like, there are different views, templates, and we have API views and so many other views that are getting inside the Django framework. And I would mostly suggest to let's say, let's talk about a proper view. What is a view? A view is a normal API where we are not using anything. It's just a simple API view where you have to write your own set of logic for get, post, put, and delete. Okay. These are the operations, you have to write your own set of logic, and you have full control over these methods. Like, what you have to write and how the validation is going on, how the different communication will go. This is what will give you a full control of writing your API. So this is the view, and a view set is. There are multiple users, so one of the users is a model user. A view set abstracts these methods' implementation. And it does provide you a simple 2-line or 3-line of code where you can create your API, and then it will be ready. Right? And in order to 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 the router service. So those routes need to be associated with the view set or model view sets. But for the view, a particular API view, we can attach it with a particular URL where a URL is one URL for get, one URL for post, one URL for updating. But for view and model usage, it is only one single router which will actually extract everything and it will give you the implementation of what we have been doing inside the view. And the model view set is something which I can directly use. So let's say, I am writing an API for the employee table. So in the employee table, I have different fields. Right? So I can use those fields inside the serializer. And through the serializer, I can directly use the model and serializer, and let's do the model user and then it will again give me everything. Get, put, post, delete, everything. So that's the main difference. It's the implementation that works. And if I want a full control of how I can implement my API, then I will prefer to choose a view. But inside the view side also, I can override the get method, post my route, so and write my own custom logic inside it. But, yeah, that is something which we have to write.