Ashrut Panchal

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

Yes, I have had a chance in a project to create a React front end for my Ruby on Rails application for RESTful practices. We know that for RESTful, it is a representational state transfer protocol, which includes HTTP verbs like get, put, post, patch, delete. And for all these, there is a particular structured routing in Ruby on Rails for Rails controllers and routes as well. There are index, new, create, edit, update, show, and delete methods in the controllers. So to use those APIs from a React point of view, first of all, I will install React. And whenever the React app is created, maybe it is already created, or I create it with create React app or command. Then I will use fetch. Fetch is already integrated there. But if we want something more famous now because it is used in Next.js framework as well. So with the help of, I can use whatever I want to hit the API on a page, whether it is mounting or at the time of mounting, or I can use an effective hook to call those APIs as well. So 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 use try and catch. So whenever there is an error, we can show it as a prompt. And whenever there is an API being hit, it is up to us if we want to show an alert 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. It can happen mostly on React in an AJAX format. So that AJAX will work just like JavaScript that works with Ruby on Rails. So in React, I will use useEffect or Axios or fetch APIs. And the component 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 how the APIs are being called. Apart from that, I will do some testing and debugging. For testing React or any other JavaScript, there is Jest tool that we can use. We can use Jest library to test those applications to test those components. And also, after the deployment has been done, we can do some testing on production by opening the network tab if the APIs 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. So that will be the process of the React front end, how it will use the Rails APIs. Thank you.

Yes. The process of integrating a third-party JavaScript library with a Rails 6 application is quite simple, but it has multiple factors associated with it. First of all, there are two ways we know to add any library. We can use it with npm or yarn. So let's say I want to install jQuery. I will give the example of jQuery because it is mostly used, and it doesn't need to be initialized just like many other JavaScript libraries, while many libraries need to be initialized. So first, we will add it. If it is a file available for that library, we will just use it in the app/assets/javascript folder. If we are using the file, we will go into our manifest file called application.js. And whatever our manner of installing it is, we will use import or require for that library. So it will be two backslashes, and then require, and then I will write that library's name or file's name, or I will just import it in my application.js file. It will depend on how I have installed it. After getting installed, I will first initialize them if it is essential. But, as I'm taking the example of jQuery, it is not necessary to initialize it. So without being initialized, we just directly start to use it. Some developers still use CDN links in application.html, but I don't believe that is good. That is not a good manner because the version changes and some other things cannot be used in a good manner in that. The sequence can be disrupted. Also, after using any library, not all, not only jQuery, any JavaScript library, I will make sure that the Webpacker compiles and Webpacker integrates with that particular library very easily. So the Webpacker pipeline is run, and it is easy to integrate that JavaScript library into the application. So I will make sure. After that, I will check if the versions are compatible with other libraries and nothing is breaking on any page for that part because of the use of that particular JavaScript library. And after everything has been checked, I will do the testing and debugging. For the JavaScript library, the test cases are being returned. And 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 within one week or two weeks or within one month, or it depends on the scale of the application, I monitor the change log of that app. If a new version will come, I will definitely try to use it, keeping in mind that it doesn't affect the application, and there are not many risky changes that have to be done in the application for that. So that I will keep in mind. But I mean, it will be a good practice to check for the change logs of the JavaScript library. Thank you so much.

Yeah. So, to implement any JavaScript callback to handle asynchronous processing in a Ruby on Rails app, what I will do is, JavaScript callbacks can be used whenever the pages are loaded or whenever any event is triggered. Generally, in Rails 7, or maybe in Rails 6 as well, if we are using 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. That is the event on which I'm calling a callback. So, asynchronous processes are those which are working behind the main server or behind the main application's work. To handle this, I will create some AJAX requests, and AJAX can check the states. We know there are seven states on which AJAX works. And on our proceed JavaScript, it can check that there are some asynchronous processors working for the Ruby on Rails app. And they can send messages or prompts, or they can hit other APIs or whatever we want them to do. So, the JavaScript callback can be created in such a way that it handles asynchronous processes for Ruby on Rails app. As of now, I'm talking about it, so I won't be able to do much, but I can explain it on the system while doing the code, and the process is quite clear to me. I can definitely do that. I'm pretty sure of it. Thank you so much.

Yes. So, as we know, MVC architecture, not only for Rails, but for other frameworks like Monstack or Jang, I'm not sure of Monstech, but for Django as well. MVC architecture is based on the responsibility splitting. So, MVC architecture stands for model, views, and controllers. We know that, models are the object relational mapping integration, called as active record. Models are based on the ORM concepts. So, they are there to interact with the database for the application. Right? And controllers are there to handle the connection between models and views as well as to handle the request response cycle and authentication and authorizations. And views are just the user interface. So, to split the responsibility, first of all, I will make sure that models only contain the database logic and the business logic of the application. There are two logics that work in any application. The first is the code logic, which is how the application would work. And the second is the business logic, which is the core principle of this feature. So, these both should be there in the models only. Although, nowadays, to follow the skinny controllers and skinny models rule, all the business logics and code logics are moved to the concerns, and some developers move business logic to the concerns and some developers move code logic to the concerns for models. And the same is for controllers. Controllers are not there to interact with the database directly. But, they are there to initiate the request response cycle and make sure that the request response cycle is secure, and it is fast, and it is smooth. So, all these things should be there. And authentication and authorization, these kinds of things should also be handled by Rails controllers. So, there shouldn't be any business logic or any much activity code query fired through various controllers. If there is a need to apply a big logic there, we can use concerns. And we can use concerns for controllers, and we can include them there so that the code is also clean. And we also know that views are just the UI interface, so there should not be any complex logic related to the database of the application or any other logic. In views, it is a rule of some developers that whatever it is, any way they want to write database queries in the views, which is kind of forbidden. And for views, we can use helper files for controllers and models, which are concerns. But, those responsibilities should be split. Apart from MVC architecture, there is also an extensive use of a 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 into our application, they are generally third-party services. Our application doesn't have direct influence with them or shouldn't have direct influence by them. So, that's why there is a separate services folder in which all those API wrappers and API logic should be moved. So, 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 Rails application. So first of all, let's talk about tenancy. There are actually three kinds of tenancy levels. 1st is single database, single schema, which is for the small applications in which the database and schema are shared for all tables. 2nd is single database but separate schema. Right? So for all the tables, the schema will be separate, but the database will be single. And the 3rd kind is separate database and separate schema. So these are three levels of tenancy. The first two levels are generally for the applications which are very small, in which the database is so contained, and there is not much use of this different context for different users or different scopes. In case of single database in a shared schema, I will use a tenant ID in every table so that through that tenant ID, we can check what is the context and if before every action or transaction, before any kind of querying or any kind of usage of that database, any cloud operation that is applied on the database, we can check that tenant ID. And with that tenant ID, it is clear to us that this belongs to a different tenant context, and this belongs to a different tenant context. But in case of separate database and separate schemas, we should use the Apartment gem. So Apartment gem is to switch the tenant context, which can be done easily by configuring the Apartment in our application. We will just install the Apartment gem by writing it in a Gemfile, and we'll use a bundle install after that. After it has been installed, we have to configure Apartment from apartment.rb. In that, we have to write tenant names. So there is a lambda that is passed. I remember that line because I use it much. And there is a line to initialize the Apartment. After Apartment is initialized, we can use Apartment::Tenant.switch and that tenant ID, which is associated. So Apartment will give us, for Apartment, we also have to set up models and associations, particularly. And Apartment can give us a separate wall between all the schemas and all the databases if we want. Also, Apartment can easily be integrated with cancan and pundit, these kinds of authorization gems. So it is also good for us that these gems also understand how Apartment works. Apart from that, in Apartment, it also works in our Rails console. Apartment also provides us a different URL for all the users. In the URL, it will be written as, let's say, 2220 is the apartment is the tenant context for that particular user. So the URL will start from 2220 dot, the URL. So this can also be there. Also, some tables can be excluded from the Apartment gem. There is also a procedure for that so that they become irrespective of the tenant context, and they can be used universally in the application. So this is also a good thing with Apartment gem. So I will use data modeling. Mostly for bigger applications, I will use Apartment gem. Otherwise, this is how I will 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. So, this Ruby code is intended to handle errors during service execution. Yes. We have to handle the errors. Let me check it. So here we are what we're doing is we are executing a service. And if there is a service error, we are printing that error. And for other errors, we are raising the errors. So we are only raising those errors which are not related to service errors. 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 it is only printing that a service error occurred: then e.message. And what happens after that is not there? So if there is a threat or there is a standard error or name error or no method error or every even a bigger exception, so that won't be clear that you know that also occurred in this application. Also, an unexpected error occurred in that message. While writing e.message, we have used only one code, so double code should be there if this is a wrong thing. And we are raising an unexpected error, but we have not defined what kind of unexpected error that can be. That can be 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 into two things. The first is a service model's error, and another is any kind of error. And potentially, failed to handle certain errors. Yes. Let's say, let's say service object is not initialized properly, then also the execute method won't be called properly on that. And if there is an exception because you know in line five, we have not defined what kind of exception or what kind of error that can come, and we are taking it into e, and we are raising that error. So as we are raising that particular error, we don't know if this was the only error that this application was giving or as we have raised it, so this would break the chain and we have to re-execute it to know what is the error again. But let's say there is a smaller error at the third line, and there is a very big error at the seventeenth line. So after the third line, if that is not a service error, it will itself raise that error. So we want you know at no point of time, we will be able to check what is the service you know what was the error at the seventeenth line. So that will 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 third line. So if we fix the push for the third line and let's say we now we know what is the error at the seventeenth line. And at this twenty-fourth 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 the errors which are not service errors. So that can be a potential threat over here. We should avoid using raise over here, but it is only for logging that I'm talking about not using raise. But for a seamless integration of this service and for to break the chain whenever there is an unexpected error, so we should definitely use the raise. So the these both kind of dilemma would be there.

Yes. So, before action, as we know, is a filter, which is used in rails controllers. Before action, there are 2 before actions used over here. 1st is before action require admin, which is only called 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, unless the current user is admin. First of all, in this code, 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 redirect me to let's say I'm not admin, it will redirect to the root path, it is not showing any error or any flash message. So how can a user know that why I'm being redirected to the root path, first of all? 2nd of all, find user in find user, we are instantiating a user, a user object, instance variable, and we are using user dot find. Let's say the Param's ID is nil or Param's ID is not in the database. So the find method will give us an error over here. So we have to handle that error, which will be active record not found error. So to handle that, we could rescue the error or use find_by or find_by_id. And in required admin, there is no flash message given. Also, yes. Required admin is only used before new and create. So I'm assuming before creating any new record, we have to check that I am the admin. But, not before deleting the record, we are checking the admin. So it is kind of also weird that before creating any new record, we are checking that I am admin or not. But I can easily delete the record because the requirement is not used before that. Also, the find user, I already told. What if we used find user from user.find to user.find_by_id, we can also remove that accept because a direct user won't be used in these actions. So we can remove that accept line. So this is also a potential issue, I am thinking. So, otherwise, we can just rescue the error, active record not found. But, generally, what I feel is, the fine method should be handled, and the flash messages should be there. Thank you so much.

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

Yes, to create animated transitions in a Rails application views, there are many libraries, actually. There is the GreenSock animated platform, GSAPP, which is very famous. Anim.js is there. Velocity.js is there. So, just like I told you, any other JavaScript library can be integrated, and we can integrate them as well. Although, it can also be achieved with Turbolinks, Rails UJAs, and jQuery as well. I would suggest using jQuery because it can beat many of these libraries in terms of animations. There are many simple methods, such as fading, fade out, toggle, and others, like stop, delay, that are there. Also, there is a logic that we can apply. We can add and remove a class after some time. After some time, that class can be added, and after some milliseconds, that class can be removed. This logic can also be applied. Apart from that, there are many actions that can be applied on jQuery and Velocity.js as well. I have used them in my applications. And to test these things, after they have been applied, we will test them, along with other JavaScript functions as well. These functions are working or not, and they can be tested just as well. While checking on production, I will try to make sure that 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 animated transitions.

Yes, to safeguard sensitive data, there is, you know, so in a Ruben risk application. To safeguard sensitive data, we have to start from the very basic. Right? So, we know the device is there, to provide us a good authentication platform. But what after that? So, there is a good authentication that has to be applied, whether it is a device or whether it is any other, like, doorkeeper or any other system. Or even if we are not using any system, we should be using JWT methodology or OmniAuth or OmniAuth 2.0. So these concepts should be there in our application, whether integrated by any gem or whether integrated by a custom code. After that, a good authorization should be there, which is a handle on access or if there is multi tenancy, that should be introduced. If there are multiple roles, all of them should be there, and all of the actions should go under the checks of those particular roles of the user. So a good authorization platform should be there. After that, we should be using HTTPS only, not HTTP. And a good logging of our APIs should be there. If we have deployed them on AWS, we can use CloudWatch. We can use AWS CloudTrail to log what is happening or what is 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, we can apply the token bucket algorithm. Also, we can apply rate attack and rate limiting middleware gems, which can check if the API is being hit multiple times from one IP address. So these middlewares can be approached and used in our application. Also, apart from that, to safeguard the sensitive data, we can use session site storage in our application. So for the unnecessary and dilute kind of data, we can use client side storage. But for the safeguarding of sensitive data, we should be using session site storage. If AWS Lambda is being used, we can use AWS Lambda as open API 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, that will be all from my end. Thank you so much for your time, and thank you so much for this interview. Thanks. Bye.