Varun Kulkarni

So I graduated as a chemical engineer in 2020 from BIT. After that, it was long before my graduation that I decided I'm not gonna continue with the field. So after my graduation, I started my own startup. During that time, I was basically trying to build a fusion of Facebook and Amazon, but with kind of different concepts. So I revived the retail sector in the United States. Apart from tech, I also got a chance to work with some of the leaders of Fortune 500 companies. But due to some funding issues, I had to discontinue after one and a half years. So in 2022, I joined this company called Brackets Infinity, where I got to work on several projects, including a crypto-based wallet called MGC that we built. We also built an appointment system and a library management system. And in the end, we were actually working on developing an ecommerce application. Unfortunately, they lost the client and couldn't pay my salary, so I had to leave the company. So in 2023, I was hired by this company called Insurance Samadhan, where I worked for a very brief time because there was a profile mismatch. They hired me for Django and AWS, but put me into package development, and that was not the profile I was looking to work in. After that, I joined Impulsys. At Impulsys, I worked on a 3-month contract. They were planning to extend the contract, but couldn't gather the funding. So that's why there was no second contract at Impulsys, where I had a chance to re-architect the software infrastructure for the American Heart Association. This year, I'm planning to become certified as a cloud solutions architect. And I'm also getting very deep into natural language processing. I got a chance to work on a few ML projects, but now I'm getting more hands-on with AI and ML as well. So that's my profile so far.

Okay. So I have never worked with Next.js per se, but I've worked quite a bit with React.js. About Next.js, I just know that it's more of a framework which allows you to build front-end as well as back-end, and it allows both server-side and client-side rendering. My general approach would be to first explore what kind of data is supplied - is it supplied at once or is it a continuous visualization? So if it's a continuous visualization, I've done this type of project before. I would look to use Django Channels in the back-end, which is a framework Django's internal framework for WebSockets. And I would prefer to use Chargebee on the front-end. So, the draggable widgets, I'm not sure what exactly that would mean. I'll need some more details to dive deeper about what you exactly mean by draggable budgets. But ideally, I would either supply the data to Chargebee or if it's constant polling or if it's live data, then I would use sockets. And on the front-end, it would be Chargebee. On the back-end, you can use any framework. My preferred framework is Django since I've worked on it for the most time.

So, I'll have to check if salary automatically allows any retries. Ideally, salary all is also used with Redis, but it is used with Redis cache. So, you know, I would like a retry mechanism. In the past, I've implemented one using Redisq. I would implement a Redisq to wait for a response from salary. If the response is not 200 or whatever the desired response we set, the Redisq will keep retrying the task with the salary. So, I think that would be my approach, but I will also have to check if salary offers any features for retrying failed tasks.

Yeah, I definitely know that Django offers internal built-in support for multiple languages as well as IoT devices. I never had a chance to work with it, though. So, I'll have to check the documentation on that one. But, I'm not sure about this particular one.

On Versal. Okay. I haven't done the CICD part on Versal. I've done it on AWS. So, I would answer the AWS side. I would do it with the help of either code pipeline and code deploy and code build, or the best version I've seen so far is Amplify. So on Amplify is mainly a Lambda-like version, but it's mainly used for hosting front end. And Amplify automatically pulls the latest git commit without putting the application down in the transient time. So, I don't know about Versal, but this is how I've done it on AWS previously.

Serialization, as the definition goes, is used to convert Python data. I'm sorry, that's my cat in the background. So, it is used to convert a Python data to or from the complex query set as we see. So, from many to many. Right? In many to many relationship for the front end. Okay. Django sets up many to many. So, when you say many to many, ideally, when we do serialize and there are many fields, we ideally just add many_to_many equal to True inside the serializer. So, that's an argument to pass, many objects, many serialized objects, converted to Python and then passed to the React front end. Right? So, other than that, yeah, I think that would be my answer. But let me see if I can say something more about this. Serialize a query set from many to many relationship for different ends. And one more thing, in the same many to many, once you can add many_to_many equal to True argument in the serializer. But at the same time, if you also want the details of other tables, this particular table is linked with, you can use either a hyperlinked model serializer or a serializer relational as well. So, the model that you fetch has details of other tables as well. So, I think, this is an additional step I would take on the model's side.

Okay, so this is the model view set. Okay, scalability and maintainability. And get query set, right? Return. Okay. This is creating a user, and this is returning a user, right? So this is returning a user. Better scalability and maintainability. I mean, the core kind of looks fine to me, so I'm not really sure. Item serializer, query set, objects dot all. I think we can know what here. I think I have the answer. I think what we can do is use a models manager. And in the models like, because some users could have been deleted, but you would also want to kind of soft delete or some users might be inactive. So using the models manager, what we can do is even if items dot objects dot all will be called, we can use models manager to not fetch the inactive users or soft deleted users. And so this way, the objects dot all will fetch less number of users, which will put less load on the server. And so this can help scale the application properly. So this way, the number of entries to iterate through are lot lesser. So I think that's one step I would take for scalability.

What is written on that? I think you have used map function. Right? Map to iterate on the items. Okay. In the okay. Add item is a function in which items dot push. Okay. Items is created and, okay. Set items. Okay. Okay. Yes. Right. Okay. Perfect. Item. Okay. Set item. Okay. Okay. Yeah. Because a useEffect is not added to rerender the template after the item is updated. Right? So, you will have to add a useEffect to since the items will have to be the dependency. And once the dependency changes, useEffect will automatically rerender the template. So, that is the reason.

I never had a chance to work with Next.js as I mentioned. I've only worked with React.js. So, I think I'll pass on this particular answer.

WebSockets are a must when chatting is concerned. And then I would also create an endpoint with the AI model if you have built your own model or if you're using external APIs like chat GPT or Gemini. Like so, I would also create an endpoint with the AI model. So, basically, you'll have to connect the front end and back end with the model or the external API. And you'll have to do this. What approach else can you do? And user experience wise, you'll have to create a proper layout and a proper prompt and response mechanism. You will also have to ensure authentication. I personally use JWT, but given the security point, I would also try to use custom authentication. I think that's pretty much it. When I had integrated Gemini with one application, I had integrated it with the Django application using its API and then rendered that on the front end. One more part. I think that would be enough because mine was more of a form that sends a response and then gets the response. So since this would be more of a chat part, I would be looking to use Django Channels on the back end.

1, first would definitely be the calls permissions. Second would be JWT customer authentication. That customer authentication would check the token, the device type, and the location of where the request is coming from. So that would ensure that even if the token is stolen, the device type has to be the same and the location also has to be among the locations where the user is usually located. Right? Then, third would be this one. I would look to encrypt. I would implement an encryption or perhaps a VPN between the front end and the back end. Then, if there's any server, I would implement encryption in transit and encryption during rest. So, yeah. I mean, these are like the base steps to sum up, cost permissions or authentication on the routes, and authentication has to be customer authentication based on device access token and location. Oh, yes. Access token will be short-lived, and a refresh token will be sliding. The front end will have an auto-refresh mechanism, and then encrypted requests and responses. So, these are the steps that I would take.