Ahmar Hashmi

Hi, everyone. I'm a software developer professional. My educational background is that I've done my B.Tech in computer science engineering from IIT, shifting course in the year 2010 and graduated in 2014. After that, I went for my master's and completed my computer science engineering from the prestigious IIT Bombay. I graduated in 2016. After that, I've been working as a software developer for a few companies. In total, I have more than 7 years of working experience. I started my career as a.Net developer with Angular framework, with the front-end technology being Angular. I have around 4 years of work experience as a.Net developer. Since the past 3 years, I've been working mostly on the JavaScript domain, and I have full-stack experience in Node.js as well as React.js. Apart from this, I have good experience in both SQL and NoSQL databases. I also have good experience in Docker.

To mitigate SQL injection risk in a Node.js application, we can use ORMs or we can use parameterized queries rather than hard coded queries or input, or we should use the ORM. Other than that, we can also make use of the fact that the inputs which are received from the front end, we check for inputs before running the query. We do sanity checks on the input to test whether the input is valid or not. So that is also a technique.

So to improve the load time of a single page application, which is built on React and has many components, what we can do is improve the total time by code splitting. Maybe we can split it up into smaller chunks, and that can be loaded on demand. We can also do lazy loading using the React router. You can also do optimization of the images and the assets. We can make use of CDNs. CDNs will also help. We can minimize the bundle size, specifically of CSS. We can do mini bundling. And caching, we can do. All these activities would help improve the load time.

So we would use separate interfaces for MongoDB and SQL, and bringing it to a common API, like, what I imagine maybe there's an API which needs access to both these databases, data in both these databases. So it will try to connect to each of them using their own respective ORMs, and it would fetch data or push data, whatever. But, like, whatever it would do, it would fetch data from both of these tables using their separate interfaces. And then based on the data which has been received, we can take action on that data. We can modify the data or apply our business logic to that data.

So for a content management system, if you want to design a MongoDB schema to handle multiple content types and their associations, we can have it in the form of a JSON, and we can query on this JSON object. Imagine that we have these JSON data stored in the DB. Each of them would have their content type and their association type inside. We can have the table name as contents, and contents would be having different content types. One content type can be an article or a text-based content. Another can be an image-based content. Another can be a video document-based content. The association array would be stored in their associations, to which related content they are associated to. Another association type can be. All these associations will have a type and a content ID. We can also have the author who is the author. There can be an author collection, and each content would be tagged to one author. We can also tag articles or videos with tags. So we can also have another entity called tag collection. This should be a good schema design for MongoDB to handle multiple content types and their associations.

So here, what we can do, we can make use of a logic search to or maybe we can have an in-memory cache, like that is. We can make use of that to store the most frequently accessed data in the cache. We can store them. And when there are repetitive queries, we can make sure it is stored in the cache and served from the cache rather than making a DB query. This is how we can implement the caching mechanism.

So in this particular code snippet, we're not checking whether the query is actually returning a user object or not. So we have to add that check null check over there. If the user exists, only then we can return a test dot status 200 dot JSON user. If the user object doesn't exist, then it would result in a 500 error.

So it can be the situation here where we're trying to find the user and update its email. So we need to first add a check before calling this find by ID and update. What I mean is that it might be that the user does not exist at all. So this if condition to check the user should be before calling this find by ID and update. If the user exists, only then we can update. So probably this should be the issue.

So in one of our previous rules, we had the entire application on Node.js backend, and the DB was MongoDB. So while we were met with the situation where the number of users was scaling up, our MongoDB database was getting slow. So we used the in-built feature of MongoDB to increase the cluster size. And, we earlier had only 1 node, so we increased it to scale up to 3 nodes and 1 master, 2 slaves like that. And, it would auto-scale on the basis of that. It earlier would be only 1 node, and maybe with the number of requests increasing to the database, it would scale to multiple nodes. So this was a feature of MongoDB itself, so that's how we managed to resolve this.

To ensure code quality, we run unit tests and find out the code coverage. We also make use of various hooks provided by GitLab to check that the code is of good quality and that all these tests passed before it would be merged into the main branch. This kind of code quality insurance is provided by paid repository providers, like GitHub or GitLab. We use GitLab. So at GitLab, we have done this thing.

So for managing data consistency, what we use is a message queue. And any changes in it ensure that different services are having these queues, and they push and pull data from this queue one at a time in that using the queue architecture, and that's how we manage data consistency.