Siddhesh Rane

Oh, well, I have been JavaScript developer for more than 6 years now. Uh, I have over 6 years of experience, uh, working with React and React Native frameworks, both mobile and web applications. And, also, I have worked with Node. Js, uh, for 3 years 3 years of experience with Node. Js. I have, uh, developed all kinds of apps, uh, with React Native, uh, maybe whether it's freight forwarding or stock market apps or, uh, voucher based apps, uh, with real time functionalities, all, uh, I have developed so far, uh, in my previous and current companies. And, uh, I also worked with the WebSocket, uh, you, uh, GraphQL. I have used I have used caching libraries like React Query and, uh, Apollo GraphQL as well, both front end and back end. So I also, uh, also use, uh, like, I have good knowledge of Next. Js. Uh, it's caching. It's server side rendering. And, obviously, Redux I have been using, uh, for 6 years. Over 6 years as well. I've used Redux Saga, Redux Toolkit. I used Redux Thunk as well. I've even tried, uh, Just Stand, which is, uh, which doesn't require a provider. So it is good, uh, but it is a new technology. So, yeah, I mean, I have a good experience with React, uh, with JavaScript, basically. With Node. Js, I am I know, uh, like, I have worked with real time features. I have used Express as well. I have good, like, a good knowledge of the event loop and how the how it, uh, handles, uh, the single threaded, uh, not just application by, uh, any heavy task it sends it to leave you, we all v eight, and only executes the callbacks on the single thread. So it, uh, becomes non blocking. Uh, so and, uh, also works, uh, its performance also is very pretty good. So yeah. I mean, I understand Node. Js in, uh, pretty well as well. So yeah. So

Well, I think the best approach with WebSockets, there are many approaches. First of all, you can use the WS library in both front end and back end. And through this, there is one HTTP session and then there is a WS session which you have to make sure that is available in both sides. So the same concept is used in like Apollo GraphQL and Apollo server. So we can use that as well with Apollo GraphQL and Apollo server in the front end, we can again use the WS library to set up the session for the real time subscriptions. And in the back end, through that session middleware, we can access the whatever that is passed through the API, the routes, and we can use that and through the resolvers, we can handle it in the back end for Apollo GraphQL. So like I haven't worked with Django much, but I'm like comparing it to Node.js experience, which for an app, I've already worked with a chat app, which involved using a front end Apollo GraphQL and Apollo server. And I managed to had a session with WS enabling WebSocket and providing the important access tokens or any authorization related material through the WebSocket session, which is then available in the back end as well. And there we can check the authorization process through the middleware and handle, like we can then proceed with the resolvers for the GraphQL. So I think then we can just perform our back end database operations or anything, so yeah.

I think they, uh, with the RDA query, there is already a use infinite query hook, uh, which allows you to which gives you few properties and, uh, like, uh, next page property, previous page properties. Uh, like, I can't remember the perfect names of the properties, but those, like, next page properties, previous page properties, the total count. But those things you have to handle in your API as well. Like, make sure those things are available. And, uh, it abused you the property to re fetch with different, uh, with the the next page, uh, property, uh, next page number, basically, or previous page number. Uh, it also tells you it also gives you, like, how many, uh, like, uh, how many those things are what you will have to set in the API where, uh, how many, uh, how much data you want. Like, uh, if it's a list of data and how many count of that list you want in that response at that moment of time, uh, when at on that page. So, like, I think use infinite query is their one, and then, uh, I think, uh, which is which is pretty good for pagination, I I believe, because if because if your list is, uh, like, you want both ways, like, going up, so you want to only enter those 10 for now. So you can, uh, basically, uh, like, if you are reloading the page, then you can remember the page. It will remember the page in the cache, and it will load those 10 for you. Then you can also, within final query, uh, loop it upwards or loop it downwards. You can, uh, use the next page to bring the next in, uh, parameters next in, uh, response for the in the previous, uh, page number to bring the, uh, previous, uh, 10 responses. So I think that's how you can use it. Yeah.

Well, uh, interfaces and well, first of all, are, uh, like, if you have status, uh, of an employee let's say you have an employee site, uh, like, a few employee role there are roles of employees like admin or just a normal employee or just a clerk maybe. So you, uh, you can have those statuses predefined statuses in an property. So you'll have clerk, uh, basic employee, admin employee. So depending on those, uh, roles, depending on that, you know, whether it's admin, you can have a different kind of functionality you can have. Uh, then with interfaces, uh, let's say there is an employee interface with some common data, uh, like name, age, employee ID, uh, and, uh, all that. And then there is an interface, uh, for admin where you have, um, some, uh, higher, uh, level of, uh, like, authorization properties, like, can access, uh, payment information or, uh, can make calls, uh, to, uh, can make calls to CEO or something, those kind of, uh, properties, and you can extend one interface to another. So let's say you want an admin employee, let's say, so you can use that employee interface and extend the employee interface with the admin employee interface. And now you will have a a big a bigger interface with admin and employee properties both. So you can do that. Uh, so yeah. I mean, that that's it. Like, it, uh, it helps, uh, like, it helps, first of all, to provide types to any large object structure. And enums basically facilitates any kind of, uh, rule or statuses you have, uh, in the app predefined that you know are not gonna change. So you can use that for. So yeah. That's how we

In an existing application, first of all, I will need to add the TypeScript library and I will have to set up the Babel properties and the ts-config, I guess. Once that's done, I think, depends on the application, like, first, the main important, if it's a JavaScript application, let's say it's a React application with using Redux, then it will have a global state, let's say, like in a reducer, so there I will be hitting first, I would be making sure that the reducer, all the properties in reducer that I am using, whatever that is, I will be converting it to types. Then again, let's say there are some common properties in the state, properties which are, let's say, shared in different state, we can have a common type for that and maybe some properties are different for a few components, we can extend, we can have different interfaces which extend that common type. Then also we could have enums, enums which, you know, like, if there are already some rules in the JavaScript app, some predefined values that are not gonna change and on those values certain functionality depends, so we can have enums for that. We can also use generics, generics is a dynamic typing, so basically, let's say, you have in the JavaScript app a lot of data coming in, but you don't know whether it's string, you know that it is having data, let's say, in type of maybe string or number or in array, so you can, with generics, you can define, let's say, use an alphabet like T for a type and that type will correspond to, let's say, it could be a string, number or an array, so you can predefine it to accept these kind of types and that becomes a generic. So maybe that would be also a very good way to, like, make sure that app quickly gets converted to a TypeScript app, so yeah.

With Redux action creators, we can use generics because with generics you can like first of all generics means it's dynamic typing. So if you like with what action creators basically are is they are just actions that you know change the reducer state. So a lot of times those actions are very similar with just different properties. So you don't have to write multiple with generics you won't have to write multiple actions again for updating each and every state. You can just have like a generic type which could take any of that state property like it corresponds like that type T should belong to any of let's say there is a state with a name, user ID, like employee subscription and everything. So that type T that's passed into the action creator should only correspond to any of those types and that way we will only need one action just to update that reducer state. So you can pass in let's say you are updating a state during setting the state in the reducer. For that you will need a separate action in a normal Redux action creator you will need a separate action for name, for user, for ID. Suppose you are doing that then like instead of that we can have an action creator with generics that could update. You could set anything and that T could be anything inside the reducer. You could also make it to have a function in there so you are just setting something or you are just calculating something and then executing. So those things also can be achieved. So yeah I mean that's how you can use generics.

Well, first of all, this dot set state is not synchronous and here it is called one after the other, therefore you don't know which one will get executed first. So that is a bigger problem here. Then this dot state of count, again another problem that this set state introduces is a problem of closure where the count property basically, closure basically means like you have JavaScript returns another function and that function basically keeps the values of the, let's say that outer function and inner function and outer function had few variables and the inner function is now returned, the inner function will retain those values of the variables, value of the outer function even if those variables are changed later. So that's the problem with closure and here since it directly using state, this dot state dot count, there is a problem of closure that can be created here where the count value will not change even if it's updated somewhere else. The set state will take the count value which was initially, what it was initially and will again and again use the same count value even if it's updated somewhere else. So instead of using this dot state dot count, we can use the previous property which can be like this dot set state provide previous property, well you can use that previous property and then using the previous property, it removes the problem of closure and gives you the current state in that previous property, it gives you the current value of that count state and you can then add plus one and if you are doing, in this dot set state, if you are trying to do two set states together, one after another instead of that, this dot set state, I think it gives you a callback. So you can add a comma after that first object and you can have a callback function inside there, you can execute the set state, the other set state. So that will be done one after the another in a synchronous fashion. So you can do that.

Okay. The the error here is the name of the screen, uh, home page initial route name home page. It is not there. Uh, it is not defined in the create stack navigator. It is home and details has been defined. So if you want, uh, to define an initial route name, it has to be one of the 2 mentioned in the create stack navigator. So instead of home page, it should be home. So that is the error.

If it's already an DRF, if it's an API route, then we will have to use, first of all, we cannot use server side rendering, I guess, because if I could just use the database directly, that would have been like we could have fetched the data from the server side, from a server component itself by using, by directly connecting with the database. But here you are saying that there is an API, so I think we will have to, we are using a server client component with any kind of hook to get the data from the API. So in that sense, I would suggest using React Query or any caching or even like any other caching library. Let's say we are using React Query and since you are saying that it is fetching a large data set, so I would suggest, since it will be a huge list of data, I hope there is pagination in it, so we could use infinite query or any pagination query and we could reduce that amount of data, like for every page, maybe, depending on how much data is there, we could divide it by, we could already make that possible in the API itself, where it, let's say, if it's a data of 1000, then maybe we would give only 50 for each page or 100 for each page. So that way, I think, first of all, we will be reducing the amount of data being fetched in the front end and also that data will be cached with React Query. So if the page doesn't change, the page number doesn't change or the user doesn't want to see any other data from that list, then you don't need to go and bring the data again and again. The React Query cache will provide it in case the user wants to, we can also provide a functionality where the user could specify a particular page in the front end itself, in the next JS component where the user could specify a page and he will jump to that page immediately. So in that sense, the data cache will get updated to that page data. So I think we could handle it. I think we will have to use, like, I don't know what DRF, Python based DRF is, but if it's API based, then I think we will have to use server components if it was directly connecting to database and we could have used, sorry, we will have to use client components if it was directly connected to database, then I think we could have used server components and directly got the data from the server itself, from the database itself. Yeah, so I think that's, that would be good.

The situation is successfully optimized. They react with performance in terms of both memory. Uh, first, uh, let I have, uh, like, the the best way to optimize, first of all, is Hermes. You have to use, uh, like, Hermes allows you to use, uh, like, optimize, uh, the it makes the app more faster with the Hermes engine, uh, in Android. Uh, with, uh, the app itself, uh, we can use, uh, for animations, we can use React Native to animate it because, uh, it allows you to, uh, use, uh, it allows you to have animations on the directly. Instead of JS thread, uh, it helps you to have animations on the UI thread itself. So React Native basically has a JS thread, uh, UI thread. Uh, so JS thread connects through to UI thread through native, uh, bridges, uh, which kind of delays that process. So with in an normal animated library, which comes prepackaged in React Native, uh, uh, that that's the problem. It doesn't, uh, it has to go through a bridge to connect with the UI thread. So instead of that, we could use React Native and reanimated library, uh, which also allows us to use worklets. Uh, worklets are basically, again, something that directly works on, uh, you know, UI thread and the computations are faster, so we can use that as well. Then you can also use use native driver property, uh, in some in lot of and lots of animations to make it, uh, like, faster, uh, to work on, uh, basically, the UI thread. Than, uh, that what the use native property, uh, means. Uh, we could, uh, like in order to optimize the performance, we, uh, I we can also use image caching library like react native, uh, fast image. Again, uh, like, uh, instead of scroll views, we have we can use flat list, uh, because most are most apps have lists. Most, uh, big apps have lists. So it's better to use flight list instead of scroll use because they are already optimized to only show the data that, uh, that we are that the user want is seeing right now on the screen. So the rest of data is not, uh, really rendered on the screen. So that helps in performance, uh, optimization. Other, uh, other things, uh, again, like, uh, I didn't know those things are, uh, enough, like, uh, means in in terms of optimization, like, any more kind of, like, uh, means, I'll they they, uh, there is a saying that you, uh, don't use inline styles a lot. Use style sheet because it's already optimized in, uh, to, uh, have better performance. Uh, but I don't know how much it affects, like but, yeah, I mean, uh, that's a good, like, uh, that that could be helpful, like, using a used style sheet property to write your styles, uh, and separate them out instead of having inline styles. So that that could be a good way to optimize it. Uh, apart from that, like, um, I think native driver, it's already spoken about it. So I think, uh, like, this this should be enough. Yeah.

First of all, I have never worked with a Django application. I have worked with Node.js applications and the common vulnerabilities that you find with web is obviously, first of all, is authorization. So the best thing I would say is, like, Veeam normally uses JWT or any kind of authorization, salt-based authorization, which, like, makes sure that it encrypts any kind of user info and then decrypts it perfectly at the backend side. Then we could, like, in terms of security, again, it's important to have the SSL certificate where, whichever, wherever you are putting it, like, let's say DigitalOcean or anything, you can basically create your, like, make sure to have an SSL certificate. Then I think HTTPS is obviously always used, like, never use HTTP for your servers. Apart from that, I mean, like, if you're using SQL, then make sure to, like, not directly use SQL in your queries to avoid SQL injection. I think the best way is to use some kind of, like, database layer, maybe, that, like, Drizzle or, let's say, Equalize, but make sure that you don't have anything in frontend that exposes your API route that connects to the database. It doesn't expose this, like, let's say an input is there, and if someone puts an SQL in it and it directly goes and hits the database route, like, that is something that you have to avoid. So, I think there, maybe, you can, like, middleware, you can have a middleware where you can have those kinds of checks where you can avoid, basically, any kind of SQL injection or authorization through, like, JWT or any sort method. So those things, like, you have to take care of in the middleware. Again, other security problems, like, I mean, those are the ones, like, I have dealt with, like, I remember. So yeah, I mean, like, I think those will be, like, enough, like, probably enough, yeah. So yeah, I mean, that's it, I guess. Thank you.