Neha Bhavsar

What about your background by the end of the business production? Yeah. Sure. So my name is Neha, and I have around 8 years of experience as a full stack developer. So I have started with back-end development first, and in that, I have experience with the Node Express framework, plus I have also experience with Next.js' framework. And in terms of a database, I have experience with MongoDB, PostgreSQL, DynamoDB, and MySQL. Besides that, I have also experience working with front-end technologies like Angular, React, and Vue.js. And besides that, I have also experience with AWS services like Lambda and state machines and API gateway to start up development services, and also a few deployment services like AWS EKS, AWS ECR, and AWS ECS. So that's about it.

Yes. The method will implement item potency in the list full APIs built with the method. So, a useful API is filled with it. So, regarding the list full API built within Node.js, we need to define a few methods, like, for example, get, put, post, which methods we need to define, and we might need to write the business logic based on our requirement to, like, pass the data into the post request or define the validation layer.

Deciding between REST and GraphQL for a Node-based project depends on the project requirements, which type of structure we need to go with, either REST or GraphQL. So, GraphQL is mostly very easy to use and is straightforward to implement. In terms of a straightforward approach, when we have some specific data that we need to get and some specific results that we need to get from some APIs, and from there, we just need to pick a few columns or keys that are returned from the response. Then, definitely, we should choose GraphQL. And if there are some custom requirements that we have, like we need to upload some files and put some data, and we need to put some data into a third-party or execute some webhooks, or let's say if we want to send an email or a particular SMS type of stuff, then we should go with the REST API.

Configure a postgreSQL replication strategy to improve the phone tolerance of a Node. Js application. Okay. So regarding the replication strategy for a postgreSQL or a vendor database, let's say, if we, there should be there will be always a one primary and there will be can it create a one replica set? So how primary and replica set will be configured and it will work? So let's say whenever we want to write some data into the database and, parallelly, we also want to read some data. So at the same time, we can write some data into the one of the copy. Let's say there is a primary copy of the post process here. And at the same time, we can use the replica to read the data. So we their particular both edit, both operation won't conflict with each other, and it will block or lock the database at the same time because read operation might be sometimes heavy to read. At the same time, write will take some time to write the data into the database. So both should not be block each other.

Setting up a continuous integration workflow using CICD for an area. So, creating a workflow for a CICD tool for a Node.js application. First, we need to define the steps we need to follow. For example, if we're using a Docker container for our Node.js application, we need to write those steps in the CICD workflow. To create a build, we need to include the Docker steps, create an image, and then push that image to either a Docker registry or an Elasticsearch registry. We need to write steps in our workflow to execute those steps. We have specific technical jargon that we can write into our workflow files. Let's say we're using data, so we need to stick to those particular terms to provide. First, create a build and upload that build to the registry. Then, after the registry, upload the build. We can also define that if there's a code push to this branch, then execute these steps. If there's a code push to this branch, you can execute these steps. Based on that, we'll get some commit tags, so we can attach that text to our registry, particular tag. And based on that, we can define which environment should be restarted or which particular instance should be restarted based on those CICD pipeline.

How do you mention both read and write scalability for a postcode as well as a bridge in a high traffic environment? Okay. So as I mentioned in a previous question, when we want to handle heavy read and write operations in a high-traffic environment, we need to consider scalability. We can achieve this by maintaining replicas of our postcode instance. For instance, we can define a setup where there's a primary replica and a secondary replica. Whenever a write operation occurs, the data can be written to both the primary and secondary replicas simultaneously. Similarly, when we need to read data from the database, we can read from both the primary and secondary replicas, ensuring high availability and scalability.

In this Python code that uses Flask, a common design principle is being wired. I can explore and explain. So here, one of the things which I should suggest is that there should be one validation layer which should be there. Either we can use a middleware to authenticate the user. And if that's a create user registration functionality, then there might not see the need for the validation layer for that. But for fetching the user details, there should be a validation layer, I mean, an authentication layer and another validation layer. It should be there for fetching the user details.

So here, what I find is we are not using the body parser or anything to pass our body data. So that should be one. And also, there should be one middleware to authenticate requests. And if that is not required, that might be optional. If this is the public cloud, then that should be fine. But in the other scenario, there should be a body parser to pass the data. And there should be some CORS configuration also needed if it is going to be used or consumed by some other host.

High throughput system using postcode SQL to handle 1,000,000 of transactions per day. Okay. So if you want to handle a million transactions a day using Node.js and a PostgreSQL, then first of all, our Node.js architecture should be designed in a way, and also the PostgreSQL should be defined with some more replicas and also with more configuration, like, as at the same time, there might be some heavy traffic. So we need to handle the throughput with allowed accessibility. So in terms of if, let's say, we think about the Node.js, and Node.js should be secured in a highly scaled application if you want to allow high traffic.

To optimize the cost of cloud resources for a VHS data paper, automancers will be implemented to optimize the cost when we deploy the real test application. It depends, like, are we deploying the static build? So, if we are deploying the static build on a cloud form, let's say if we take an example of AWS, then if there is a static build, we can deploy it to S3, or there should be some light cell instance we can use if it is not a state. Let's say, if we know we are using Fargate, so there might be server-side deployment required. So, at that time, either we can use S3 light cell or, if it is like, server-side, as I mentioned for an ECS, then we might need a VPS. So, if we need a VPS or else we go for AWS, ECS, or something, then we can define our task definitions, like how much resource we have, how much traffic is going to be there, and based on that, we can define our task number, that way, we can make the cost-effective applications, I mean, cost-effective deployment.

TypeScript into an existing Node JS project and what benefits would it be. So, TypeScript itself has many benefits. Like, we can define our linting errors. We can check some type of variable declaration errors and many more benefits that TypeScript provides. In an existing Node.js application, first, we can install the TypeScript model. And based on that, we can upgrade our files to use TypeScript. Like, first, we can update our require statements to import. And based on that, one by one, we can upgrade our packages. There are also some third-party libraries available to directly migrate to TypeScript. We can use those.