Deephan Mohan

Hi, my name is Deepan Mohan. I'm a senior software developer. I have more than 13 years of experience. It should be actually 13, but I took some long breaks. In fact, the current session that I'm doing was after a long break. I have primarily done a lot of web development, a mix of Java and JavaScript for the most part of my career. I did my master's in computer science in the US. I graduated there and worked in a mix of full-time and consulting roles. I had to come back here to India in an emergency, but primarily it has been web development, JTV technologies, SpringBoot, SpringMVC. When you talk about Java, it's backend, but I started as a content developer, primarily doing JavaScript with DojoJS and also Vanilla JavaScript. This is even before Angular and React. That said, I have also done Angular and React. The recent version of Angular that I did last time was Angular 6 because my previous version was in a backend role and I was working with Golang. I can also code in Python. I've done a lot of work outside of both. That said, I have exposure to MySQL, relational databases, NoSQL, like MongoDB. I used a lot of MySQL though, commercial experience, writing relational queries. I've used ORM mappers like Hibernate and so on. With JavaScript, I've done React, I've done Angular, I've done a little bit of Redux. That said, I'm trying to keep myself updated with these technologies as they evolve. My previous role, as I mentioned, was a backend developer, but I got to work closely with another front-end developer. I don't do design. I rely on the UX developers, UI/UX developers for that. That said, I can do a little bit of design using Ionic or Bootstrap. The framework standpoint, I also have other experience in different other frameworks. Underscore, Handlebars, those are all very old JavaScript frameworks. I have also done Node, NPM, not so extensively. When you talk about more exposure, it's mostly about doing Angular and React from an application logic standpoint. I'm probably writing the rest layer using Swagger. Recent experience has been in Swagger. That said, I didn't do the front-end. I wrote the application logic in Golang. That said, I've used Spring Boot. We talk about other projects, different companies. Spring Boot for writing and creating the rest layer, developing the front-end Angular, end-to-end testing, and deployment. Sorry, from building to deployment. I also have experience in a different series of tools. I've used mostly, that said, I've used SVN and Perforce as well to talk about version control. With Git, I've got exposure to Jenkins, AWS, CodePipeline, CodeBuild, so that I can also work with big files. No problems with Linux either. It has been a full-stack journey for me so far. I've done both front-end and back-end, but you can throw me any challenge and I should be able to adapt. That said, I'm still learning.

This particular error, it's been a while since I used files. I'm just speaking from memory. So, the reason is that the file for the socket that's open for this, for checking if the file exists or not, it's still open. It's blocking. And, you know, it's probably not throwing the error. It could be throwing the error, but the files are not the sockets are not closed because it's blocking. So, one way to handle this is to use the async library properly, to make sure that the file descriptors are closed that you opened. There is one thing that I can speculate. Another thing is, this should be probably within a try-catch block, which is a much better way of handling errors like this. You'll get more details about what's happening because the error may not be thrown in sometimes, and it has to be handled. It has to be caught correctly. So, if you need more context, try to wrap it in a try-catch block, so that it's handled properly. But I said, my solution would be to go for async and try to defer the file descriptor, closing the file descriptor. Right? So that it is closed and it's not blocking on any errors that might happen along the way. I think that would be the way to go. Async is a good solution, and that should be a better way to handle this. This is the NPM library, so I don't know what it's doing behind the scenes. Mostly it's sync and fetch, and trying to defer the opening and closing of file descriptors. I believe that's what EPOS is also doing. You know, recall from memory for this particular module. So, those are something that I can think of. Try to handle that as within a proper try-catch block and make sure that you have more context about what's happening, which it is doing. It is turning it, but I doubt if it's getting caught correctly by the enclosing scope, the object that calls the method.

I think the action is not getting dispatched properly to the, to set the state of the particular account query component. It is probably not getting tied correctly. And maybe there is a timeout feature for the clicks. Between the clicks that would be, there is a latency that's involved and the clicks are not getting registered. No, I don't think that's the problem. I think the state is not getting set incremented correctly. Set count is supposed to increment count equals count plus one. That's what it's doing, then it will work. But otherwise, the set count is just assigning count plus one, you know, the initial value is zero. So, it is just assigning zero plus one, which means every time, it could either mean that the count gets reset back to zero after the component loads. After every click, it simply assigns, you know, the count value doesn't get incremented, probably. And it is simply showing what the current count plus one value is, but it's not getting assigned to the state. It's not assigning it to the state. And the state is not getting affected here. That's what I meant that the action is not dispatched correctly. So, count plus one could just mean zero plus one, you know, which is not getting assigned to count. The current value is zero, though, because that's the initial value we started out with. So, it's just printing, you know, count plus one, but count has not taken the value of one. So, if it takes the value of one, the next click could say, one plus one, which is equal to two, you know. But that is not probably what's happening. The set count is not assigning count plus one to count. And I would make sure that it is doing what it's supposed to do. Set count is doing, it's assigning count plus one and assigning it back to count, which is probably what is not happening here. For some reason, the state is always zero and it is not getting incremented. What you are seeing is just zero plus one.

Redux is a good option, especially when the interaction between the components on the client side is large. There's a lot of components to be designed and defined. And these components need to share data and pass on data to different components. It's based on actions and events, and then Redux is a good way to go about it. There are also other libraries, such as MobX, and other flavors. For state management, Redux will be the best bet because it does a good abstraction of over React for maintaining state. You can also take snapshots of the state. You can roll back to a different state or, based on your timeline, do analysis about how your application behaves over various timelines. And you can roll back the states to a consistent state from a previous timeline. You have that flexibility with Redux, with some action dispatches and so on. So, the Redux would be a good choice. The recent portions of Redux, I don't have much exposure to, but that's why I have done Redux. But, there should be more pieces than the previous versions. And, that'll be my choice. Otherwise, you have to define your own state management type of how you would go about doing it. Maybe you have to write your own libraries for how you manage the state based on options. You know, how you capture it, where would you store it, and most importantly, how do you make sure that state is shared and components are inherited across which is supposed to be reusability and reduces boilerplate. All these factors come into play. And, it will simply be easy to go with the industry standards like Redux, because it reduces the developer time reinventing the wheel. And, you can put and choose what you want. You can reduce the size of your library, it's pretty lightweight. You don't have to use only the dependencies that you want, and you can reject the rest. And, so Redux would make your life easier, especially from a consistency standpoint. It's easy to monitor the state and go back. You can also deprecate some features and there are a lot of other features that you can think of, such as backward compatibility as well. And if you're using something like React, it just works well with the React framework. Because it is written on top of React, it means it makes things easier, but it goes well with React. The normal pressure of this impact semantics suits the React ecosystem. So, the Redux would be a good choice for state management.

For back-end services, a lot of things you can think of, what is the service? What does it handle? Like, is it a relational database that it talks to or it's a NoSQL database because it's more structured data, you're running more, you know, structured queries, then you may have a different flavor of how to handle concurrency. On the other hand, if it's like NoSQL, or like MongoDB supports, it's highly scalable. It supports a lot of horizontal scaling, it's more optimized for that, but not from a consistency standpoint, right? So if you're more worried about consistency, then you may have to go for relational databases, in which case, for handling concurrency, you have to introduce some messaging frameworks in the middle, on top of all the best practices that you do, right, like caching and, you know, thread pooling, so on and so forth. Right. I'll just go with, I'll go with NoSQL first, if it is, if it is not, if you're not worried about consistency, because it supports horizontal scaling, on-demand scaling. And if you're using it on a, you know, a serverless environment, like AWS or GCP, you can scale based on, we have two different kinds of scaling, you can do it like predictive scaling, or you can do like reactive scaling, predictive scaling, meaning could be seasonal, the kind of load that services handling could be seasonal, not throughout the year, but on specific time of the year. In that case, you can auto-scale your clusters, if it's deployed on Kubernetes, or, you know, if it is, if you're using NoSQL, you can, you can horizontally scale the number of instances for NoSQL, based on the demand, or if it's like reactive scaling, then the infrastructure AWS or GCP, they automatically do it for you, even Kubernetes can support that. So they automatically detect the demand and they auto-scale the clusters. So this is for NoSQL, if it's like relational databases, then they're more worried about running complex queries, and, you know, handling millions of concurrent users, then you may have to go with some messaging frameworks like Kafka, or, you know, RabbitMQ, which you can set up your brokers, you can set up your topics and partitions. And these frameworks can handle millions of requests per second. And they take care of scaling as well. And then you can, you know, you can set up your monitoring and, you know, lobbying facilities with Kafka, you can use it for data management, you can also use it for queuing, you can pretty much do everything you want, you can replicate your partitions, and you can, you know, auto-scale the, it also does a lot of load balancing itself. And as I said, you can have a load balancer at the top of your application, which can take care of, take the load off mostly by reducing the reverse proxy in the middle for caching frequently used data. On the other hand, in an application standpoint, you make sure you do all the best practices, you can, you know, set the maximum, you can increase the thread pool, you can try optimizing it, you can use asynchronous processing to make sure that every thread handles a lot of parallel requests, every thread can do that, not simultaneously, but async, meaning it can handle many requests per second, make sure we can do that. And you know, it doesn't have to be, you follow all the best practices, you can optimize it, you can, you know, you can set up a min cache layer for frequently cached data, it takes care of, there are different retention policies, and you can do all this with Kafka as well. So you know, so from a monitoring standpoint, you can use Prometheus, Grafana, or, you know, Elasticsearch, Logstash, and Kibana, look at query logs, see, you know, profile your database queries, if it's taking a long time, in an RDMS, you can just explain the query and say how much time it took. But otherwise, there are a lot of profiling tools available to look at these metrics.

Okay, first thing I would do is, I'll try to see this change works correctly on my end by creating a separate branch, a dummy branch probably, pulling this pull request, seeing if it works as I expected and does what it says it does for this entire description. And I tried to understand what it's doing. If the developer is not directly involved in the feed, so when I commit and he wants me to take a look at it, and I have to make sure that the functionality is working fine. I have to see it both. And that's the first thing. And after that, I look into the functionality. It's a back-end change. I look at it. You can go both ways about it, whichever has precedence. I look at the logic of what it's doing from a back-end standpoint. And make sure you can probably try to even isolate it, the front-end part and the back-end part, to make sure that these pieces are impacting correctly. Some data is getting changed or sent between these pieces. Make sure it's sent correctly. And there are tests written, and then I want to make sure the tests are done properly. That is something that I would look at. That would be the last part. The first part is making sure the functionality intended is working correctly from a syntax standpoint, from a semantic standpoint. So that the application logic is intact and it is doing what it's supposed to do. Then we take a look at the tests, try to see the tests are working fine, introduce more tests. Sometimes there could be some regression issues of hiding. Try to make sure that it works from a concurrency standpoint. Address all those kinds of issues, type safety issues, threat safety issues, immutability, some anti-patterns that can be recognized can be addressed. Security standpoint, make sure that you know, some things like SQL injection, cross-site data. All those are handled properly. And then talk about testing in different kinds of testing as I already mentioned, the unit testing, functional testing, integration testing, and load testing if that's possible. If it's a highly scalable application, then you have to load test it, see how it performs, and make sure that there is no resource leak. These are all the factors that we have to consider. We can only go so far with some commits. You don't have to be so aggressive. It's early in the development. If that is the case, there are more things to come and make sure that you add documentation and add comments in your code so that another developer knows. We have to point out that. We have to make sure that from a functionality standpoint, the requirements are getting set properly, and it is getting executed properly. You know, using something like REST. And I know it was being proved, but with REST, you can take a look at the Swagger team on to see the model is what it is set properly. And from a back-end standpoint, I should almost reflect the same functionality. It is probably the right thing. Solid principles, try and all that. My time's already up, but those are some best practices I can think of.

Okay, a lot of things you can do. First thing, if it's a front-end web-based application that has a back end, which is the case in most applications, you can use a CDN, content delivery network, and like Akamai or, you know, there are other CDNs as well, where you can cache all the static data. This would significantly reduce the load time from a front-end standpoint. You can fetch all the static contents from those websites, especially when there are a lot of requests and a lot of traffic. The next part is, you can use a load balancer, and for the most part, the CDNs themselves are pretty powerful in doing it. Otherwise, you can specifically set up your own, there are a lot of load balancing options, messaging systems themselves can do this these days. They do a pretty good job of spawning new instances, when talking about Kafka, for example, spawning new instances, you know, replicating the partitions. They do a pretty good job and they do it dynamically based on the threshold that we set. We can also set the retention time, caching policies, and so on and so forth. If you're talking about asynchronous processing, comes to threading, it's a Java application or whatever application, you can try using the threads. You can use a thread pool behind the scene, a lightweight thread pool, JDBC library like Hikari is a very good library. I can set the thread pools, and each of these threads can act independently, which can take off a lot of concurrency. You can make sure that you write asynchronous code, make it asynchronous. You can introduce streams, you can use something like Project Reactor's WebFlux, Mono, or Flux, you know, behind the scenes to make it real-time. That's a significant improvement, streams can be difficult to debug, it's very complex. But if done rightly, it can take care of real-time messaging pretty well. You can do some caching, as I already mentioned. I can introduce a reverse proxy in the middle, or you can have something like Memcached or Redis, where you can fetch the frequently used data. You can fetch from the cache first, if it's not in the cache, then you go to the database. That said, the databases themselves are industry-tested for a lot of concurrency handling. They are optimized for performance, you can reduce the load, you can introduce data compaction, you can do some regular jobs, you know, it's all about extracting the data, deserializing the data, deserialize it, you know, from the back end, make sure it's compact and it's fast, use some good compression algorithm to do that. And a lot of the tools they provide out of the box in this case, so it's not a problem. That said, you have to take a look at the application logic, make sure that your algorithms, if they are used or using the optimal data structures, take a look at the queries, profile the queries, keep them efficient, thread them, if there is some Java, you know, I mean Java, for queries should be done.

Okay, there is a lot of decomposition best practices for moving from a monolith to microservices. First thing is to define what a microservice is, which should handle a single responsibility only. It is tolerant, can autoscale, supports easy testing, supports easy deployment, supports easy rollback. And those are some things that are good about microservices. It manages its own state, and the initial lightweight version can handle a lot of load when done correctly. For migrating from monolith to microservices, one of the best ways is to use a 12 factor application, which contributes to how you think about structuring your architecture. I'll give you a brief overview of the 12 factors. The first one is to ensure there is only one code base, if you're using Git, make sure all the code exists in that particular repository. Then take care of the dependencies and isolate them for this application. You run it, you package it, you scaffold it outside your build, it's not part of the code base, it should be external. The third one is config, make sure the config is managed through a dedicated config server for providing configuration properties for your application. The fourth one is that each microservice should handle its own data, like an instance database, and it should be stateless, none of the services themselves should store stateful data, but instead go to the backend and retrieve it. Building and deploying and running that process should be separate, right, like AWS CodeCommit and pipeline. Your CI/CD operations should be independent of the code base, you should talk to the code base, pull the code that way because each of these processes has inherent risks, introducing risks that might significantly affect the going live time or the developer productivity. These have been segregated separately. The sixth one is processes, you make sure that again, a stateless process, you know, REST would be a good way to develop your applications, so that none of the state is stored anywhere. It's faster, and it's easier to understand. You have to bind your code to specific databases, like this port only talks to Microsoft SQL, right, MySQL, this port only is required for configuration. And you know, isolation is data porting, it's called data isolation. And the other ones, I don't have much time, but I'll try to be faster. So, keeping your admin tools separate, like CloudFormation for log monitoring, logging has to be separate. There should be a difference between dev and prod parity, both the branches should be different, and dev should have the most up-to-date code. There should be disposability, you can use and throw, and fault tolerance.

The first thing is, best bet is to use a relational database, MySQL full screen. Consistency means going to a free tier regardless of the number of instances of your backend service, for each node, you should get the same answer. So that is consistency. One way, to do this for the most part, is if we are using a relational database, make sure that they are already industry tested and they do a better job with ensuring consistency is handled. But that said, if it is a lot of requests, then there has to be replication of clusters. I have to partition the instances, and we have to make sure that the data is in sync right, between the instances. So in that case, you know, there is either the replication itself is not instantaneous. There is a little bit of latency, due to the physical network ops. It cannot be instantaneous. Right? Within, there could be some delays. But during the downtime, for the replication or whatever time that is for replicating your clusters, you have to make sure that there are no read requests coming in because we don't want stale data to be returned from the node that is expecting the recent change. So we had to take some best measures like that. And, we can introduce some caching layer. Caches these days do a better job of syncing. They can pull the database or they can pull the application to get the recent data, keep it in sync. Can I do some retention policies? If you know the kind of request that's coming in, right, like, you can divide your nodes geographically and serverless environments like GCP or AWS do this automatically based on the region. They do the replication. You can see the kind of data that's coming in, the kind of request that's coming, and you can cater to those needs. Some rates may not need the recent data. In that case, you can switch it from the database to the cache. But, otherwise, if it has to go to the database, we make sure that it doesn't overload the database. We make sure the currency aspects of it are handled properly. And, when it comes to read, write, we make sure that it's synchronized. If it supports a lot of reads more than writes, it's much better. Consistency is a high-importance operation. There should not be any issues. Right? Because, really, it's just going to return the value itself. That's there in the database. In that case, you just have to make sure that if you're using caches, some data is regularly updated, without much latency. But, otherwise, there are a lot of writes. Then you make sure that there are no lags in between, especially if it's a more sensitive request that has to return the recent value. You can optimize your database for read and write. You can introduce a lot of heuristics in between to cater to those kinds of needs based on the requests. We can do a lot of optimizations like that. My time is almost up. So, yeah, the results on this.

So maybe the action type that's coming in is probably not doing the right thing. So this keeps returning the state because it keeps going to the wrong switch case. In this case, it goes to the default case that it simply returns the scope. It doesn't do the push operation. It's not getting appended. So probably have to take a look at the action that's coming in. The type of action has to be add item, and it's add item, then the item gets the action payload gets pushed to the item setup. Otherwise, I think that's the problem here. The action type has to be add item. The items array is immutable. So you have to create a new array. You have to push the item and set items to it. So because it's const, the items that is const. You have to make sure that every time it's appended, you append and you create a new array, append the payload to it. Take the items. Create a new array from it. Push the action payload to the copy because it's mutable. Then, send it back to items. In this way, it's immutable again. So the state doesn't change. It's not affected by another push item. Take a copy of items, push the action payload to it, then assign the copy to items object. In that way, it becomes immutable. I think that's what it should be doing instead of directly pushing the action payload to items. Because it's an immutable object, shouldn't be changed. A new instance has to be assigned to it, if there is a change. Because the state if that changes state, we have to do it the right way to ensure it's immutable.

That's a tricky question. There is something called DevSecOps, security ops. She recommends that security should be taken into account from the start, hopefully, in every step of the process from packaging to deploying your application. Because this approach reduces a lot of issues in terms of addressing the problems that you might face later on after going to production or after going live with your product. DevSecOps is getting a lot of traction lately. From a security standpoint, we have to make sure that we follow all the best practices. If you're using an API, make sure the API keys are stored correctly and not shared publicly. If there are services talking to each other, the handshake should happen in a secure manner. Make sure your front-end application uses SSL domain termination for all your website's endpoints. Start with HTTPS instead of HTTP. Ensure necessary termination and take care of the hardware use of the hardware NOS. That's the validation, then the requests are handled. Take care of the back-end standpoint. If the authorization and authentication are in place, like OAuth, which is pretty heavy, there are also lightweight options, like JWT. In a serverless environment, you probably have high-end features, such as authorization based on roles assigned to specific groups of people with more privileges than others. These are taken care of from the start of the application and follow all the best practices from the back-end standpoint. If you're using IT SQL, make sure all the security loopholes are closed, with no interest in SQL injection. Also, from a load balancing standpoint, make sure DDoS and other products are handled gracefully. You should also make sure that your monitoring alerts are set up properly, so that based on the logs or traffic data, it sends prompt alerts to the users, developers, and stakeholders, so they can take a look and find out any abnormalities. You should do endurance testing for your software to make sure there are no resource leaks. Other things include making sure your API is secure behind a firewall, and there's an API gateway that comes with it and then goes to the back end. My time is always short, but those are some best practices.

Okay, I think in the previous job, we worked with a UI/UX developer and I've done this with a couple of people in my other jobs as well. So they usually give the wireframes, they do it and they use tools like Figma, so what are the other tools, but yeah, there are ways to do that and the developers can take a look at it and post some comments on it. All these requirements are coming to them, to the UI/UX developers from the stakeholders. They give us the wireframe, it's all about using the wireframe and seeing if it works in a front-end application. So it's all about including those assets, CSS, and the glueing code will mostly be JavaScript or TypeScript, Angular. So make sure these components are defined, you define the components, it's fetching these wireframes and doing what it's supposed to do. From a functionality standpoint, the requirements are sent to them clearly and they do it correctly. Otherwise, it's the role of the developer to tell them what it's supposed to be doing and there are some changes that have to be done aesthetically, get the help of UI/UX developers and make sure that it's taken care of properly. For instance, some functionalities, some dynamic functionalities may not be given to them explicitly. For instance, developing some component, let's say a text box or a button, and it has to dynamically change color or it has to show some popover, a tip kind of markup. And we have to make sure that it's communicated to the UI/UX developers so they can include it as a part of their design, make sure it's complete. And I have to tell them that this is the requirement that I need when this action is performed and the action is, of course, taken care of by the developer, the front-end developer. For instance, if it's a mouse move or hover over or a mouse leave event, this should happen in your asset and this action has to be taken care of by the developer. But what happens to that asset, that particular button or text box, that particular HTML element, what happens to that from a style standpoint, there are some state changes and transitions that happen behind the scenes from an HTML and CSS standpoint. I have to make sure that is communicated to the UI/UX developers so that they can include it as a part of their wireframe design. And those are some things that we have to do with them. Otherwise, they will give you the assets and you simply include that. You can probably think about optimizing the markup so that the boilerplate can be reduced and that is their job, probably to do that. But if it's an in-space issue that we are using, that's creating, then you have to make sure that you have to address all those issues in your front-end design to make sure that the boilerplate is reduced.