Navin Kumar Micheal Jayraj

Yeah. Hi, team. So myself, Devin Michael, completed Beacon Electronics and Telecommunication branch, and I joined WNS Global Services as my first company, wherein I worked as a software test analyst in that company for 2 years. So after that, I joined Q Telstra Software Private Limited, wherein I worked as a PHP developer. So from there, within that organization, I was promoted to different positions like senior PHP developer and as well as leading a team of 2 to 3 people. So during my tenure in that company, I was working as a senior PHP developer and handling all the API connections made between different applications. So I used different frameworks like Laravel, CodeIgniter, and Netter. This is basically a domain, which is a travel domain, wherein we post online reservations for flights, hotels, tools, sightseeing, and different services. So in that team, I was working as a senior developer in connecting the 3rd party APIs, integrating different APIs, and fetching the information and displaying it in our projects. So, in my tenure, we were part of different teams where we supported in-house clients and also the clients from abroad, basically from Gulf countries, Dubai, Abu Dhabi, and different countries. These clients gave us projects to work on. Like, they gave us a project like online travel reservation management system. So we integrated different third-party applications, like payment gateways, and handled all the bookings, reservations, and cancellations and reconciliations. I worked in that company for 5 years. So yeah. So I had overall 6 years of experience. After that, I joined Rakan Bureau Justice Private Limited. That's basically a shopping cart application, which is fully based on coding net or framework. So I worked as a senior PHP developer, integrating the payment gateways and integrating the third-party resources within the applications, getting data transformations, and presenting that product in the web application so that the user could book those products from there. Those are basically online juice marketing companies wherein your user can buy health drinks and many health products from that applications. So currently, I'm working in a loyalty rewards program. So I have integrating third-party integrations, like Workday, SAP, and many other major applications, and working on huge data. Yeah. So that's all about my background. Thanks.

Yeah. So SQL injection is a very critical thing in web application and it has caused a major impact in accessing the data of an user, like admin especially. So preventing SQL injections, there are various steps taken from the form itself in the JavaScript query itself, validating all the HTML scripts, whatever is getting added in the required fields. And also, on the server side, like, there are different ways of escaping those input fields and validating the data from the server side as well as the client side. And yeah. So overall, for preventing SQL injections, we have validated the data from the client side as well as the server side. And while inserting the database as well, so all the data which is going to be inserted or getting selected will be thoroughly checked from a script point of view and validated before being used in any purposes, like displaying it to top applications or sending it to a third party. So handling the data has been a critical part of our projects, and we have done that throughout my career in web application development. Yep.

So finding that internal server error is basically a syntactical error in any of the applications. So far, for resolving those kinds of syntax applications, we prefer looking into that error reporting mechanism, PHP. So that actually displays all the errors in the UI itself, and we can use that. It displays the line number and all the information required for the same. We actually look into that and accordingly switch that file and look for that error in that particular line number.

It's back then. You're working on recording division of user-facing elements. That will have to die. How old are you, please? Yes. So integrating the front-end, UI developed by the front-end developers is not a great deal. So that's what happens using a different template file, like Blade or Smarty, and encoding it. We also use a different file, an HTML file. Those files are used by the UI developers to integrate it, so we apply the required data to those files and process the data received from the UI developers. We verify that data and integrate it in our big back-end application by sending the correct data in the fields they have applied for us. As a PHP developer, we're fully focused on the data that's getting displayed over there. So we work on providing the data in a curated and to-the-point manner. If you provide more data than required, it will print in the whole area and pass it to the data field, which will not give a better performance. We restrict the data that is required in a particular format, like a JSON string or any lightweight text format file. We pass that data to the UI template files accordingly, to get better performance out of that. Thank you.

Push three. Sorry, I haven't worked on post creation. But, yes, we worked on data migrations and how we can generate a script from the PHP backend for in case we implement a new project and the client wants to have that new project with the required data. So we worked on migration scripts and everything.

For the lateral methods, like, we basically use factory design pattern wherein, we generate different objects and, use that in the required workflow.

We're designed to create a full API as one point out any issues with this function and how it might violate these solid principles. Yep. So this is a create API response which checks up the data parameter and the status parameter. And, header set to content tab application JSON. Response code status echo JSON encode and data. Yeah. So, basically, while, then creating the API response, the API will be of a particular format. And, it cannot echo directly the JSON code data, which will print the direct, which will print that in the, web application itself instead of manipulating that data and using it in the required, format. So this so we cannot, directly echo the data which is received from the API response before validating if it is a correct response or not. If there is any error received, then we cannot, print that directly in the response. This will, stop the users from execution is executing other, if there is any other functionalities that, depends on this API. And if the API is failed, then all other, code functionality will stop because we have an exit after the echo statement.

Yeah. So this query is susceptible to SQL injection by, like, email can be equal to 1 or anybody who calls this function gets a user by email. If they pass a different value, they can have access to that entire database, and they can even print that in the web application page itself, which will be a big major issue. Like, here we need to use a prepared statement for handling such kind of queries. Prepared statements are like escaping the email variable that is getting switched from the get user by email function parameter.

Complex migration, we won't be using Laravel to transform a single table and then design the table in a tense design. In Laravel, we do have a different transform technique for inheriting the designs.

So for aggregating the data from multiple resources, Laravel, we make it more robust for in case of particular failures by continuing to execute the remaining set of code. We create certain functions and make it more object-oriented so that if a particular function has some failures from a particular resource, we are driven while aggregating the data. During that case, we ensure that we handle those errors separately for each resource we are working on. Based on the errors, we can collaborate and add it to the log, which the user investigating those kind of failures can easily have access to.

Best practices for using REST API in error handling is everything, like API call and connecting to third parties and validating the username and password. All the credentials should be enclosed in their try-catch format so that if there is any exception that can be caught and logged in the error logs, so it can be easily accessible and reused in case of debugging purpose. For risk-full APIs, we always depend on the third party's server responses, how it's written, how long it takes to complete the successful query. It all depends upon the connection and readability. So we have to maintain it in such a way that we should have ample time for connecting to a particular application and switching the record out of it. And for consistency, we always have multiple calls. If there is any failure for a particular set of time, we have to have a separate logic implemented in our application such that if there is any error happening and which is a familiar error, which used to happen from the third party side. So we have to have a set of retriggering logic wherein it triggers after one or two hours automatically so that the data that's supposed to be fixed for that particular day on that API should not be left out and it covers almost all the records.

Want to start in a legacy PHP system? The consideration would be to ensure backward compatibility. So while refracting any PHP system, like, we are removing any particular application from the normal core PHP background to any framework or something. So we first need to make sure the existing finds, functionality that is working doesn't get hampered, and it will have the exact functionality that the whole system used to do and with the least amount of code, using more and more functions or enterprise applications and following all the OOPs concepts and principles and the different techniques to reduce the logic to such a way that the user can be more readable. Like, whoever comes up as a new developer will be able to read it and understand quickly and perform the successful workaround with that, similar tasks.