Aditya

Marshall Badri here. I have been a full-stack web developer for quite some time now. I've had the privilege to work with some of the best web technologies out there, build web applications spanning across a multitude of categories. I have worked in the capacities of technical lead, DevOps, architect, individual contributor, and developer, building end-to-end applications on both the front and back ends. That would be just about myself. Yes.

So, basically, what I would do is I can give you my approach. It's basically, let's say I have a MongoDB cluster, and let's say I have a Node JS server already running. I'm implying that if we have a situation starting from scratch, then I'll install my MongoDB cluster on an instance. And once it's up and running, I'll configure the replica set itself because we're getting involved with data replication. And then what I would do is, there is this replica set name. Basically, I will set the configuration of the replica, initiate the replica set, and ensure that after application is happening, it should be. So, the initiate method, with the ID and members, all the data pieces, are there. And then I'll configure the Node JS application to connect with this replica. How I'll do this is that the MongoDB URI, the connection string that we use, we can specify the particular replica that we are referring to. We have the primary server IP, the port, then you can also specify the replica set. And then you can, with this property, provide the corresponding value, which will be the replica set itself. What will basically happen is that I can then use properties like reconnect or reconnect. Basically, what I'm trying to do is use this replication set. I'll try to access the data based on this replication. And if there are connection drops, I can retry. I can also ensure that the connection is maintained in a synchronized manner, so on and so forth. This would provide a high availability by itself. It's interesting inherently.

Yeah. So what I would basically do in this case is that, let's say, we have a React application and a server-side Node.js back end. In most instances, I would use Axios for client-server communication. The client sends a request, and the server sends back a response. I would set up the Axios instance. Let's say Axios is the library being used, and then I'll set up the default headers and the base route. So, the base URL to which the requests are being sent. And I'll ensure that we're sending the required authorization headers if involved, such as bearer tokens, and so forth. This inherently brings in secure API calls in a detached manner because REST APIs are stateless. Then on the back end, this token can be extracted, validated, and the requests can move forward in that particular manner. There are more headers which can be set to ensure that we are, and this also depends upon the back end because the back end has to be secure in order to utilize those headers. But, yes, this is one of the examples; there are many ways to do it. And this is for a React front end and a Node.js back end, let's say it's an Express API.

There are various ways to deal with it. One of the ways is spawning child processes because that's where you basically utilize the multithreading of the CPU at the maximum. Other ways to do it is you can use a library called clusters. So you basically use clusterization. And then, what else can you do? Right? So there are various ways to do it. Also, it depends upon the kind of situation you're dealing with. Another thing that you can use is that you can find the number of CPUs that you have, the cores that you have, and you can utilize them to the maximum. Because if you're using the cluster library, you can use methods like is master. So you can identify whether you're referring to the master code. And then you can spin off worker processes and run different processes in parallel. That's certainly a way to do it.

What I'll do is that both approaches I would say in this case is that both the approaches have their own pros and cons. I don't think there is one size fits all because sometimes what really happens is that you want to use it in most cases, if you had this option, in many cases, I think Mongoose would be a very good option. The simple reason being you're getting a declarative approach and a really robust one out of the box. Right? So Mongoose is written by a team of very good developers. You're getting a lot out of the box. You're almost always safe while using that library for schema validation. In other cases, you might not be using Mongoose at all for the entirety of the code base for an existing application. Then bringing in Mongoose just for schema validation might not make a lot of sense for you. Right? So, if you want automatic validation, if you want validations out of the box, go ahead with Mongoose. What I would say is that Mongoose as an ODM is a really good choice for the majority of the cases. But if you want certain sorts of flexibility, you want a kind of validation which might not be provided by Mongoose or any other libraries for that matter, or you want third-party integrations with those libraries, then a custom middleware might make sense in that case.

Yeah, so horizontal scaling basically can be done with a lot of methods. One is clustering, which we were discussing in one of the previous questions. And you can utilize multiple threads of your CPU, or run different processes in parallel. That is one way to do it. So basically, I have a master process that distributes processes out to child processes, gets back the results, and then moves on. One of the pitfalls of using this method is that you might want to use connection pooling. I say that because if you're using clustering without connection pooling and you're using clustering with MongoDB, you may overwhelm the database with a lot of parallel and simultaneous connections. The other thing is sharding. Sharding is a very good example of horizontal scaling. In sharding, you have to be careful about the configuration of the shards. Otherwise, you might overwhelm the instances. Another way is load balancing, which is a pretty good way to achieve horizontal scaling because you have an incoming traffic load balancer. It checks based on the configuration which instances are available and distributes the load accordingly. There are very good options out there. Another way is containerization, but containers can be very large, so you have to be careful about that.

Silence. Silence. So I have this example in which I have a Mongoose library being imported. We have to use a model using method to find one person by email. I call it. OK, I used to call it back as I say that user is found right. So the key patterns. What I would say is because that's a very unique question. And this piece of code is not very intricate as well. When it comes to anti-patterns. Yes, there are a few potential anti-patterns and areas of improvement that I see. One is that you're using callbacks. You can very soon reach a situation of callback hell. I would rather I would advise against that. If you can use promises, you must do that. Error handling, you might want a more robust or comprehensive one over here, for instance, in user dot find one. If you get an error, you're returning the callback with the error. I would say you might want to do a little bit more and log it. There is a lack of input validation. What kind of email are you getting? It can be checked. And, you know, there are no error types situated. So, you know, basically mentioned so on and so forth. So if you bring in promises, try catch, so on and so forth. I can see this particular piece of code improving.

Yep. So you can do a couple of things. If you're unmounting the component, you need to clear the states. You might want to call another API, which basically deactivates the session of the user. You might want to clear temporary storages, like local storage being used if any. So, you know, for instance, you get the user, but now you're unmounting and the user profile should not be available now and it's a protected route. You might want to clear out those credentials. You might want to clear out the cookies. Basically, it depends upon the situation you're in, but you might want to perform a couple of cleanup methods in component will unmount so that your components are consistent, your functionality is consistent with the expected results. So the actual outcome should match the expected outcome. And, yeah, I think that should help a lot.

So I would say this is another scenario which really depends upon the situation. I mean, it's again not one size fits all. And the reason why I say this is that you have these different advanced encryption algorithms. Right? You have SHA 256. You have AES 256, and so on and so forth. I would propose AES for various reasons or SHA. Then you can bring in how to implement this. You have libraries like crypto and Node.js, through which you can basically build hashes. Then you can do what you can do is if you don't want to use crypto, you can use other well-established crypto libraries such as sodium native or lib sodium wrappers. And it depends upon what kind of data you have. Sometimes you want to hash the incoming payload. You want to hash certain parts of the incoming event. And then you can use approaches like Diffie-Hellman exchange or exchanging the key so that only the source and the destination are aware of the payload and can decrypt it. So the source encrypts it, sends it to the destination, and then only the destination should be able to decrypt it. I mean, that's the whole idea behind end-to-end encryption. The key exchanges should happen over a secure connection, such as SSL or secure sockets layer, so I'm referring to HTTPS. You need to use different secure modes. There are different secure modes, such as when I say secure modes, I'm referring to key generation and distribution. You use HSM hardware security modules to do that. So, through this, it now depends upon what kind of compliance you have, whether you're talking about HIPAA, GDPR, and so on. I think you can pretty much maintain that through the methodology I shared with you here. And that too in a well-defined manner, that is.

Yeah. So best practices to follow if you want to secure REST API endpoints. Let's say you have a Lambda, it's mapped to an API Gateway. The API Gateway gives you an endpoint. First, you might want to set it up to allow certain types of requests. Then, you may want to expect a specific type of token. Let's say it's a JWT, a bearer token. You should have the secret key set up and secured, and you might also want to rotate them. The headers should be in a particular manner, and only the request should go through if they are all there and valid. The token needs to be validated for each request. You may have a middleware for this purpose. Then, you may put up a different shield, such as a WAF, to ensure the Lambda isn't overwhelmed by DDoS attacks, and so on. And, you know, the Lambda's execution role should not be accessible. So, following the principle of least privilege, you can use various ways to do it. There are many approaches to take, but these are some of them.

Okay. So we have rate limiting, and we want to somehow ensure that we are considering cashing and retry policies. Right? That's interesting. So what I would do is if, you know, we have an API for rate limiting, first of all, caching is a really good strategy because what you're doing is you can use packages like React Native async storage. You have these other options such as caching libraries, reactive caching libraries for basically caching the data. And it's important to understand that caching should only happen if the data is not time critical. If you're looking at data which is time critical and really needs to update and it's sensitive on that front, then caching may not be the best option. And so what basically happens is whenever an API request is made, the cache is checked first. If the output is available, it is returned. If the cache is not available or it has been invalidated for a particular time out, that's another thing to note that the time out should be carefully considered. If the cache is not there, then the API endpoint is accessed. The request is made, and the tender data is returned. Another thing is exponential backoff. If someone is hitting the APIs too frequently, then you might want to increase the delay between subsequent requests. That's what the exponential backoff is. And it should only happen in case of API failed requests. So because when they are going through, you don't want to disturb them. But this is basically one of the ways to apply rate limiting, exponential backoff, and the retries will happen within a particular duration. So you have different ways to do it as well again, but, yeah, these are a few of them.