Tuhin Samanta

So currently, I am working with tech at IBM, since the last two years. And the project I'm currently working on is for the telecommunication company MTN. I'm working on their back end, managing their customer portal, managing recharges, and all. It's basically created with Node.js and the Loopback framework, which is utilizing TypeScript. And along with that, it's using MongoDB and a SQL-based database as well. Before that, I worked on IBM's internal project called IBM assets, which was a huge east-west project. And then before that, I worked on another project that was called Ulta Beauty Salon, which was a US-based project. It was a complete salon system, and their back end was created with Node.js, Express, and PostgreSQL along with Redis and GraphQL. And for the front end, it was used React and Redux. My role there was a back-end developer, and I actively worked on both parts. Before that, I was in another organization called TechnipForce. When I joined, they were recording services. I used to work on their WordPress plugins and WordPress plugins with PHP and with manual JavaScript and HTML/CSS. Later, they promoted me as their PHP team lead, and I worked on their couple of SaaS-based applications like Cloud Panels, Course Panels, and subfunnels. These are basically cloud panels, a prepared project, actually. Where it was, like, people can create their complete website upload through drag and drop, like, create members and it's automated email autoresponder, and it was integrated with a lot of third-party payment methods as well to automate sales membership and mailing. So it all the things, like, people can just install the software on the server and can easily integrate these things through drag and drop. So that's the thing. And utilizing that corresponds was created, which was basically a self-hosted element system like Udemy or Udacity. And Shopify was an alternate to sub, like, Shopify was an alternate to Shopify. It was also self-hosted. Next to it, I moved to their JavaScript team. My past project was a Pursue app, which was a cold mailing autoresponder. It was created with Node.js and Express and MySQL in the back end and for content. And all the applications that I mentioned, they are most of the memberships used to be created and payments like that kind of places for customers who are purchasing was used to create with React JS. And for the main application, we used mostly Vue JS as well. And that was a complete mailing autoresponder, cold mailing autoresponder so people can drag and drop and can put, make their sequence flow and all. Next, we created a browser based on Electron. So it's called Logi. So it was also

So the MBVW strategy, I will be using. There will be routers and their pages, and each page will have access to I will have different folders for my components, where I will have individual components for my videos and common components that I will have will be in a different directory inside components where I'll be using them everywhere in common places on other components. I will have a place for my storage, so I can store basically my Redux stores, and I will have my style, and it will have a structure provided by an engine CSS. They are also directory-based on common if they are common in the CSS files, they will have a general directory. And based on other components and pages, I will have a proper hierarchy and store them properly on a different folder. So that's where I will have the n b file on my root and also the index file. So that's the thing. And on my public, I will be storing my images and all, while maintaining the structure.

We can use a Jenkins for this purpose. So, what it does is automatically run after you push and after creating a PR when it's approved. It automatically does all the things if there are any issues, it runs its tests. It tests them with the weather, I assume you mean "with the weather conditions." All the test cases have proper syntax and good structure, then it can run the test cases itself. And once all the test cases are done, it deploys itself into the specified place. That's how it helps to go through a proper practice and does the automation itself where humans sometimes make mistakes. So, it doesn't deploy until everything is working well.

So earlier, we used the pattern for the back-end application called the emission structure where we used to have all the models in one file. So, basically, they are data or database models. Maybe that may be a civilized database model. So, that the things and the controller basically, like, the controllers are our functional things that will merge and connect our route and those and the models that I'm using, so that's the thing. But nowadays, we don't have that view card. We used to create our separate application for view. So apart from that, what we used to do, if we were using our REST API and also we basically used routes there or API folder there and used your structure. Our separate API with proper hierarchy that's easier under a proper under a, like, that is a parent path. So that means that path, we can, like, create a separate proper folder structure and routes inside that. And if we were using, like, a GraphQL, so we will have a proper GraphQL folder and there, the proper structure again for individual elements and individual workflow. So I will have the proper structure. And there, we will have a proper folder for utilities, like, where we will have our helper concerns or the library files that we are going to use, like, commonly. So that's the thing. And in the room on the room there, I should have a config folder. So config, basically, it's like, it's updating each hour in dotenv file. We can, like, specify, but the config file is the thing that where I can, like, stick to checking, like, whether all the things that I need, all the keys are there or not. And programmatically, we can modify that, you know, keys and all if we need. So that kind of restrictions we can keep written in a config file. So in that way, even if there is something wrong in v, so it forces us to go through a proper, practice. And for and for scalability, we can do one more thing. We can like, if it's a programming perspective, we can for a large-scale application, we can think of using cluster and that you will utilize the multi, processing. And so in that way, we can make it as, like, scalable. We can utilize the huge release there for our caching and all. So for collaboration, the structure and that structure, in the, like, trajectory and code and, you know, folders are important as well. Also, the proper flow and it, you know, just like I just mentioned, some places we may need to use cluster for proper relations, proper when we are using the, you know, database system. So structuring them properly using indexes properly, connecting the by probably, to, like, to make to, you know, make them visible proper. So there are a lot of good things that we can do there.

So, virtual DOM is basically without using the actual DOM tree. We don't modify or use the actual DOM tree. React is doing, like, it takes the difference of a proper DOM element when we create the root element. So, it sticks a reference there. And instead of modifying the entire document, it does whatever it's doing after the state changes or props change. It re-renders things and uses that DOM element itself. So, it doesn't modify the entire DOM or interact with the DOM team all the time. That's the way it works. Now I can explain how it works. Let's assume we have a React application, and we have an object with a getter, a setter, and an init method. So, let's assume we have an init method that takes the parent through query selector or get element by ID of a specific element that I want to render. Now, let's assume when we're using a getter, we're assigning something through get. So, if that variable is used in my content somewhere, in the element that we're given, if we have content inside that, we can modify the HTML or it's a very busy example. In our HTML log, it creates a proper DOM tree where the elements are modifying, I mean, DOM portion it's modifying is just rendering that portion in a React viewer. But for the sake of example, if there's something I'm providing and it's the variable getting changed, I can modify that variable value directly, and it can do that in our HTML. So, like, JavaScript also has getter and setter, and JavaScript now supports a proxy. So, with proxy, we can also do these things happening. In such an application site, React reaches the virtual DOM without modifying the entire DOM element, or entire HTML. It just takes a reference of a variable, and whatever we're assigning things, assigning its child components or all are working there. So, all modifications are applying there. This is how the virtual DOM works.

So one way, like, if it's a component level, we can use an effect to hook with like, it to maintain side effects so you can pass the additional array. So inside the only tool, like, get the content. It's only one time it will trigger after the hashed agenda. So each time it renders. So I mean, each time it mounts, so it will be running one time, and we can use React or Axios to call our APIs. And, also, you can use custom hooks for our logic that our API call that we are going to call multiple times. So if we use a custom hook so that there it will give us a benefit to hide our logic in one place and to get benefits from other components. And another practice is that we can do if we are using Redux so that we can also use Thunk middleware. Also, in Thunk, basically, it's used to handle asynchronous operations. So there, we can place our API call. And another place that we can do is we can create our own middleware. So in our own middleware, we can also use three arguments, namely the store, the next, and the action. So when you are getting the action based on that, we can do our API call and whatever the values, then we can pass it to our store itself. So that's not practically used, but that's possible. So there if we can when we get things happening, so we can pass that. We can modify the store from there or pass the payload to the next. So it will also work. This is the couple of ways that I've been saying. So this is the way of asynchronous data patching. And, yeah, also, it's an asynchronous start task. So every time we are doing an API call or when the promise got resolved, we need to maintain the state. We should update the state if it's in touch to suit, maintain the state. And, also, we should handle the errors to throw the catch person, and we can use a proper error handler to handle errors as well. So, that is basically a state itself, state manager, where you'll have error and whatever error happening there. So properly based on that, I will show a different component that this error happened. This is the way how we can handle errors in async on a start data bridge.

So here, it's not maintaining the immutability. So what happens is, JavaScript objects, each JavaScript object, used to have the mutability thing. Doesn't matter if we assign it to a defined variable, and then we are still modifying it. They are like it's basically modifying that variant object that it has the reference. So in the past case, what we are doing, we are completely getting a new object there by spreading these dot stated items. But later in the code, we are just modifying the items by concuring their new item as an added. So that's the one problem. And another thing, there is also one key I'm seeing that a new item. So yeah, that's the thing. It's not going to provide any more this new item. So based on that, we could spread it past the state and then whatever we are going to modify there. So in that way, it will be doing that, it will be a better practice to maintain the immutability. So in this code, that's not working. So that's the problem. What we could do is spread the this set state and then spread the state passed. And then inside items, I could take Like add in and then only spread their heat and add a new item there. Basically, there is a library called Lodash. So it's also beneficial in such cases to handle and maintain the immutability.

So here the issue which we are not assigning, we are taking the numbers and running the for each loop there. So now we are getting there as well. But what we are doing, we are not assigning that to some. We're just making the sum plus num, which is basically will do nothing. So what we need to do here, sum equals sum plus num. So in that way, it would do the actual sum and sum plus equals num. So that, in that way, it would give us the proper result.

So, the best practice would be using a nonce. So, nonces are basically a one-time key. So, whenever someone is rendering the application, I will give her a proper token ID or a system ID so that it only works for that specific screen. And once that, we can restore that in a stored variable or maybe in a session storage. So, when the user goes through the form, that would be also passed there. And in the back end, I will check that, whether it's a system that was created or if it's a JWT token, so whether it's a valid JWT token and it has the validity or not. And in that way, I can make sure that the nonce with that nonce is going fine. And also, what we can do is encrypt data. So, in that, we can try encryption of our data. If it's high-volume data, we can break them into chunks and consider sending it to Azure. It's like a performance thing. So, in that kind of business, we can consider chunking. Otherwise, for integrity, maintaining the integrated token is one thing. And another thing that can be done is creating a proper session. Now, this session is not using cookies, so we can consider using a proper JWT token with the proper expiry time so that it gets expired even though someone is copying the cookie from one browser to another. So, it will not work. And what else can be done is rate limiting, with a specific time, so that the back end will only allow a specific amount of requests. And next, it will stop taking the request or itself with a delay and then take the request. And basically, for when we are passing any data, which is required to have high integrity, we can try that and use the token thing that we render our bids with. It automatically takes it from the back end and can, whenever we are making the request, pass the specific system's token. That will ensure it's coming from a proper source and will maintain the integrity. And same for the front end to front end, we'll pass the proper token and verify that as well. So, that's the thing with proper authorization.

Yeah. So, integrating the part is like a highly beneficial thing. It's like a two-way, like, authentication. First of all, we just need to place at that whatever username or password they need. So, next to it will redirect them to a specific server endpoint. So after that, it will generate some sort of token and all, and we'll authorize the authentication request. We'll again get back to that page with the proper JWT, I mean, proper token that will expire after some time. And all the requests that we send in will be using that token. So not only that, if we're using Gmail or other logging systems, they also maintain this flow in a very authenticated way. They already have the endpoint and all which you need to whitelist. So it mentions complete security. Whenever you're making a request, it takes the token, checks the validity and all. This is how it's been updated.

I'm not sure about this question, what it's asking, but if it's a performance thing, so I will. If it's in the application level, so I should consider using a high load balancer while we are doing a lot of processes, and a lot of users are using it. So from the application end, we should do that. We would use a system to preserve data that are frequently needed. And from that perspective, I should be using a SQL-based database, indexing, and also consider new database cache configurations. Whenever possible for long-running data, I will try to utilize worker threads. So in that way, I will try to make sure that the back end is always available to solve requests and perform my content even when I am solving a lot of requests. Even if you select 1, we are doing CPU binding to the task, which takes a lot of time. So in that kind of cluster, it's going to help us through multiprocessing. And again, I will take care of the event-driven approach of React, including workers. So that will make our application efficient.