React has announced the release of a new compiler, which will improve the developer experience by simplifying code and removing unnecessary features like use memo and forward ref.

### Highlights:

- React's new compiler promises a groundbreaking improvement in the developer experience.

- jQuery has also made headlines with the announcement of version 4.0, dropping support for IE1 and migrating to ES modules.

- The new React compiler simplifies code by removing features like useMemo and forwardRef.

- The compiler eliminates the need for memoization, making code more straightforward.

- Complex features such as forwardRef and server actions will be replaced with simpler alternatives.

- Handling promises and async/await becomes easier with React's new compiler.

- React's improvements align it more closely with other frameworks, potentially leading to similar APIs.

### Key Insights:

React's new compiler significantly simplifies code by removing complex features, such as useMemo and forwardRef, reducing mental overhead for developers.
![useForwrodref.png](https://media.graphassets.com/2aff1CifTJC5N4Na00Wp)

The compiler also improves the handling of promises and async/await, streamlining asynchronous operations in React.

The convergence of React's API with other frameworks may lead to a more standardized and unified development ecosystem.

The removal of features like useMemo and forwardRef simplifies the codebase and makes React more accessible to developers.
![ray-so-export.png](https://media.graphassets.com/5si4hHphROyJYxsdNyf2)
The compiler's optimizations not only boost performance but also enhance the developer experience by reducing the need for manual optimization techniques.

React's new compiler reflects the ongoing trend of simplification and standardization in frontend development, facilitating easier framework transitions and maintaining codebase consistency.

These improvements highlight the continuous evolution of frontend development, with frameworks like React adapting to meet the evolving needs of developers and users.


React has announced the release of a new compiler, which will improve the developer experience by simplifying code and removing unnecessary features like...

React 19: They Fixed React Js  (Everything you need to know)

In our previous article, we explored the deployment of a single instance of our application using the Elastic Container Service (ECS). Now, let's take a deeper dive into our deployment strategy by scaling horizontally and efficiently distributing traffic using a load balancer.

While your application may perform well on most regular days, there are occasions, such as high-traffic events, when we anticipate a surge in users. In such cases, traditional vertical scaling by upgrading server resources with faster CPUs or more memory can be challenging and often leads to downtime.

Instead, we can adopt a horizontal scaling approach. This involves running multiple instances of our application and dividing the workload among them. Horizontal scaling offers several advantages. Firstly, it is a seamless process that doesn't disrupt service. Secondly, it provides fault tolerance, ensuring that if one instance encounters issues, traffic can be directed to the remaining instances, ensuring uninterrupted service availability.

### Setting Up Security Groups

In our previous article, we made adjustments to the default security groups to enable incoming traffic for our application instance. Now, we'll take a step further by creating two new security groups from scratch.

### Creating a Security Group for the Load Balancer

When utilizing a load balancer, clients seeking access to our API don't establish a direct connection with a specific application instance. Instead, they interact with the load balancer, which acts as an intermediary, routing requests to one of the application instances.

To ensure the seamless operation of our load balancer, we must define the appropriate security group rules for accepting incoming traffic. To create a fresh security group, navigate to the EC2 panel and locate the "Security Groups" option in the left sidebar under the "Network & Security" category.

![S01.png](https://media.graphassets.com/RW6yO1ERS6GYtvIy3ErQ)

In the context of our security group setup, a critical step involves adding an inbound rule that permits incoming HTTP traffic on port 80 from external sources.

### Security Group for EC2 Containers

As users direct their requests to our load balancer, the load balancer becomes the gateway responsible for forwarding these requests to our application running within the EC2 instances. To facilitate this communication seamlessly, we must explicitly grant permission for the load balancer to interact with our application. To achieve this, we will establish a distinct security group dedicated to this purpose.

![S02.png](https://media.graphassets.com/6TDIX9vDQ3KldaoqidHV)

An essential aspect of the configuration mentioned above is enabling incoming traffic from the load balancer. This is achieved by specifying the previously created security group as the source for inbound traffic.

### Setting Up the ECS Cluster

In order to proceed with the following steps, it's essential to have our ECS (Elastic Container Service) cluster ready. Let's go ahead and create it.

![S03.png](https://media.graphassets.com/JD9BwfBvT5uNkc3nN9zQ)

The pivotal aspect of configuring the ECS cluster is defining the number of instances, and in this case, we'll opt for simplicity by setting it to two instances.

![S04.png](https://media.graphassets.com/hSYmaileQk2ppLojvqz6)

### Creating the Task Definition

Within our ECS cluster, we have the flexibility to execute various tasks and to enable this, we must create a task definition. This process closely resembles what we previously accomplished in the prior article.

![S05.png](https://media.graphassets.com/yhzfHXGeTG61EwN5aaUK)

Once again, our task definition involves configuring it to utilize the URI of the Docker image we've uploaded to the Elastic Container Repository. 

![S06.png](https://media.graphassets.com/1ACC4RdmQQmEU8i9DZlr)

Additionally, we expose port 3000, which is essential for our NestJS application.

![S07.png](https://media.graphassets.com/Wbyxge3gRuzd4zAOmu8Y)

In the preceding part of this series, we configured our task definition with static host port mapping. However, since we intend to use an Application Load Balancer with multiple instances of our application, dynamic port mapping becomes necessary. Consequently, 

We won't be altering our task definition to establish static mapping.

![S08.png](https://media.graphassets.com/VKLwIIIfRGyY4pbMxd3l)

Furthermore, we must supply the required environment variables for our Docker image. The area that necessitates configuration is the environment section.

![S10.png](https://media.graphassets.com/F7ej83H8S2Zq7skDbfPg)

### Running Multiple Instances

Configuring the ECS cluster and the task definition doesn't differ significantly from our previous setup with a single instance of our application. However, running multiple tasks requires a slightly different approach.

- **Creating a Service:** Begin by accessing your new cluster and creating a service capable of running multiple tasks. Click the "Create" button to initiate this process.

![S11.png](https://media.graphassets.com/ibRsyYOQMaPCPhXDldYE)

- **Selecting Launch Type:** Given that we intend to use EC2 instances within our cluster, it's crucial to select the appropriate launch type.

![S12.png](https://media.graphassets.com/PaAE5L7bSZageSAtZR3d)

- **Choosing Application Type:** Opt for the "Service" option, which enables us to launch a group of tasks that can be distributed across our ECS cluster.

> Using the "Daemon" service type would mean deploying precisely one task on each active container in our ECS cluster. Instead, we should employ the "Replica" option, allowing AWS to distribute tasks dynamically across the cluster.

![S13.png](https://media.graphassets.com/h2ildmkdQgOExK1O7xv5)

- **Load Balancing Configuration:** Here's where we focus on configuring the load balancer. This presents an opportunity to create a new load balancer, and one of the key elements in its setup is the target group.

> In AWS, target groups serve as directives for the load balancer, guiding it on where to route traffic. The load balancer regularly sends requests, known as health checks, to registered targets to verify their functionality.

![S14.png](https://media.graphassets.com/gYEgnJeMShaOP3FuCTyp)

Our NestJS application offers the /<your-end-point> endpoint, which retrieves a list of data from the database. In this simplified example, this endpoint can double as a health check, ensuring the proper functioning of our application instances.

### Implementing the Configured Security Groups

Upon running the service as described above, it results in the creation of two EC2 instances. To ensure the correct security configurations, follow these steps:

**1. Modifying EC2 Instance Security Configuration:**

![S15.png](https://media.graphassets.com/3lipJJR9RoSYvTvDDjDS)

- Access each EC2 instance individually through the EC2 user interface.
- Modify their security configurations to include the  "EC2InstanceWithLoadBalancer" security group that was created at the beginning of this article.
- Add the "EC2InstanceWithLoadBalancer" security group to both EC2 instances.

![S16.png](https://media.graphassets.com/WWDaNqvhSGy3u72GdmIH)

**2. Configuring Load Balancer Security:**

- Locate your newly created load balancer in the list.
- Modify the load balancer's security configuration by adding the "LoadBalancerGroup."

![S17.png](https://media.graphassets.com/jDglPuL4QOCmjWPShget)

These steps ensure that both your EC2 instances and load balancer have the necessary security groups applied to enable seamless communication and traffic distribution within your ECS cluster.

### Accessing Our API

**To access our API, follow these steps:**

- Locate the Load Balancer Configuration:

> Open the configuration page of your load balancer.

- Find the DNS Name:

> Look for the DNS name section within the load balancer's configuration.

![S18.png](https://media.graphassets.com/QdQTUH17TeuvudotAVis)

- API URL:

> The DNS name you find in the load balancer's configuration is the URL for your API.
You can now use this URL to make requests to your API.

![S19.png](https://media.graphassets.com/NEyp6C6tQKG8AlBhvJpW)

### Summary

In this article, we successfully deployed multiple instances of our NestJS application on AWS, enhancing our ability to handle incoming traffic effectively by utilizing a load balancer. We also established new security groups to facilitate communication between the load balancer and the EC2 instances.

Horizontal scaling through multiple application instances offers scalability benefits, but it introduces considerations. Instances operate independently, potentially leading to challenges like data integrity when using in-memory caches.

To address the aforementioned challenges and ensure data consistency, we can implement a shared cache among multiple instances. A common solution for this is Redis.

There is much more to uncover regarding deploying NestJS on AWS, so stay tuned for further insights and developments!

Scaling (Multiple Instances) Your AWS Deployment with a Load Balancer

### Uploading our Docker image to AWS
Up until now, we have constructed our Docker image on our local machine. In order to proceed with the deployment, it is necessary to upload the image to the Elastic Container Registry (ECR). ECR functions as a container registry, where Docker images can be stored. It operates in a similar manner to Docker Hub. Once we have successfully uploaded our image to the Elastic Container Registry, it becomes accessible for utilization with various other AWS services.

To initiate the process, we should begin by accessing the ECR service.



![ecr-image.png](https://media.graphassets.com/asIYxxlYQsmveqoXwrh9)

Initially, we must establish a repository specifically for our Docker image.
![repository.png](https://media.graphassets.com/8yPIzPwTPOpvFnEXOHpB)
After constructing our NestJS Docker image, we should proceed with pushing it to our ECR repository. Once the image is successfully uploaded, we can navigate to the newly created repository and locate the "View push commands" button.
![repo-image.png](https://media.graphassets.com/Ti6TWY6pSc2GnfqmASFu)
Upon clicking the "View push commands" button, a popup will appear, providing a comprehensive list of commands that need to be executed in order to successfully push our Docker image to the repository. This serves as a helpful guide, ensuring that all the necessary steps are followed for the image upload process.
![push-cmd.png](https://media.graphassets.com/XSJPkLBWTlKcvaEy6eRg)
### Authenticating with AWS CLI
To authenticate with the AWS Command Line Interface (CLI), the first step mentioned in the provided popup, we need to have an understanding of the AWS Identity and Access Management (IAM) service.

IAM enables us to manage access to our AWS resources. When setting up a new AWS account, we initially have the root user, which possesses unrestricted access to all AWS services and resources within the account. However, it is highly discouraged to utilize the root user for everyday tasks. Instead, it is advisable to create an IAM user with limited permissions.

For our specific use case, the IAM user should be granted the "

> AmazonElasticContainerRegistryPublicFullAccess

" permission. This permission will enable us to push our Docker image to the ECR (Elastic Container Registry).
![i-am.png](https://media.graphassets.com/88HtA1tTcutXBtlTfs9n)
We should access the "Security credentials" section and create an access key, which will be utilized in conjunction with the AWS CLI.
![acc-key.png](https://media.graphassets.com/OaeHkFmQLgq25AccxELw)
The last step is to run the 

> aws configure

 command in the terminal and provide the access key and the secret access key we’ve just created.

### Pushing the docker image
We can now proceed with executing the push commands provided in our ECR repository to upload the Docker image. 

> (Just open your terminal and copy/paste the command that shows in a push command window (You can see the above image) )

Once we successfully execute the aforementioned steps, our Docker image will become visible within the ECR (Elastic Container Registry).
![uploaded-docker.png](https://media.graphassets.com/1QGkf3XhQo2zucgDc0Hp)

### Connect with  ECS cluster

AWS offers the Elastic Compute Cloud (EC2) service, which allows users to launch virtual servers capable of running various applications. However, when using Docker with plain EC2, the process of installing and managing Docker manually on the server can be cumbersome.

To simplify this process, AWS provides the Elastic Container Service (ECS). With ECS, users can run a cluster consisting of one or more EC2 instances specifically designed to run Docker. The advantage of using ECS is that it eliminates the need for manual installation and management of Docker on the server.

It's important to note that ECS is not a replacement for EC2 but rather a complementary service. ECS and EC2 can seamlessly integrate with each other to enhance the functionality and capabilities of deploying Docker containers.

1. To begin using ECS, the first step is to open the ECS interface in the AWS Management Console.
![ecs.png](https://media.graphassets.com/rybfkYNqSLK8UlQsHOeT)
2. Now, we have to create a cluster and give it a name.
![ecs-name.png](https://media.graphassets.com/VQtdrXh1Smq97KgCllNN)
3.While leaving most of the configuration settings at their default values, it is essential to configure the cluster to utilize EC2 instances.
![esc-config.png](https://media.graphassets.com/48ZgG8rYQmu6m1UHMSz3)
### Creating a task definition
To run tasks within the ECS cluster, the Amazon ECS service requires a task definition. A task definition defines various parameters for running tasks, including the Docker image to be executed. In our case, we need to create a task definition specifically for running our Docker image.
![task-def.png](https://media.graphassets.com/bzXz9fPdQVuViFDk9RWU)
When setting up the task definition, we should utilize the results obtained from the previous steps in this article. In particular, we need to specify the URI of the Docker image that we have previously pushed to our ECR repository.
![task-def-one.png](https://media.graphassets.com/swd5SVihTrGeOtqUqKB1)
In order to interact with our NestJS application, which runs on port 8080, we must expose that port. This will enable external communication with the application.
![task-def-two.png](https://media.graphassets.com/rPZwPbB5ShWZ6T42pt3Z)
Additionally, it is crucial to provide all the necessary environment variables required by our Docker image. These environment variables ensure that the application inside the Docker container can access and utilize the required configuration settings or external services.
![CleanShot 2023-06-02 at 20.08.12@2x.png](https://media.graphassets.com/JAQy2P9aTlSCS1XJsHPA)
The final step in configuring our task definition involves specifying the infrastructure requirements. This includes defining the CPU and memory resources needed for each task, configuring task placement constraints, and any other infrastructure-related specifications required for the proper execution of our tasks within the ECS cluster.
![final.png](https://media.graphassets.com/6WHBxs0nQreTsHJ7aXk3)
### Configuring static host port mapping
By default, when we enter the value "8080" in the port mappings within the aforementioned interface, AWS expects us to set up the dynamic port mapping. However, for the sake of simplicity, let's take a different approach.[You can ream more on thin link.](https://aws.amazon.com/premiumsupport/knowledge-center/dynamic-port-mapping-ecs/)

To modify the configuration, we can make changes to the existing task definition we created earlier. This can be done by opening the task definition and clicking on the "Create new revision" button.

Once we have created a new revision of the task definition, we can proceed to the port mappings section and set the host port as "8080". This adjustment ensures that the application will be accessible through port 8080 when running in the ECS cluster.

![8080.png](https://media.graphassets.com/ncysT46nRWWuEZnT6Anb)
Upon clicking the "Create" button, AWS will generate a new revision of our task definition, incorporating the modifications we made. This new revision will reflect the updated configuration settings for the task definition.
### Running The Task On The Cluster
Once the task definition is properly configured and ready, we can proceed to open our ECS cluster and initiate a new task execution within it.
![cluster.png](https://media.graphassets.com/2x5wFHdT9KYpCdkAcXMA)
Before running a new task in the ECS cluster, it is important to ensure that the environment is set up correctly. This involves verifying that all the necessary dependencies, configurations, and permissions are in place to support the proper execution of the task.
![cluster-1.png](https://media.graphassets.com/AVZrVW6qQmUVchDn2FUi)
In the process of running a new task in the ECS cluster, we must select the task definition that we created in the previous step. This ensures that the task is launched using the specified configuration and settings defined in the task definition.
![cluster-3.png](https://media.graphassets.com/sjmRfmebRSfUaUC8qQZo)

> Please note that we are utilizing the second revision of our task definition, which incorporates the static host mapping approach.

After clicking the "Create" button, AWS will commence the execution of the task that we have defined. The ECS service will initiate the necessary processes to run the task within the cluster based on the provided configuration.
### Accessing the API
To view the details of the EC2 instance created by our ECS cluster, we can navigate to the EC2 service in the AWS Management Console. By accessing the EC2 service, we can retrieve information about the instance, such as its configuration, networking details, and other relevant specifications.
![ec2.png](https://media.graphassets.com/IXqpE359SyGu5pEMeNWX)
After accessing the EC2 user interface, the next step is to open the list of instances. This list provides an overview of all the EC2 instances associated with your AWS account.
![ec2-1.png](https://media.graphassets.com/EHNhL2Q4QvSy8y6fSt1n)
Upon opening the specific EC2 instance, you will find the "Public IPv4 DNS" section, which displays the address of your API. This DNS address can be used to access your API externally and interact with it.
![dns.png](https://media.graphassets.com/m6G6JDQySl6AGje3WFgZ)
To enable access to your API, you need to configure it to accept incoming requests on port 8080. This involves setting up the necessary network and security configurations to allow traffic on port 8080 to reach your API. By allowing incoming requests on this port, external users will be able to access and interact with your API.
### Setting up the security group
By opening the "Security" tab, you can access and modify the inbound and outbound rules of the security group, allowing you to control the traffic allowed to reach and leave the EC2 instance.
![seq.png](https://media.graphassets.com/7G1diIbpS5fKFRrfKEHF)
To modify the inbound rules of the security group and open port 8080, please follow these steps:

1. On the configuration page of the security group, navigate to the "Inbound rules" section.
2. Click on the "Edit inbound rules" button to modify the rules.
3. Create two new rules:

- For the first rule, set the source to "Anywhere-IPv4" and select port 3000.
- For the second rule, choose "Anywhere-IPv6" and specify port 3000.

By creating these rules, you allow incoming traffic on port 8080 from both IPv4 and IPv6 sources. This enables external requests to reach your API running on the EC2 instance.
![seq2.png](https://media.graphassets.com/QSal2ZoTGWDy1BPGBSOQ)

Once we do the above, we can start making HTTP requests to our API.

### Summary
In summary, here are the steps we have covered in deploying a NestJS app with Amazon ECS and RDS:

- Pushing the Docker image to ECR: We pushed our Docker image to the Elastic Container Registry (ECR), a repository for storing Docker images.
- Creating a task definition: We created a task definition in ECS to define the parameters for running our Docker image, including the URI of the image in the ECR repository.
- Configuring the task definition: We configured the task definition to expose port 3000, where our NestJS application runs, and provided any necessary environment variables.
- Modifying the task definition: We modified the task definition to use static host mapping for port 3000 instead of dynamic port mapping.
- Running the task on the cluster: We ran the task on the ECS cluster using the specified task definition, allowing the application to run on the EC2 instances.
- Accessing the EC2 instance details: We accessed the EC2 service to view the details of the EC2 instance created by the ECS cluster, including the Public IPv4 DNS, which provides the address of our API.
- Configuring security group inbound rules: We modified the inbound rules of the default security group assigned to the EC2 instance, opening port 3000 for incoming requests from both IPv4 and IPv6 sources.

> If you have any problem just put a comment and I try my best to answer it.See you in next one.























React 19: They Fixed React Js (Everything you need to know)

Highlights:

Key Insights:

LEAVE A COMMENT OR START A DISCUSSION

MORE ARTICLES

Scaling (Multiple Instances) Your AWS Deployment with a Load Balancer

Deploying a NestJS application using Amazon ECS and RDS

React 19: They Fixed React Js (Everything you need to know)

Highlights:

Key Insights:

LEAVE A COMMENT OR START A DISCUSSION

MORE ARTICLES

Scaling (Multiple Instances) Your AWS Deployment with a Load Balancer

Deploying a NestJS application using Amazon ECS and RDS

Weekly

Monthly