Akhilesh Singh

Hello. I am. I have 15 years of experience in web-related and web development. I started this journey in 2009 with basic PHP and related technologies like MySQL. Later on, I brought myself into WordPress development, and I worked on supplying WordPress projects, including Ucommerce Integration, prod ecommerce development, and downstream. I also work with other CMSs like Joomla, Drupal, OpenCart, and Magento 1. Along with that, I also have experience with Laravel development, where I have a good hand in Laravel Development, with key concepts of programming, like object-oriented systems, object-oriented programming, and interface design patterns, repository design patterns, and singleton pattern. So I have these aspects already in hand. And if we talk about Magento, then I have approximately 8 to 10 years of experience in Magento 2 since Magento 2 was launched. I am familiar with several Magento ecommerce installation setups, creating new modules. I also did open-source work. I also submitted my PRs to the Magento community. Also, my PRs got approved for different functionalities. I have worked with different types of clients in Magento, like small, starting, mid-end, and big-level ecommerce already running. I have managed several clients in Type 2 main. I have experience in Magento upgradation management, from touch to creating new functionality, creating new modules or extensions, installing existing extensions, and extending the default functionality of Magento. I also have hands-on experience with headless Magento Commerce and PWA provided by Magento 2, which is on React. So I also work with that, and I have hands-on experience in designing Magento commerce for the front end. Though I found myself not very strong in the front end, but I know how to do that.

To test Magento front end JavaScript libraries as we all know that Magento front end JavaScript best practices mostly require the use of required JS techniques and the Ku opportunities, like the Ku libraries for their model view controllers for the front end functionalities. So to update or create new functionality in the JavaScript with minimal user impact, I would try to do this with several setups, which compile JavaScript into the front end. And after compiling, I will try to achieve zero downtime deployment, in which my compiled JS is automatically replaced by the new compiled JS. So in that way, there is minimal or no user impact because as soon as a user refreshes the page, the new JavaScript will be loaded, and they can experience our changes. And to attach our new functionality into the JavaScript, as I mentioned that we can use the required JS tool through which we can attach our newly created library to existing Magento front end designs. To create the new user experience, I would go with tier libraries, which are used by default, through which they are using model view controller, and it also gets data through either Magento graphical API or we have natively available data. So in this way, I will update and create new JavaScript libraries. To test it, I will use Cypress libraries to check the JavaScript front end working, our user interface, and how it's responding.

To manage JavaScript challenges into, because it's a pretty good challenge. I have faced just a little time. So, first of all, as we know that the modern JavaScript is not 100% label compatible with all the browsers. So, it labels differently with different browsers and versions. That's why we use a fallback method, and we try to use those modern JavaScript methods with the older ones. And that's why I would mention a fallback method to use. In Magento, this fallback method is already included. If we talk about the jQuery system, there is a jQuery migration. The migration script is already involved in the Magento team. So, in this way, we can handle the legacy JavaScript browser support because it's been impossible to use several new functionalities that are labeled in newer browsers, and tools are not available in older browsers. So, we can use the fallback metadata I mentioned earlier. And for that, we use a library. With the help of the library, we can handle those outdated browsers' functionality too.

What is the issue. To resolve the conflict, first, I will try to break down where the conflict is happening and why it's happening. Most of the time, the Java jQuery is the culprit. However, if there are others, then first, I have to check where the conflict is happening and why it's affecting the JavaScript functionality. Sometimes, it happens that on a particular day, two different modules are working so that data could be modified by any of them, and that could cause an error. To solve that problem, first, I would try to disable the extension if it's not required, if that functionality could be managed by other extensions. And if that's not possible, then I will try to extend one of the plugins and write the code myself, and then inject it into the system through the required JavaScript. And when I update the code, I will keep in mind the conflict that was happening with the extension. So with the help of that, I can create an extra extension, which will override one of the extensions, which is conflicting. So in that way, I can avoid the conflict, and I can set proper triggers and proper events, where the data could be updated if that's the conflict. If the conflict is like a view operation, or a user UI conflict is happening in a user UI experience, then again, I would go with the same approach, and I will create an override for one of the extensions, and I will try to avoid the conflicts.

To integrate the third-party graphical API securely in Magento, I will create an extension that is wholly responsible for this connection, which is my first step for security. The second step is to determine what kind of API I am using and what the frequency is for hitting it. In this way, I will connect my extension to the third-party GraphQL. For secure connections, it will mostly work via the backend. There is no frontend network involved, only our open API. It will connect with the third-party API server securely. I must show that the third-party providers provide us with login credentials or an API token. I will use these credentials securely, storing them in the database with Magento's inbuilt hashing. This way, the keys will be saved and hashed, so no one can access them. To access the data, I will use Magento's HTTP library. This is the most secure method available in Magento through which I will hit the third-party API and get the required data to perform the operation. In this way, I will create a secure connection with the third-party GraphQL connected to our Magento 2 store.

For giving further debugging process of the checkout, giving is a quite complicated task, and I faced it several times in my work. So first of all, I would try to locate the bottleneck where this checkout fails and why. So my debugging evolves over two steps. First is the JavaScript functionalities, and second is the BSP functionalities because most of the time I found that the checkout fails due to JavaScript functionality as Magento 2 uses heavily JavaScript with the knockout libraries on the checkout piece, and it uses several events, several data points to manipulate the data, communicate to the server, and vice versa. So there is a probability that using some extent and conflict could happen and Magento could fail to successfully fail to check out. So my first step is to debug the JavaScript, the front-end JavaScript. And to use the front-end JavaScript debugging, I used the Chrome inspect tool. And through that, I can access that particular library for that particular event for the data they hold, how the data is processing. Because as I mentioned that they are knockout model-view-controller methods. So in the knockout model, there are data and we can see how they are managing. So this is my first step. The second step is if the knockout JS and front-end JavaScript library submit data correctly, then certainly the error resides in the PHP section of the back end. So at that time, I would check the back-end part of the BSP because during the checkout, several API connections happen at the time of checkout, because Magento frequently connects to the back end, submits the data, and gets the output, and validates it and gets the output. So I will check the PSP part of the checkout function if they are creating conflicts. So in these two methods, I will locate the problem and solve it.

Oh, using "important" in CSS code is always prohibited. Everyone suggests that. So, I would find out that using "important" is itself problematic. Regarding the maintainability of this code, we can see that this is changing the background color and the text color of the primary buttons throughout the system. So the problem is that the "button primary" CSS class is very key, so it's used almost everywhere, almost every button. So with this code, we are changing every button's attributes, setting the background color and the color. This is the problem of maintainability because there are several kinds of buttons used in the Magento theme. So we need to change if any particular button or any style. This could make our life very tough. So to solve that, I would try to use the reason why "important" is required. If there's something happening or we need the primary buttons to be color updated, then we can define it in team CSS, which is the team's default file from where we can update the theme, update the button primary. Or if we want any particular button to be updated, then I would add a page class and that div class before that so that it could update that particular button only, not the other ones. And in that way, it maintains the maintainability because that is one base code, where every override code exists on a page like team.css, and from there, everybody can change. So it will solve our maintainability issues.

Oh, but using double equals to sign age, most of the time, it's worked, but here, as we are checking it with the validation, sometimes the space character could get through with the validation, and it provides its result into true. So to solve this problem, the empty is the method in JavaScript and in Magento also. In Magento, there are several validations of label and through which there are methods, like, as I mentioned, the easy method. So with the use of those methods, we can easily and more comfortably say more comfortable. Hello. Not comfortable. I think a more good way, I guess. I'm sorry. A more good way to use those methods because those methods are already tested, and they are very reliable. So those methods are very reliable. So I would use the asymmetric method to solve this problem.

To architect a Magento system that could be reverted back, I would use a continuous deployment tool where our system is deployed to the live server, runs the compile command, like the command compiles the front end, deploys the front end, and all the necessary commands. After that, the directory is connected to the current directory, which is linked to the domain. This is where we'll call zero-downtime deployment, where there is no downtime. There is no downtime because it's just similar to creating a new version. Earlier, Simulink was connected to the older Magento systems. The older Magento installation, with an older version of Magento or an older version of a plug-in, was working, and that was fine. If we want to upgrade it, we upgrade it on our system and push it to the repository system. Then the repository system's continuous deployment will copy the code to the new directory on the server and run the necessary codes, as I mentioned earlier. After that, once the process is over, it simply deletes the older symlinks and creates a new symlink. In this way, Magento's domain responds, and the new domain is connected simultaneously. So, there is no downtime. And if something goes wrong, it automatically deletes the new folder and connects to the old folder with the symlink. So, there is no downtime. And if anything goes wrong, it automatically goes to the previous stable state of the Magento system, which was working fine before the upgrade.

Live Magento stores, I generally prefer the New Relic, which is already given in the Magento system. So if a client allows further payment, I go with the New Relic system because it provides very important data to monitor the performance of the Magento and the bottlenecks of the Magento. And I also use the server-side tools like log slow query, where I log the slow query MySQL queries if there are any. Similarly, I log the slow PHP operations. If there are any slow PHP operations that go beyond my threshold, which I have defined, it logs that code block so I can go and check it later. Apart from that, I also use Google Pagespeed and GTmetrix tools for front-end optimization to see what they are suggesting to improve our performance on the user's side, how the user is facing the problem, and what are the problems and how to fix them. So these are the tools I generally use for performance management. I also use the Google Chrome's Lighthouse tool, which allows me to check performance issues in different terms, and GT metrics provide a detailed view. So, combining light speed, Lighthouse, and GT metrics, I go for performance upgrades accordingly.

To approach the proactive monitoring, there is a tool already provided, which scans the website every week, one day a week, to monitor the performance of the website. So I use that tool, which thoroughly examines our website and find out if there are any issues at least till now. And apart from that, I also use OSWP suggestions because there are OSWP suggestions, like blocking bots and blocking bots and DDS, which prevent DDS attacks, etc. Apart from that, I also try to update Magento as soon as their security patches are released. So in this way, I can secure the Magento store.