Sachin Kumar Gupta

So yeah, hi. I'm Sachin Kumar Gupta. I'm a senior software engineer at Technology Private Limited. I've been working in this company for the last six years more than six years. And, my primary stack, which I'm working on is Ruby on Rails and React developer. So, yeah, that's all.

So to refactor a complex view template, what we will have to do is identify the components, the parcels that can be created. So that will be the main thing. So first, you'll have to add tests so that we can make sure that viewed in reels, we can add view tests. If the team follows that convincingly, you can add tests for the view. And then, you will have to identify the parcels which can be created, common components which can be created. And, yeah, based on that, we'll have to refactor. Actually, yes, that's all. Let me think. So yeah, parcels are one way to go, like creating common parcels and making them do specific tasks. Like, it's one way to go. Then you can also use helper functions. So view-related helper functions can be used where the view logic can be placed. That's another way of bringing clarity to the component.

So, yes. So in the React front end when, with the Reels back end, what we have to do is we will have to use if the application is complex and requires global state management, then we'll introduce some globally used state management libraries like Redux. Then we'll use Redux. And along with that, Redux also provides the Redux toolkit. So using that, we can, like, whatever data we consume from the API, we can assure them in the Redux. So yeah. And then you'll have to use a library like Axios for gracefully handling errors and retrying. What else can be done? Let me think. So, if the reels API follows this pattern, okay. Okay. So, we can also have documentation about how the reels API is sending the response. So that will become a key point when designing the React front end for consuming the reels API. So if the Reels API follows a pattern like JSON API, then in the front end, you can write reducers in a way that consuming the data becomes easier. You can have a global seed object where all the data goes, and in your individual Redux, you can only keep the IDs. So in that way also, you can proceed. So, yeah, that's it.

So Rails allows connecting to multiple databases. So that concept can be used for one approach, which is having separate databases altogether. For different tenants, for different phones, different organizations, we can have different databases. From a security point of view, that will be the best. But if we are going with a single database, that will have in terms of complexity, that will be less complex. So that will be the benefit of having a single database. And in that case, what we can do is in one of the applications, what we did is in the URL segment itself, we appended the subdomain part. So let's say if the company name is abc.com and the tenant name is x, then we'll have x.abc.com. And using this x, we can identify the tenant. Using the subdomain, we can identify the tenant, and then whatever calls, whatever API calls which are made. Okay? If any API call is being made from this x.abc.com, then we'll scope all the API calls which we are going to execute up against our database for that tenant. Okay. So by default, that scope will be applied. Okay. So in that way, what will happen is we'll have we can make sure that there's no data or security risks involved.

To optimize, what we can do is, one is from the application side, we can reduce n plus one queries. Okay. The other thing means n plus one queries we'll have to find out using gems like bullet or rake, mini profiler and resolve those things. Then in the back end, we'll have to use an index on the right attributes of the table so that our query time increases is becomes good. Now, the other thing is profiling, knowing which data is causing a problem, which query is taking more time, and finding a better solution for that. So some databases like Postgres provide some features of its own, which can be used to provide some operations that are not provided in other databases. So, database-specific features could be used, if possible, to optimize the query, or some queries are written in not a good way. So, we can optimize here also. So adding an index, reducing n plus one queries, and then optimizing the queries, what else can be done? Yes. The other thing is caching, but caching of frequently and static data that can be done within the application so that we don't reach out to the SQL within the application so that we don't reach out to the SQL server. So caching can be used to improve. And then we can use data sorting also.

I don't understand the question. Like, I don't understand why someone would like to have statefulness in a customer-facing Rails application. A stateless application makes sense. Statefulness, the reason could be, like, you only have one server, and then you would need to persist application state, which we did in one of our applications, but are there very specific reasons for doing this? So, there must be some effective strategy. So, basically, for implementing this, what we'll have to do is we'll have to use some variables to store what is saved. We need to define those variables globally. Maybe, some will have to define the model with some base model or, maybe, in the base controller in the initializer file, or, anyway, we'll have to define those states and then use them.

So, basically, this service code executes the service dot it calls the service dot execute function. And if there is any error of type service colon service error, then it catches that error and displays an error message. If there are errors of some other kind, then this will also catch all the errors. All other errors will be caught. And in the next block, it catches all the errors, shows all these errors, and then raises the same error. Then it raises the error again. So when it's raising the error, it's not passing the error object, just saying raise. So that can create an issue.

So in this code, we are trying to fire you we are trying to make sure that new and create actions can only be called if the user is an admin user. And the index new and create is can whenever a request is made for any action except index new and create will run a code that instantiates the user record. So it instantiates the current user. The problem with this code is that except for new and create means in case of new and create it's not trying to find the user. It's not assigning who the user is which should be called. So current user finding the current users will be done before checking whether the user is the current user or not. Also, we are using current user dot add, whereas we are finding find user at the rate user equals user dot find. So we are doing that. So when we are finding the user findings should be done before, and it should be done for new and create both because new and create depend on whether the user is the current user or not. So if you don't have the user record, we'll not be able to identify whether that's the case or not.

Acid stands for atomic, c for consistency, i for isolation, and d for durability. So atomic says that either the entire operation should complete or the entire operation should roll back. It should happen as a single unit. Consistency says that before the transaction is started, they should see, and after the transaction ends, should be consistent. So, if a transfers 50 rupees to b, he was having 100 rupees and b was having 50 rupees, and he said 50 rupees initially, then the total is 1.50. Then at the end of the transaction, this total amount should be 1.50 only. It should not happen that the money got deducted from a's account and now a has 50 rupees, and b also has 50 rupees, and so the total amount is 100. That should not happen. So that violates it. Isolation means each of the transactions should happen as if there's no other transaction. This should not be aware of any other transaction happening. Okay? This would be completely isolated as if they are happening in an isolated moment, and let's see. If another transaction had occurred, the result of this transaction would not get affected. So, not knowing isolation says that other transactions and the presence of other transactions would not affect or should not it should be isolated. Transactions would be isolated, completely isolated. Durability says that whenever there's a power failure or something, new applications should still be able to function. Okay. So, those things should happen. And that is the thing to maintain compliance. What isolation level do you consider when handling transactions? The application to one is to maintain a safe compliance. So, yeah, that is all.

So Lambda can be used to move certain parts of the application, certain features of the application, to AWS Lambda. We can move those things. Let's say we are building an email tracking feature, and we want to move it. In that case, whenever an SQS event is triggered, either we can trigger an event when an email is sent, and we can send an SMS. After SMS is triggered, the application can receive the event and process it, or it can send it to SQS, and SQS can send it to Lambda. In that way, Lambda can consume it. Okay. So, our server won't be handling those functionalities. Lambda functions as a service. Anything that can be moved to AWS services, including AWS Lambda services, and we want scalability, we should do that. In that way, we'll be able to improve our app's performance. One other thing could be processing a file and generating thumbnails once a file is uploaded. So that can go to the server, but instead, we can go for a direct upload using a pre-signed URL. And then once something is uploaded to a certain S3 bucket, we can add a trigger that a certain Lambda will get executed, and it will process and generate the required thumbnails and pictures.

Real-time communication can be done. So for real-time, we use this WebSocket. In Rails, we already have ActionCable, which provides the same functionality under the hood using WebSocket, but so using WebSocket, we can like achieve this. We'll have to define subscribers, publishers, and channels to which the front end app will have to subscribe, and whenever something is published on that channel, it will receive it, and in the front end, we'll get it. So, yeah, not much change will be required.