Dhara Thacker

Hi. I'm Dara, and I have been, uh, working as a Ruby on Rails developer since past 9 years. And, currently, I'm working as a team lead in my current organization. And, uh, qualification wise, the highest degree of qualification is, uh, master of computer applications. Uh, I had passed passed out, uh, my post graduation in the year 2015.

Um, with the rate limiting, uh, there's a, um, I would say there's a line that we need to write in our middleware middleware file where we mentioned that, uh, what the custom rate limit is so that, uh, we cannot, uh, like, no one can hit the same API multiple times, uh, in in a short interval. So we can limit it, like, uh, certain number of requests in certain certain duration. So it's, like, it's called the custom rate limiting and that we need to do it in our config dot, uh, application, uh, config slash application dot r b file as part of our middleware feature.

Multi tenancy, I had done very briefly during my early days, so I'm not quite sure about that right now. No. I'm not sure about this.

Okay. Uh, whenever there's a 503 service unavailable error, firstly, we need to check our logs as to, uh, what what is breaking breaking the application. So there might be chances that, by any chance, some our server storage might be full or, uh, RAM might be, uh, utilized up to 100%, or, uh, maybe DNS is not available. Like, for example, if we are using Cloudflare and Cloudflare is not reachable or something like that. So we need to figure out, uh, what what is causing the error. We can see, um, the Apache error logs to figure out where the issue is. And based on what kind of issue comes up, uh, we need to solve accordingly.

I don't have much hands on on React at the moment, but, uh, I would say that, uh, the APS that we develop in Rails would be restful only. And in React, we can use the same conventions to create the routes accordingly as we do in Rails. And, uh, like, for example, if it's a user listing API, for example, then, uh, in React front end also, we can create a a a module of users. And in that, we can create the index function. So that would work. And in that index function, we call the user, uh, user index API of rails back end, and, uh, we can work it like that.

Okay. Um, so far for user authentication, I've been using device jam and JWT token to authenticate the request, uh, authenticate the user. How it integrates with AWS infrastructure? I would say that whenever there's a request for an API, the request would first go to our web server that is Apache, for example. Uh, whenever the request goes to that Apache server, it checks, uh, it checks, uh, that, uh, where it needs to redirect. And from that, it redirects the request to our app server. Uh, that is the rails. And from there, uh, rails would identify as to which controller and action it needs to send it to. Whenever the method goes through, uh, whenever the request goes to the controller, uh, we first verify if it is an authenticated request or not. So oh, there we test, uh, check if the, uh, authentication token of that user is present. If it is present, but if it is incorrect, then we send back an error. If it is correct it is present and correct, then we, uh, provide a required response to that request.

Okay. Uh, the before action filter, uh, would, um, would be the first thing that would run that would be executed whenever, uh, there's a request comes up to this, uh, controller provided it is applicable to that action. For example, uh, the required admin action is, um, execute is to be executed only when, uh, the request for new or create action is called. Similarly, the find user action would not be called if there's a index, uh, if there's a requirement for index new or create action. Apart from that, for all other methods, all other actions, fine user would be called. Now, uh, the issue with this, uh, I'm sorry, issue with this code would be, uh, in the find user action, we are using user dot find params of ID. So whenever, uh, the ID is incorrect and user is not found, it would throw an throw an exception when the user is not found. The ideal way would be to use find by so that even if the user is not found, we, um, there wouldn't be a an exception that would be raised. Rather, it would give us a nil nil error. Uh, like, it would return nil instead of raising an exception.

Okay. Uh, in this, if there's a service error that could come up, then, uh, the rescue with the first rescue will be executed where it says service calling service error, and it would, uh, print the necessary message. Yeah. And, uh, apart from that, if there's any other error or if there's any any specific error that we need to handle, then it won't handle it. It would directly go to the other rescue. But over there also, we explicitly need to mention as an exception that needs to be caught, and only then it would be able to raise the error.

For a service object in, uh, rails, uh, we can make use of, uh, the object oriented principles. Like, having a service object itself would, uh, be one of the object oriented principles as we are segregating the code. So segregating the code in a different section. So we were we are increasing the code reusability. So that would, uh, be one of the benefits. Secondly, uh, with the, um, with the services, uh, we can, you know, make use of proper inheritance as in when required, again, enhancing the, uh, reusability of code. Then, uh, let me think. Yeah. Uh, as we can have, uh, like, method method overloading in this case as well. Like, uh, we can have a method that would take up different parameters in different scenarios so we can have dynamic arguments as well. Um, in that way, we can achieve, like, function overloading as well as one of the features of encapsulation. So so, yeah, in this way, we can, uh, make use of object oriented principles in, uh, the sub subject.

Okay. Uh, to safeguard the sensitive data, firstly, uh, we can make sure that our API endpoint is also SSL enabled, first thing. Second thing, of course, authentication is there. Like, we need to authenticate each and every request. And, uh, the authentication token should also have an expiry so that, uh, it expires at after a certain time so that even if the by any chance, if the token is accessible to the hackers, then it gets expired, so they cannot use it to um, send bulk requests. Uh, then, uh, in our in our queries, the in the condition where we pass the parameters, uh, those parameters should be only the permitted parameters, plus it should be like, uh, the parameter should be sanitized. Like, um, we cannot simply write as user dot where ID is equal to and pass the ID straight away. We can use it as the hash parameter, like string string interpolation and then pass it in the, um, after the comma in the where condition. That way, uh, the the user the hacker cannot modify your queries by bypassing the values directly to the query as a part of in SQL injection. So, yeah, I think that's that's pretty much I can think of at the moment.

I'm not quite sure about animated trans transitions, but I think, uh, we can make, uh, make use of JavaScript for this. Like, uh, there are there might be various, uh, JavaScript packages that might come up with this functionality that that would enable us to do this. Or, otherwise, we can also use, uh, any other JavaScript feature. Yeah. Yeah. I think using JavaScript jQuery packages, uh, would help us do this. Like, for example, I'm not sure about the animated transitions, but for example, if we have, uh, some drag and drop feature or something like that, then we do have a JavaScript package to do that. So I'm sure that, uh, for animated transitions also, there might be some packages that would allow us to do that. So yeah.