Ashrut Panchal

Hi. So thanks for giving me a chance to, uh, introduce myself. My name is Ashut Panchal. I am a Ruby on Rails developer. I have an experience of, uh, more than 5.2 years. And, uh, in these, uh, more than 5.2 years, I've been a part of, uh, many projects, uh, which are monolithic applications or microservices. Uh, in all these projects, I have integrated a bunch of APIs. Uh, I worked on many third party, uh, API gems and, uh, 3rd party API integrations. As far as front end is concerned, I have worked on React JS, Vue JS. And, uh, as far as JavaScript is integration of other kind is concerned, I have worked on jQuery. I have worked on Rails UJS, Stimulus JS also with Rails 7. 7. In Ruby, I have worked on 2.xand3.x versions of Ruby. In Rails, I worked with 5.6 and 6.1.4, uh, 6.4, and then nowadays, uh, rail 7.0 as well. Uh, I have worked on multiple versions after rail 7. Right? 7.0.1 or 7.1 is, uh, also there now in market. Uh, and, uh, as far as other technologies are concerned, I have worked with Redis. I have worked with Elasticsearch. I have integrated Elasticsearch, rails, and Searchdig gem both in my Ruby on Rails application. I work with Docker, uh, for, uh, to enhance, uh, how other developers are working, uh, with the application. I have, uh, done deployment on Heroku and, uh, AWS both. In app AWS, I have used Elastic Beanstack and uh, Amazon, uh, and a a w AWS EC 2 instances for the deployment. Uh, also, for the deployment, I have, uh, used the ELK, and, uh, that is Elasticsearch, Logstays, and Kibana. This is in that is integrated in Amazon. And I have, uh, done, uh, integration of some, uh, I have deployed some, uh, Elasticsearch clusters for, uh, the Amazon for the AWS instances that were created for the app. It was a very big project on which I was working previously, uh, about which I am talking about. And, uh, there are many, uh, third party API integrations for payment as well that I have done. Uh, to name a few, they are Paytm, Stripe API, Razorpay. Stripe API is used internationally. I have, uh, worked on both of the models, payment intent and the subscription models for Stripe API. I have integrated open APIs as well. Uh, to name a few, there is a keyword API. I have, uh, I have a good hand in implementing that. Check GPT. Checkgpt 4, uh, as well I have implemented, which is a a paid version. So that is also implemented in one of my project. Apart from that, uh, uh, there are several other APIs. Rossum API, uh, is one of the great API that I've I've worked with. It it is it is all about PDF, uh, reading and, uh, checking what is there in the PDF. Apart from that, that's all about me. In my family, I have one big brother, one elder brother who is a doctor. My mother mother and father, both are teachers, and, uh, they support me in what I do. They, uh, they take care of me. I take care of them, and, uh, I live with my parents. And I really enjoy the, uh, uh, environment, uh, in my society. I as far as Aviso is concerned, I I play tabla. I have learned tabla a little. So in in in classical music, I have also some interest. So this is all about me. Thank you so much.

Yes. Uh, I have, uh, had a chance in a project to, uh, create a react to front end for my Ruby on Rails application for restful practices. We know that for restful, it it is a representational state transfer protocol, which, uh, includes HTTP verbs like get put, post, patch, delete. And, uh, for all these, uh, there is a particular structured routing in Ruby on Rails for, uh, Rails controllers and, uh, routes as well. There are, uh, index, new, create, edit, update, uh, show, uh, delete methods, uh, in the controllers. So, uh, to, uh, use those APIs, uh, uh, from React point of view, uh, first of all, I will install the React. And, uh, whenever, uh, the React app is created, maybe it is already created app or I I create it, uh, with the create React app or command. Uh, then I will, uh, I will use or fetch. Fetch is already integrated there. But if, uh, we want is more famous now because it is used it is being used in Next. Js framework as well. So with the help of, I can, uh, uh, you know, whenever I want to hit the API on a page, whether it is mounting or, uh, at the time of mounting, or I can use, yeah, use effective hooker to, uh, call those APIs as well. So, uh, to whether it is get put post, whatever API it is, I will apply that in a method. The simple way is to apply to the method and, uh, use the try and catch. So whenever there is an error, we can show it as a prompt. And whenever there is a, uh, uh, the the API is being hit, it is upon us if we want to show an alert or a or a flash message, or we just don't want to do anything. We just want to get the data and update the page. So that can also be done. Uh, it can happen, uh, mostly on React, uh, in an Ajax format. So that Ajax will work, uh, just like as similar to the JavaScript that works with Ruby on Rails. So in React, I will use useEffect or Axios or fetch APIs. And the comp and apart from that, to make sure the components are loaded and the APIs are called in a sequential way, so the component structure will be decided according to, uh, how the APIs are being called. Apart from, uh, and after that, I will, uh, do some testing and debugging. For testing the React, uh, or any other JavaScript, there is a, uh, gesture tool that we can use. We can use gesture library to test those application to test those components. Uh, and, also, uh, after the deployment has been done, uh, we can, uh, do some, uh, testing on productions, uh, by opening the network tab if the API are being hit. All the APIs that are defined are being hit or not. So the testing on our local machine and the testing on the production would also be done in that manner. Uh, so that will be, uh, you know, the process of, uh, the React front end, how how it will, uh, use the rails APIs. Thank you.

Yes. The process of integrating a third party JavaScript library with rel six application is quite, uh, simple, but isn't it has multiple factors associated with it. Uh, first of all, uh, there are 2 ways we know, uh, to add any library. Maybe we can use it with the NPM ad or NPM install, or we can use it with the Yarn ad. So let's say I want to install jQuery. I will give the example of jQuery because it is mostly used, and, uh, it doesn't need to be initialized just like, uh, many other JavaScript libraries, while many libraries need need to be initialized. So first, we will add it. Or if, uh, it is a file of, uh, uh, there is a file available of that library, we will just use it in app/asset/javascrip folder. If we are using the file, we will go to into our manifest file called application dot j s. And whatever our manner of installing it is, we will use import or require for that library. So it will be 2 backslashes, uh, and then require, and then I will write that library's name or file's name, or I will just import it in my in my application or JS file. It will depend on how I will I have installed it. After getting installed, I will first, uh, for some libraries, it is essential to initialize them. But, uh, as I'm getting the I'm taking the example of jQuery, it is not necessary to initialize it. So without being initialized, we just, uh, we can just directly start to use it. Some developers still use CDN links in application.html. Erv, but I don't, uh, believe that is good. That is a good manner because, uh, the version changes and some other, uh, things cannot be used, uh, in a good manner in that. The sequence the sequence can be disrupted. Also, after, uh, using any library, not all not only jQuery, any JavaScript library, I will make sure that the web picker because in rail 6, web picker is still there, not, uh, unlike in rail 7. Rail 6, I will make sure that Webpacker, uh, compiles and Webpacker integrates with that particular library very easily. So the set pipeline pipeline is run or may or whatever used, like, webpacker is used. So webpacker is, uh, easy to integrate that, uh, JavaScript library into the application. So that I will make sure. After that, uh, I will check if the versions are compatible with other libraries and, uh, nothing is, uh, breaking on any page for that part, uh, because of the use of that particular JavaScript library. And, uh, after after everything has been checked, I will you know the testing and debugging has been done. For the JavaScript library, the test cases are being returned. And, uh, uh, not only the things, not only the pages, the functions of their JavaScript library are working, but other are also not disrupted. After checking all the things, I will make sure that, uh, within 1 week or 2 week or within 1 month, or it depends on the scale of the application, I monitor, uh, the change log of that app, uh, of that JavaScript library. If a new version will come, I will definitely try to use it, keeping in mind that, uh, it doesn't affect the application, and there are not much, uh, risky changes that has to be done in the application for that. So that I will keep in mind. But, uh, I mean, it will be a good, uh, it will be a good, uh, practice to to check for the change logs of the JavaScript library. Thank you so much.

Yeah. So, uh, to implement any JavaScript callback to handle asynchronous processing in a Ruby on Rails app, uh, what I will do is, uh, you know, uh, JavaScript callback can be uh, used whenever the pages are loaded or whenever any event is triggered. Generally, uh, in rail 7, uh, or maybe in rail 6 as well, if we are using, uh, Turbolinks, I will use the trigger as a dollar document dot on Turbolinks load. Turbo links colon load. Let's say this is the trigger. Uh, that is the event on which I'm call calling a callback. So, uh, asynchronous processes are what? Uh, asynchronous processes are, uh, what, uh, which are, uh, work working behind, uh, the main server or behind the main applications work. So, uh, to, uh, I will, uh, you know, create some AJAX request for this, and AJAX can, uh, check the states. We know there are 7 states on which AJAX works. And, uh, on our proceed JavaScript, uh, can check that there are some asynchronous processors working for the Ruby on Rails app. And they can send the messages or prompts, or they can hit the other APIs or whatever we want to want them, uh, to be done uh, want them to do. So, you know, the JavaScript callback can be, you know, created in such a way that it handle, uh, asynchronous processes for Ruby on Rails app. Uh, as of now, I'm talking about it, so I won't be able to, uh, do much, uh, you know I I can explain it, uh, on the system by while doing the code, but, uh, I mean, the the process is quite clear to me. I can I can do that, definitely? I'm pretty sure of it. Thank you so much.

Yes. So, uh, as we know, MVC architecture, not only for Rails, but for other frameworks like monstack or jang I I'm not sure of Monstech, but for Django as well. Uh, MVC architecture is based on the responsibility splitting. So, uh, MVC architecture is it stands for model, views, and controllers. We know that, uh, model is the object relational mapping integration, uh, called as active record. It, uh, models were models are based on the ORM concepts. So they are there to, uh, to interact with the database for the application. Right? And controllers are there for, uh, for, uh, to handle the, uh, to handle the connection between models and views as well as to handle the request response cycle as well as the authentication and authorizations. And views are just the, uh, user interface. So to split the responsibility, first of all, I will make sure that models only and only contains the database logics and the, uh, business logic of the application. There are 2 logics that work in any application. 1st is the code logic that is, uh, for the, uh, that that is how the application would work. And second is the business logic that on what logic, uh, I mean, what is the core principle of this feature? So these both should be there in the models only. Although, nowadays, uh, for to follow the skinny controllers and skinny models, uh, rule, uh, all the all the business logics and, uh, you know, the code logics, some some developers move business logic to the concerns, and some developers do, uh, move, uh, code logic to the concerns, concern for models. And, uh, same is for controller. Controllers are not there to, uh, you know, interact with the database directly, But, uh, they are there to, uh, initiate the request response cycle and make sure that the request response cycle is secure, and it is fast, and it is smooth. Uh, so all these things should be there. And authentication and authorization, these kind of things should all, uh, also also be handled by rails controllers. So there shouldn't be any business logic or any, uh, you know, much activity code query should not be fired through various controllers. If there is a need to, uh, apply a big logic there, we can use concerns. And, uh, we can u concerns for controllers, and we can include them there so that the code is also clean. And we also know that views are, uh, just the UI interface, so there should not be any complex logic related to, uh, uh, to the to the database of the application or any other logic. So in views, it is a rule of some developers that whatever it is, any which way, uh, you know, any way they I mean, whatever it cost, they want, uh, write, uh, database queries in the release views, which is kind of forbidden. And, uh, for views, we can use helper files for controllers and models they are concerns. But, uh, those responsibilities should be split. Apart from MVC architecture, uh, there is also an extensible an extensive use of, uh, services folder, which is used for creating API wrappers. So it is for integrating third party services into our application. So whenever third party services are integrated our in your in our application, they are generally third party. Our application doesn't, uh, have direct influence with them or shouldn't have directly, uh, directly shouldn't have the directly direct influence by them. So that's why there is a separate services folder in which all those API wrappers and API logic should, uh, be moved. So, uh, that's how I will apply MVC architecture to split responsibility in a Rails application. Thank you so much.

Yes. Data modeling for a multi tenant, uh, Rails application. Yes. So first of all, let's talk about tenancy. There are, uh, 3 actually, there are 3 kind of tenancy levels. 1st is single, uh, database, sing uh, single schema, which is for the small applications in which database and the schema is shared for all of them for all the tables. 2nd is single database for but separate schema. Right? Uh, so at for all the tables, the schema will be separate, but, uh, the database will be single. And the 3rd kind is separate database and separate schema. So these there are three levels of tenancy. The first level or first two levels are generally for the, uh, for the applications which are very small in which the database is so contained, And, uh, there is not much, uh, use, uh, there is not much of use of this different context for different users or different, uh, scopes. In case of, uh, single database in a shared schema sorry. Single database in separate schema, what I will use is I will use a tenant ID in every table so that, uh, through that tenant ID, we can, uh, check what is what is the context and if before every active or transaction, uh, before, uh, any kind of querying or or any kind of usage of that database, any cloud operation that is applied on the database, we can check that that tenant ID. And with that tenant ID, it is clear to us that, okay, this is did belong to a different tenant context, and this belong to different tenant context. But in case of, uh, separate database and separate schemas, uh, we should use apartment gem. So apartment gem is, uh, to switch the tenant context to which can be done easily by, uh, configuring the apartment in our, uh, application. We will just install apartment gem, uh, by writing it in a gem file, and, uh, we'll use a bundle install after that. After it has been installed, we have to, uh, configure apartment from, uh, apartment dot r b. In that, we have to write, uh, tenant names. So there is a lambda that is passed. Uh, I I remember that line because I use it much. And there there is a line, uh, there is a level of, uh, you know, there is a level of past for to initialize the apartment. After appointment is initialized, we can use apartment colon colon tenant dot switch and that tenant ID, uh, which is associated. So apartment will, uh, give us, uh, you know, for apartment, we also have to set up models and associations, particularly. And, uh, apartment can give us a separate wall between all the, uh, schemas and all the databases if if we want. Also, apartment can easily be integrated with, uh, and it can easily work with can can and pandit, these kind of authorization gems. So it is also good for us that these gems also understand how apartment works. Apart from that, uh, you know, in apartment, uh, yes, uh, it it also works in our rails console. Apartment also provides us provides us a a different URL for all the users. In the URL, it will be written as, let's say, 2220 is, uh, is the, uh, apartment is the tenant context for that particular user. So the URL will start from 222 d zero dot, uh, the URL. So this this can also be there. Also, some tables can be, uh, excluded from apartment jam. There is also a procedure for that so that, uh, whether, uh, I mean, they become irrespective of the tenant context, and they can be used universally in the application. So this is, uh, also a good thing with Apartment Gym. So I will, uh, you know, use data modeling. Mostly, uh, for bigger application, I will use Apartment Gym. Otherwise, this is how I will, uh, you know, handle the multitenancy. Thank you so much.

So is execution explained what is this code? Does it know how it could potentially fail to handle? Yes. Uh, so this Ruby code is intended to handle errors during service execution. Okay. We have to handle, uh, the errors. Okay. Let me check it. So here we are what we're, uh, doing is we are executing a service. And if there is a service error, uh, we are printing that error. And for other error, we are, uh, raising the errors. Okay. So we are only raising those errors which are not related to those service error. Yes. So let's say whenever the service is executing and there was a potential threat after the service error was executed, So it is only putting that in the logs, and, uh, it is only printing that a service error occurred, colon, then e dot message. And what happens after that is not, uh, there? So if there is a threat or there is a, you know, standard error or name error or no method error or every even a bigger exception, So that won't be clear that, uh, you know, uh, that that also occurred in this application. Also, unexpected error occurred in that message. Uh, while writing e dot, uh, message, we have used only single code, so double code should be there if this is, uh, a wrong thing. And we are raising an unexpected error, but we have not defined what kind of unexpected error error that can be. Uh, that can be a a small error like standard error or argument error or maybe a big exception which is causing which can causing the whole application to fail. So this is not quite clear here. We have only bifurcated our errors in 2 things. 1st is a survey service model's error, and another is any kind of error. And, uh, potentially, failed to handle certain errors. Yes. Let's say, uh, let's say service, uh, object is not initialized properly, then also the executive method won't be called properly on that. And, uh, if there is an, uh, exception Because, uh, you know, in line in line 5th, we have not defined what kind of exception or what kind of error that can come, and we we are taking it into e, and we are raising that error. So as we are raising that particular error, we don't know, uh, if this was the only error that is this application was giving or as we have raised it, so this would break the chain and, uh, we have to re execute it to know what what is the error again. But let's say there is a smaller smaller error at at the 3rd line, and there is a very big error at the 17th line. So after 3rd line, if that is not a service error, it will, uh, itself erase that error. So we want, uh, you know, at at at at no point of time, we will be, uh, able to check, uh, what is the service, uh, you know, what was the error at the 17th line. So that will, uh, that can, you know, uh, that can cause a lack of knowledge about the code that, okay, this error could have also occurred, and we could have only pushed the fix for the 3rd line. So if we, uh, fix the push for the 3rd line and, uh, let's say we now we know what is the error at the 17th line. And at this 24th line, again, there is an error. So as we are raising all the errors, so we have to do all the error logging step by step for for the errors which are not service error. So that can be a potential threat over here. We should avoid using erase over here, but, uh, it is only for logging that I'm, uh, talking about not using erase. But for, uh, for for a seamless, uh, integration of this service and, uh, for to break the chain whenever there is an unexpected error, So we should definitely use the raise. So the these both, uh, uh, kind of dilemma would be there. Thank you.

Yes. So, uh, before action, as we know, is a filter, uh, which is used in rails controllers. Before action, uh, there are 2 before actions used over here. 1st is before action require admin, which is, uh, only called, uh, before new and create actions. And there is another find user, which is called on all the actions except index new and create. So one thing is clear that for before new and create, only require admin would be called and find user won't be called. Now let's check require admin. What require admin is doing is it is redirecting the user to root path, whatever the root path of the application is, uh, unless the current user is admin. So first of all, in this code, uh, it is and in this question, it is not written. That current user is already defined because there is no before action for that. But now I'm assuming that the device is there or any other before action in the application controller is there, which is defining that current user. And current user dot admin will work, and admin rules are defined. So this is what I'm presuming for that. So require admin, whenever it will uh, redirect me to let's say I'm not admin. We whenever it will redirect to, uh, redirect me to the root path, it is not showing any error or any flash message. Right? So no notice is given. No error is giving is been given, and nothing is happening here. So how can a user know that why I'm being, uh, redirected to the root path, first of all? 2nd of all, find user in find user, we are instantiating a user, uh, a user object, instance variable, and, uh, we are using user dot find. Let's say the Param's ID is nil or, uh, Param's ID is not in the database. So the find method will give us an error over here. So we have to, uh, handle that error, which will be active record, uh, record not found error. So to handle that, we could have all all already used to find by find by ID or find by find by and then in the bracket ID or find by ID, simply. So to prevent these kind of issues, uh, you know, we should be, uh, very astute about, uh, how the methods are being implemented over here because this find will give us an error. And in required admin, there is no, uh, there is no, uh, flash message given. Also, yes. Uh, required admin is only used before new and create. So I'm assuming before creating any new record, we, uh, we we you have to check that I am the admin. Uh, but, uh, not before deleting the record, we are checking, uh, the admin. So it is kind of also weird that before creating any new record, we we are checking that I am admin or not. But I can easily delete the delete the record because it the requirement is not used before that. Also, the find user, I already told. And what if, uh, we used, uh, we we try to know in index new or create? What is the user? So how can we find that? Before new and create okay. We are sorry. In index new and create, we don't have to find what is the what is the URL because no ID will be there. So, uh, any which way, it should not have been used. But if we can change the find user from user.find to user.findmyid, we can also remove that accept because, uh, a direct user won't be used in in these, uh, 3, uh, uh, in the in this reaction. So we can remove that accept line. So this is also a a potential issue, I am I'm thinking. So, uh, otherwise, we can just rescue the error, active record record not found. But, uh, generally, what I feel is, uh, I think that should be handled. The fine method should be handled, and the flash widgets should be there. Thank you so much.

Yes. As we know, uh, Rails is a very good framework, not only for its flexibility for developers, but for securing and, uh, for security of the application and for the scalability and reliable reliability of applications as well. So it follows the, uh, asset properties. It follows the solid principles. I mean, the developer has to follow them. But, uh, it is a good platform in which all of these can be followed. So, uh, the isolation levels, uh, in in atomicity, consistency, isolation isolation and durability, isolation is one thing, which can be, uh, achieved in a very good manner while handling handling the transactions. So, generally, there are 3, uh, 4 kind of 4 kind of, uh, isolated levels, uh, in any application. 1st is read uncommitted, uh, second is read committed, 3rd is repeatable read, and 4th is serializable. So, uh, there are 3, uh, reads issues as well. Uh, first is first is re non repeatable reads, then comes the phantom reads, uh, and then there is a third one. So in a non in a uncommitted in read uncommitted, uh, an isolation an isolated transaction can only see what what the other transaction is is doing. So, uh, in that case, all the 3 kind of reads, dirty reads, non, uh, non repeatable reads, and the phantom reads, all the 3 issues will come. In second kind of, uh, read commit read committed level, uh, 30 reads 1 30 reads should won't be there, but non but non repeatable reads and the phantom reads issue would be there. In 3rd kind of, uh, uh, the in 3rd kind of isolation level, which is a repeatable read, the dirty reads and non repeatable reads issues are removed. But the phantom reads reads, it's still there. Phantom means what? Phantom means whenever a transaction is happening, uh, from a, but b also, uh, changed something from that row. So in the result, a is seeing something else, which, uh, let's say, a is fetching all the 100 record, uh, all the records in which price is more than 100. But b has just created while this was happening, we just created a record which is having prices 101. Now when a is switching so there are more there is one more record, uh, compared to previous results. So that will be a phantom record. So in the in the 3rd case also, uh, uh, there would be a phantom read issue. But in case of serializable, which is the best, uh, best isolated level. Uh, this the phantom read issue, dirty read issue, and non repeatable read issue, all 3 are removed. In that case, what we do is, uh, as we know, uh, Ruby on Rails, uh, by default works on repeatable rates. Sorry. Uh, by by default, Ruby on Rails works on, uh, read committed. Yes. By the the default, uh, level is read committed. So we will, uh, have to make it to serializable. Also, after making it serializable, there is a database locking that can be applied. So database locking, uh, and optimistic locking and pest pessimistic locking, both are there with the with the help of which we can lock the database. And, uh, these are very, uh, these these concepts are very important for e especially for ecommerce app or financial app or, uh, whatever apps on which, uh, there is a transaction. Not only database transaction, but money transaction is also going on. So this is, uh, how I will, uh, you know, maintain asset compliance in a real application. Thank you so much.

Uh, yes. Uh, to create animated transition in a Rails application views, uh, there are many libraries, actually. There is a GreenSock animated platform, GSAPP, which is very famous. Anim. Js is there. Velocity. Js is there. So just like I told, uh, any other JavaScript is integrated, we can integrate them as well. Although, it can also be achieved with Turbolinks, Rails UJAs, and jQuery as well. I would suggest, uh, jQuery, uh, is can beat many of these, uh, libraries in terms of animations because there are many simple simple methods, fading, fade out, toggle, and qdq, stop, delay, uh, things are there. Also, there is a logic that we can apply. We can add and remove class after, uh, some time. After some time, that class can be added after some time. Some milliseconds, that class can be removed. So this logic can also be applied. Apart from that, there are many actions, uh, uh, you know, applied on, uh, in a any j s and velocity to j s as well That can be used. I have used them in my applications. And, uh, to test these things, uh, after they are they have been applied, I will, uh, if we are talking about rail 6, the web pickle will will work, uh, as it's compiled, and then we will test them, uh, according to I mean, along with other JavaScript functions as well. These functions are working or not. That can be tested with, uh, just as well. While checking on production, uh, I will, uh, try to make sure that, uh, the versions are compatible with whatever we have used in our production environment as well for other applications. So this is how I can create any method transitions. Thanks so much.

Yes. To safeguard sensitive data, uh, uh, there is, you know, so in a Ruben risk application. To safeguard sensitive data, uh, we have to start from the very basic. Right? So, uh, we know the device is there, uh, to provide us a good authentication platform. But what after that? So there is a good authentication that has to applied whether it is device or whether it is, uh, uh, any other, like, doorkeeper or any other jam. Or even if we are not using any jam, we should be using JWT methodology or, uh, OmniAuth or OmniAuth 2.0. So these, uh, these concepts should be there in, uh, in our application, whether integrated by any gem or whether integrated by a custom code. After that, a good authorization should be there, uh, which is a handle on a or if there is multi tenancy, that there should be multi tenancy, that should be introduced. If there are multiple roles, all of them should be the there, and all of the actions should go under under the checks of those particular roles of the user. So a good author authorization platform should be there. After that, we should be using HTTPS only, uh, not HTTP. And a good logging of our APIs is there. If if we have deployed their them on AWS, uh, we can use, uh, you know, CloudWatch. We can use, uh, AWS CloudTrail, uh, to log what what is happening or what is, uh, good or what is bad with our application. So these are the things that can be applied. Apart from that, to safeguard our sensitive data, uh, we can, uh, apply token bucket algorithm. Also, uh, we can apply rate attack and rate limiting middleware gems, uh, which can check the if the API is being hit multiple times from one IP address. So these middlewares can be, uh, can can be approached and where there we can, uh, use the help of them in our application. Also, uh, apart from that, uh, to safeguard the sensitive data, uh, we can use session site storage, uh, in our application. So for the unnecessary and, uh, you know, dilute kind of data, we can use client side storage. But for the uh, safeguarding of sensitive datas, we should be using session size storage. Uh, also, uh, we if if AWS Lambda is being used, we can use AWS Lambda as, uh, the open API, uh, gateway endpoints so that they are triggered just after a user has done anything. So there is another kind of security provided by AWS Lambda functions as well because, obviously, AWS is there. And, uh, uh, Yeah. That will be, uh, all from my end. Thank you so much for your time, and thank you so much for this interview. Thanks. Bye.