Ishwar Jangid

So myself, this is what I have around 5 years of experience in Python, AWS, Django, DRF, GCP, etc. I've been working as a backend engineer in Ajay Vision Education pilot company where my role is changing the system from a monolith architecture to a microservice architecture. We have developed many services like a chat service, API service, notification service, etc. service, analytic service in Django and the FastAPI. But the choice of FastAPI and Django depends on how the scale of the application is going to be. I've been an active part of making APIs with the help of batch framework and large FastAPI and deploying them. I have good experience on AWS and worked on services like AWS EC2, ECS, EKS, API gateway, subnets, VPC, route tables, load balancer, ELB, NLP, etc. And I've been managing the CICD part as well with the help of Topher and Jenkins. Previously, I was working with industrial partners where I was responsible for writing various Python adapters because that was a kind of a Fintech company where the data was coming from edge funds, and we were responsible for changing the data in a format that is required by the tool. I also have good experience on LLM path. So I worked on Lang channel LangGraph for maybe AI agents and AI applications. For example, in getting the data from a video and making the tag, a digital augmented generation pipeline so that a student can ask a question, what was discussed in the video to get more clarity? So we have used GenTropic model as well as GPT 4 and GPT 4 in that case that we have used. And in all of these things, I have been playing a crucial role in scalability and distributed architecture. For example, we had designed our database with read replica, sharp-rated replica, and write replica because it is because the application in Vision ISH, retail. And most of the applications are deployed on ECS, Elastic Container Service, with the help of ECS, Elastic Container, and Jenkins as the CICD. Other than that, other applications are also a part of EC2, Elastic Compute Cloud, and we developed and deployed with the help of GeoRecon and Nginx. So Geniconnect is a West key website or gateway interface between Nginx, reverse proxy, and the general application. So I've been managing how the application reacts and monitoring and loading with New Relic, CloudWatch, and Datadog. So this is about my role in Vision IS and Industrial. In other product projects, I have worked on screen dot com where we have a new type of platform where Django applications have to be converted into video of Jengo. We converted the video in multiple formats so that people can share them across tools like Jira, Intercom, FreshJet, Jendesk, etc. So the integration of each was done in the general environment. So this is about myself. Thank you.

What's the difference between select related and prefetch related in the general queries? Do you have examples when you have used them? So, basically, select related is used when we have a foreign key relation and we have to do a select to rid of the n plus one problem. And the prefetch related is usually used in the context of many to many. If we have a table class and another table student, where one class can have many students, we use select related for reverse mapping in a 1 to many case. Prefetch related is used in case of many to many relations, for example, between a student table and a class table. One student can handle multiple classes and one class can have multiple students. The benefit of these queries is that they solve the problem of n plus one. If we run a query that is dependent on another table, for each row, it will make another query in a new table, becoming a big overhead on the database. So it becomes 10 queries extra plus 1 for the parent query, 11 queries in total. And that's been solved with the help of select related or prefetch related. However, select related is not always a solution because it can become heavy and cause memory issues. Prefetch related does all the manipulation with the help of a query only, without taking everything in the memory. This is the main difference between select related and prefetch related.

Simple token authentication. Okay. So when we talk with authentication means to give access of someone of something. And there's another term authorization, whether somebody has the access or not. Let's say, you have a certain role or permission. Authentication is to allow or disallow to enter into the system. So when we say authentication, there are many ways of authentication. One is session authentication, token authentication, and then this, JWT authentication is also there. So JWT, if we have a session authentication, then we are storing the session in the database. A session has to be stored in the database. So every time a new user comes, we check whether the session of this user ID exists or not. If it does, we are logged in. Otherwise, we are sent to the login page. And then he logs in and sets a new session in the table. That is session authentication. In the case of JWT, that is, JSON web tokens. So what happens in these tokens, they have three components in themselves. One is the header, then the body part, and then the signature part. So in the three parts, this token is encrypted. And when we send it over, the user, the backend system will actually decrypt it and verify which token is valid. In the case of JWT, you don't have to save anything in the database like you are doing in the case of session authentication or cookie authentication. You have to save it into the cookie also. But in the case of JWT, the data and all the information is in the token itself. It's not in the database. So we can get the user ID. We can get other information, like, for example, a kind of idea, like, the token is from the token itself. This is one thing in JWT. Other than that, we have, like, when we do which, you know, data routing view, access token and refresh token and BRT token. Three tokens are there. The access token, they are not giving the access. BRT token, like, page, like, with some more permissions, and refresh token is also there. Because access token has a smaller validity, like, for one minute or five minutes max we do. So we can take more, but it's recommended to max the five minutes for safety. So access token is only valid for a five-minute window. So to generate a new access token without asking the user to log in again, we need a refresh token. The refresh token, if given with the previous expired access token, gives a new access token with a new reset validity. So refresh token has the validity of 30 days, but the access token has a smaller validity. So access token goes through the network. So even if access token is leaked, it will not harm because the access token is only valid for a short time. And the refresh token is not going through the network because we are just using it to generate new access token and not in the API. In the converter end point, we will need the device. So we'll need an end point for JWT, like, a login end point will be there. And they generate access token, a new token will be there. And in the case of logout, we can also have logout, but, there we just delete access token and refresh token. In the case of blacklisting, those are there, like, we maintain a list of refresh token that have been expired, for example. If, 30 minutes or 30 days you can go to refresh token, then we have to put it back, like, a list of refresh token that are already expired. Like, we will not cater to the request in there. It goes to the generating system. That is also there. It's beneficial of simple token authentication, site, the information is in the JWT itself, and we are not sending it in any form. So that's, like, the most important benefit. And because this gives an anomaly delay. Because even if we modify some part, the signature and the algorithm that has been used to encrypt it will change. And this change, will not allow the JWT to be encrypted at the end of the day itself. If somebody changes anything, like, a man in the middle attack is there, so no benefit will arise because of this, in like, verify signature in that agenda nano token. So all the JWT that we can check-in the jw.io. Like, every JWT can be broken into three parts. Header contains, like, what the algorithm tells you, body contains all the data. Like, larger the data, larger the size of the token will be. And the data will is generated with the header and the verify signature also there. And then verify signature is used to match whether, that somebody has, like, changed something or not. If somebody has changed something, then it will not be able to decrypt it and, like, JWT failure, I will then talk back to side on that.

What's the difference between a view, a view set, and a model view set? Which would you choose to build the standard set of REST API and when you are? Okay. So a view is a Django view, basically. In Django, a view is part of the model-view-template architecture. So a view is something where the main business logic happens, and it takes the input from the request coming in, for example, from request.get or request.post, and then it modifies it and then returns the response to the template or to the API endpoint in a JSON structure. That is a view. Like, we can make an API with a view also, but when you use Django Rest Framework, you get a view set and a model view set. So, basically, in the layer, each API view, then generic view, and then the API view set. So a view set is, when we talk about API views for a minute. API views are basically a layer of action on adjacent responses. The adjacent structure with the response on top of a view class becomes an API view. And then we can add more functionality like a router, which becomes a view set. So in the case of a view set, we get a router. So we don't have to define the endpoint one by one, like we have to do in the case of your API, your Generic View. So a router helps us to make a standard set of REST API as you're asking. So that is, like, in the case of a ViewSet. ViewSet also gives us, like, action decorators. So what happens is, like, if you have to generate new endpoints rather than the standard set of endpoints, you can use the action decorators. A model view set is, as you have asked, a model view set is with the model. Like, just like we have model forms, we have model serializer classes. We have a model user interface, and it is huge. So it takes all the attributes of the model, makes it covert it easily. So these things just make the code shorter, neater, and easy to maintain. For example, if I need, let's say, a certain functionality in my application, in my DRF application. that contains that set endpoint. There are three get. In that case, if I use API, I have to make three different classes because only one get one portion, etcetera, this one. But in the case of, view set, I can make new and newer action decorators and keep everything at one place if they are related to each other for sure. So this helps us, you know, to build a better code, to write a better, API code. So the question was, you want to differentiate a new user model, which is it's better. Which would you use to build out a standard set of API? Yeah. I would definitely go with the model view set and I mostly use the model view set and action decorators. Not to make the API because they're super friendly, super shorter, and, like, we can password serializer that I require or permission class or authentication class, what kind of response should be given, and taking the router also. So this makes the URL list of UI file is shorter also. So these are the main key benefits. And, yeah, REST API, as you know, they can contain that list, put, for you know, put, post, and patch method. And all of these things are usually there in the case of a model view set. So that's all about the model view set. Yeah. Thank you.