PEUSH JAISWAL

Piyush Jaiswal. I have around 12 years of experience, with the past seven years focused on Node.js, React.js, TypeScript, and microservices. For the past seven years, I've been working in these areas. In my current role at Aptos India, I led the fiscalization lane. Fiscalization is a feature that enables the launch of a product in different countries, which requires adherence to specific rules and regulations as requested by each country. Aptos is a retail domain product organization, and in retail, sales transactions and return transactions need to be submitted to tax authorities for tax verification. I've completed integrations for Peru, Colombia, Costa Rica, Italy, Germany, Poland, and Portugal, and I've also worked on Japan fiscalization. Prior to Aptos, I worked at Sensor, where I was a client of HS blocks, and before that, I was with INVShare. Before joining Sensor, I was part of Rise and Shine Print Tech, where I worked on an e-commerce website for print management systems. My initial five years were focused on.NET, and my experience with Node.js began during my time at Sensor, where I worked on Node.js for HS blocks, marking the start of my journey with Node.js and React.js.

What criteria would you use to decide between deploying a Node.js application on a serverless platform versus a containerized platform like Kubernetes? I'm really not sure what criteria it needs to be on. I have only worked on AWS, and when I say AWS, we have worked on AWS Lambda, whereas AWS also supports EC2 and Fargate. But since we have worked on mostly on the microservices and based basically on the serverless module, the way we have decided to go with it is because it charges based on the computation. So again, the computation cost and the flexibility and the number of services which AWS provides. I mean, having said that, S3, Firehose, EventBridge, SNS, SQS. I mean, there are more than 200 services which AWS provides. I mean, depending on the performance and the availability of the number of services which AWS provide, I would say that because I'm not sure about the Azure and GCP. I have worked on only AWS, so that looks pretty good to me as of now.

The process of setting up a CI-CD pipeline for a cloud-based Node.js application is quite straightforward. I'm not sure I understand the question, because if you're looking for CI, how do we set up a CI-CD pipeline? I mean, there are certain steps we have to follow within Jenkins, but what we have to follow is checking out the code, building it, and then running the unit test. And once the build passes, the unit test passes, and then it publishes. Before publishing, there are certain steps you have to follow. To clarify, we did this one-time setup in Jenkins.

How would you handle branches strategy in Git for parallel feature development and hot fixes? Okay, so parallel feature development, I'm aware of hot fixes, but parallel feature development the way we have worked on, we had one master branch and every code that gets pushed into a specific branch based on the Jira ticket number, it gets reviewed, it gets approved, and it gets merged to the master. Now, once we have a release, we basically tag with the release version, and I mean, there's a certain branch again, that particular release version is branched out. Once there are hot fixes, so again, these branches are based on the release version, which gets released to the customer. If there are certain changes, let's say, if there are bugs in the code, it needs to be fixed; we check out that branch and we fix the code in that particular one, not on the master branch, it gets fixed in the feature branch or the release branch.

How would you introduce a new technology or library in the team and Node.js tech stack without disrupting the current workflow? New technology or new library generally gets introduced with the new feature. But if I have to work on an existing feature, I'll create a separate version. So let's talk about a microservice. That means we have, for example, four endpoints, and I want to introduce something new. So there are four routes: get, post, patch, and delete. These are the four endpoints for a particular microservice. And let's say if I want to make some changes in a particular endpoint or introduce a new technology or a new library, what I would do is create a new version for that particular endpoint. So I'll start with the get endpoint, I'll try to introduce the new library. Depending on what the library does, I will have like two versions of the endpoint: v1 and v2. And with that v1 and v2, v1 will remain on the existing code, and with the new v2 version, we can experiment. But again, I wouldn't do that on the live code. I will try to do a proof of concept to check the flexibility, the feasibility, and the performance of the new library. It's very hard to introduce a new library in the existing code, which is working just fine. We need to do a proof of concept, and once the proof of concept is successful, then only we can have a new library introduced within that particular part of the application.

High-performance background jobs in a Node.js application. High-performing background jobs in a Node.js application. Basically, there are two ways. You can have a cluster. Clusters can be set up at the infrastructure level, or you can have the cluster set up at the code level as well. You can have a child process in place, and you can have a worker thread in place. It depends on the requirement, what exactly we are trying to achieve with background jobs. If we are talking about just input-output jobs where I have to constantly update the main thread about progress, then I would go with the worker thread. If I'm talking about a child process, again, a child process has a master and slave, where the master keeps track. I mean, these two processes are running entirely differently, but the master knows if a child has crashed, and so it can restart it. But again, it depends on what we are trying to achieve by creating this child process. If it is just a task of having a background job, it can be achieved through the worker thread.

What solid is being violated and how much do you refactor it to adhere to the principle? Given this TypeScript code sample, what solid principle is being violated? How much, how might you refactor it to adhere to the principle? Single responsibility, open, close. And then we have interface segregation. This is violating interface segregation, why it has to extend rectangle, the square class. So this is, this should be interface segregation. So we have solid, so E should have single responsibility. So this is rectangle which is a constructor set with setTightenArea, that is true. Here square is extending rectangle and calling super. Why you are calling super? Because this does not look good, it is way tight, way tight. This is wrong, so this is like the single responsibility and this calls substitution. Interface segregation, I mean this violates single responsibility, I believe, and interface segregation. These two, I believe these are the two which gets violated and the way I would fix this is like, I mean I will take, I will create a separate called, I will create a separate called like calculating the area, means I will create a separate class like area calculation or something and with that I will implement, I mean I will create rectangle class and a square class where I can, means I can extend to those class, I mean the size or the area calculation class in which I will pass these variables to check the height and width, means that way, means that following the abstract factor design pattern along with having the solid principle like single responsibility and interface segregation in place.

Yeah, what's wrong how the track is being used How would you rewrite this correctly handle Okay, the sync function fetch data Let response await fetch Oh You're not trying to return anything in this one But again, that's the try block Catch is error what Why your console you need to throw error over here How would you rewrite this to correctly handle error in an asynchronous context is synchronous contract Oh This Handle error We should be throwing error not consoling. Why are you consoling and error? Uncaught and as you're catching an error I'm not really sure about this and what exactly you're looking

Continuous, describing an efficient way of handling database schema migration in a continuous delivery environment, okay. So database schema migration, there are, the way we define it is like if there are changes in the schema, we, first of all, we try to understand that what we are actually, I mean, database schema migration, schema migration, I mean, what we are trying to do here, is we are adding new columns or we are moving data from, I mean, one source to other, it's difficult, it's difficult to understand. But let's say if I'm trying to just include one more column or modifying the column values instead of, I mean, let's say I have an object as, a strict object as a column, if I'm trying to modify it, what I'll do is I'll, I mean, I'll create a migration script, which will do exactly like, which will, so basically in the migration script, what I'll write, I'll create a temporary table and in that temporary table, I will, the modified schema will be the part of the temporary table. I'll read the data from the existing table, and then start copying, means once I read the number of records and everything, I'll start inserting it into the new schema table. And again, the new, when I send the migration, if it is a mandatory parameter, I have to try to generate a random value, if it is an optional, I'll try to keep it empty. Then I mean, just start copying data from the primary table to the new temporary table. And once the data has been copied, I'll, there is a command which says that you can rename the older table, dump the older table, and start using this new table by changing the table name, or more specifically, by using the term "ALTER TABLE RENAME TO" or something similar.

It's good to have what if I were creating a score in terms of what ways would you transition from Java to Python back in the system affect the team's delivery type. The learning curve, this is something so, I mean, if an existing code is in Java, what would you transition back to Python? The learning curve is the primary concern, and then understanding that if I understand Java, I need to understand Python, but this is half the context I don't understand. I have some couple of cross questions to verify what exactly we are doing. Are we trying to migrate the existing system from Java to Python or is it something where I'm writing Java developers to a Python backend system? This is something which has to be pre-planned. It's not like it can be done immediately. There has to be tracing sessions conducted, and there has to be a proper guideline provided of what needs to be done. And this has to be done with a proper guideline, with a proper planning. It can't be done overnight.

How would you harmonize your Node.js API with third-party payment system integration, Node.js API design with third-party payment integration system, okay. Again, I don't have the complete context, but I'm trying to understand like when you say third-party payment system integration, so we are trying to integrate it with a third-party. Now third-party, we need to understand the request, the response body, the wait time, success scenario, failure scenario, possible failure scenarios, tokens, number of requests that the third-party payment system can handle, timeout scenarios, the failure scenarios, and what are the possible scenarios in which this failure happens, and let's say in case, so after making a payment, something happens, so how would a refund will work like an alternating or as a compensating transaction or compensating action, there are certain things which needs to be understand and planned in a better way. So, I mean there are certain parameters which I don't know, so I'm not even sure what I can do with this, I mean.