DEV Community: SteveJin

SWS Console: Creating an SPA project and connecting it to S3 web hosting, CloudFront, and Route53 domain in 5 minutes.

SteveJin — Fri, 01 Mar 2024 12:40:14 +0000

To deploy an SPA (React.js, Vue.js, Angular.js, etc.) project on AWS Cloud, there are several options available.

The first option is to set up an EC2 instance with Nginx or a local Node server to serve the SPA project's build artifacts such as index.html and bundle.js.

→ To implement the first method, you need to first create an EC2 instance and set up either a Node environment or upload the SPA build files to EC2. Then, configure Nginx or Apache server to serve the index.html of the SPA build artifacts. Afterward, you would need to connect it to ALB or Elastic IP for hosting.

The second option is to Dockerize the SPA project, upload it to AWS ECR, set it up on AWS ECS, and then host it through ALB.

→ For the second method, you need to learn about Dockerizing the SPA project, setting up scripts to upload to AWS ECR, running Docker images from ECR on ECS, creating ALB, and configuring the target group to point to ECS.

The third option is to upload the SPA build artifacts to an S3 bucket, enable static website hosting, and host it through CloudFront.

→ For the third method, you need to upload the SPA build artifacts (including index.html, bundle.js, and other files) to S3, configure static website hosting on the S3 bucket, and then connect the S3 bucket endpoint to CloudFront.

Why choose the third option? The reasons are as follows:

The first method incurs costs as EC2 instances are billed for the duration they are running, making it expensive to maintain over a month. Additionally, EC2 instances require direct management.

The second method also incurs costs as ECS instances are billed for the duration they are running, making it expensive to maintain over a month.

On the other hand, the third method incurs minimal costs as S3 charges per GB stored, and CloudFront costs are generally low unless there is very high traffic.

Now, if you've chosen the third method, let's first open the project for deployment, which is the main page of the Steve Web Service (SWS) project, in an editor.

The project mentioned above is an SPA project implemented in React.js. When you execute the build script in the project (in the example provided, npm run build), it generates a build folder. You then compress this build folder into a zip file.

Next, go to the SWS Console, enter AWS Frontend DMS, input the Project Name, upload the compressed zip file of the build folder, and then press Create Project. In just 5 minutes, everything from S3 static web hosting to CloudFront will be set up at once.

Upon entering the detailed view of the created project, you'll notice the CloudFront Domain. Clicking on it and navigating will confirm that the page displays correctly. Isn't it remarkably straightforward?

Go to the Steve Web Service Page

Go to see how to create a project in Steve Web Service AWS Frontend DMS

Now that S3 and CloudFront are set up, the last task for us is domain linking.

First, click on "Go to purchase a domain in Route53" as shown in the image below, then navigate to the page. Next, input the desired domain name in the "Register domain" section. The domain should be entered in the format of abc.com .

Next, select the desired domain name to purchase, as shown in the image above, then click "Proceed to checkout." Afterward, click "Next," input your contact information, click "Next" again, and finally, press "Submit" to complete the domain purchase in Route 53.

Go to the Steve Web Service Page

Go to see how to purchase a domain in AWS Route53

Next, navigate to Route 53 → Domains → Requests as shown in the image above, and wait until the purchased domain's status becomes "Successful."

Now, go back to the detailed view of the created project in the Sws Console, select the purchased Route53 Domain, and then click the "Create SSL Certificate" button to obtain an SSL certificate.

After refreshing the page and confirming that the SSL/TLS Certificate Status has changed to ISSUED, enter the subdomain name, and click the "Connect Domain" button to complete the domain linking. The above image is an example of connecting to http://web.swstest.net .

You can verify that it successfully connects by accessing https://web.swstest.net.

In this way, without any prior knowledge of AWS Cloud, we have deployed an SPA project through the SWS Console.

SWS continues to develop tools that assist users in building cloud architectures without the need for extensive AWS Cloud learning. This enables developers to focus more on their business, and further, it provides value by allowing even small teams of developers to leverage a maximum of AWS resources.

Go to the Steve Web Service Page

SWS Console: Outsourcing development directly with SWS build tool (AWS build).

SteveJin — Sun, 25 Feb 2024 13:51:22 +0000

I wanted to see how much productivity could be increased by creating the SteveWebService Console and outsourcing development using its features.

So, I joined a well-known outsourcing platform in Korea and created a product where I requested the development of a simple admin interface.

We wanted to receive projects that could be developed quickly with minimal time investment.

So, we decided to proceed with a project that required minimal functionality, such as account creation, login, permission management, Excel download, CRUD, etc.

Thus, we received our first project, which was a simple product and employee performance management ERP project, with the following details:

The account types included master administrator, intermediate administrator, and regular accounts. Regular accounts could register the number of products and input status (e.g., in progress, completed, terminated). For confidentiality reasons, I'll refer to them as "products."

Additionally, there were screens for master and intermediate administrators to view logs of product registrations and to check daily and previous day performance statistics.

We defined the specifications for development and decided to choose the most cost-effective option for the customer. Here's what we decided:

Frontend development would be done using React.js, with business logic controlled within React.js applications.

We would create AWS Lambda CRUD APIs & mysql RDS instances on AWS Cloud, avoiding server setup costs and only paying for RDS usage.

The React project would be deployed using S3 static web hosting + CloudFront, avoiding instance maintenance costs.

After deciding on these steps, we first provided the customer with documentation on how to sign up for AWS Cloud and register their card. Once they signed up, we requested their account ID and password, created an IAM user for them, and set permissions for using the SteveWebService Console.

Next, we had to set up the VPC using the SteveWebService Console, which was remarkably straightforward.

By simply creating a Sws Project (VPC & API GW Turn Key) on the SteveWebService Console, everything from VPC, subnet, security group to Api Gateway is set up in just 10 minutes.

Visit the Steve Web Service Page to check

Go to see Steve Web Service AWS VPC Turn Key functionality

Next, setting up the RDS DB instance didn't take much time either.

By utilizing the DB & Bastion EC2 Turn Key on the SteveWebService Console, you can configure Private RDS & Bastion EC2 in just 10 minutes.

Isn't it incredibly easy?

Visit the Steve Web Service Page to check

Go to see Steve Web Service AWS DB & Bastion EC2 Turn Key functionality

Next, after creating the RDS on the SWS Console, I accessed the RDS Detail screen, downloaded the PEM Key, and followed the commands provided in the Access Guide. By connecting to the Bastion EC2 via terminal and accessing the RDS DB, I then created tables according to the designed DB table structure.

After completing the above steps, the final stage was to create CRUD APIs for each table.

This, too, was remarkably straightforward, as I simply used the AWS Lambda CRUD API Turn Key feature to generate CRUD APIs for each table, as shown below.

Isn't it incredibly easy? We managed to shorten the process of creating CRUD APIs, which usually involves building an API server, implementing CRUD operations, deploying it to instances, all within 10 minutes.

Visit the Steve Web Service Page to check

Explore Steve Web Service AWS Lambda CRUD Turn Key functionality

After generating CRUD APIs in this manner, I navigated to the SWS Project Detail to verify the endpoints and request paths. Then, as shown below, I set up functions in the React code to use them immediately.

After setting up like this, we proceeded to develop the business logic in the React app according to the customer's requirements.

While creating the admin web, we encountered additional requirements from the customer. They needed statistical data extracted from their data to be displayed on the screen.

We were able to address this by providing the data via the API generated with Lambda CRUD Turn Key, enabling a simple solution.

All we needed to do was to create the additional logic to include in the query, as shown below.

Having completed the application development, only the deployment phase remained.

At this stage, we decided to deploy the React app using S3 static web hosting and CloudFront. To set this up traditionally, we would need to configure these two services separately and upload the build files. However, I expedited the process by deploying it in no time using the AWS Frontend DMS feature in the SteveWebService Console.

The deployment process was remarkably straightforward. Simply compressing the folder containing bundle.js and index.html into a zip file, uploading it in the Frontend DMS, and creating it completes the deployment.

And if providing a Cloudfront Domain or a custom domain is needed, it's as simple as purchasing a domain from Route53, generating an SSL certificate, and connecting the domain.

Visit the Steve Web Service Page to check

Explore Steve Web Service AWS Frontend DMS functionality

Successfully delivering our first outsourced development project was a significant and meaningful experience for us.

Through configuring VPCs, setting up RDS, building APIs, and deploying resources, we learned that SteveWebService helps streamline these activities, typically requiring extensive learning and setup time in AWS Cloud, within 40-50 minutes, without the need for AWS Cloud expertise.

We will continue to develop tools that assist users in building cloud architectures without the need for extensive AWS Cloud knowledge, enabling developers to focus more on their business. Furthermore, we aim to provide value by allowing even small teams of developers to make the most of AWS resources.

The next article will delve into the history of solving different problems. End.

Visit the Steve Web Service Page to check

SWS Console: Creating AWS Lambda CRUD APIs for DynamoDB and RDS DB tables.

SteveJin — Sat, 24 Feb 2024 14:06:17 +0000

My first developer career started as a Node.js full-stack developer. However, diving into full-stack development as a first career path often resulted in shallow learning, making it challenging to grasp all aspects thoroughly in practice.

Especially early on, I primarily focused on studying React and JavaScript, so before starting my developer career, I had mostly focused on frontend development.

Consequently, understanding API servers and databases was even more challenging for me, and it took a long time to study and comprehend them.

I believed that the above process wasn't unique to me alone. Therefore, while creating the SteveWebService console service, I aimed to provide features that would make it easier for developers facing similar challenges to build and handle APIs and databases. That's where the Lambda CRUD API Turn Key feature comes in. The idea is illustrated in the image below.

Through the Lambda CRUD API Turn Key feature on SteveWebService, users can select an SWS Project, choose either DynamoDB or RDS instance name, input the table or collection name, and generate CRUD APIs for the specified table or collection in AWS Lambda. These APIs are then connected to the API Gateway of the selected SWS Project, enabling immediate usage of CRUD APIs.

The reason for directly connecting Lambda Functions to API Gateway is that when creating an SWS Project (VPC Turn Key), the API Gateway is automatically generated.

Visit the Steve Web Service homepage

Explore Steve Web Service AWS VPC Turn Key functionality

We implemented the above idea and designed the input process as follows.

Isn't it incredibly easy? By creating it as described above, CRUD APIs for the selected database table are generated instantly.

Visit the Steve Web Service homepage

Explore Steve Web Service Lambda CRUD API Turn Key functionality

The benefits of being able to create CRUD APIs are as follows:

Elimination of the need for a dedicated CRUD API server, resulting in reduced server instance costs as AWS Lambda operates on a per-request pricing model.

Saving time by eliminating the need to develop a CRUD API server.

When developing simple microservices, placing business logic in the frontend removes the need for separate backend development, enabling rapid prototyping.

Now, after creating CRUD APIs using Lambda CRUD API Turn Key, how can you determine the endpoint and usage specifications?

By accessing the Detail screen of the SWS Project mentioned earlier, you'll find the API request endpoint and example code provided as shown in the image below.

Assuming that the image depicts an example scenario where a Lambda CRUD API was generated targeting a table named "test".

In the "Crud RDS Request Code" image:

The first select box represents selecting the method (e.g., GET, POST, PUT, DELETE).

The second select box allows choosing the technology stack to provide the request example code.

For the Route Path indicated by the second arrow, you should insert the path corresponding to "1번" (the first part) and preceding it is the API Gateway path.

With this, users can create APIs using the SteveWebService tool without the need to learn about AWS Cloud's API Gateway, Lambda, or CRUD API design, saving on server setup and operational costs, development time, and more! Isn't it amazing?

Continuing in this vein, we will keep developing tools that assist users in building cloud architectures without the need for extensive AWS Cloud knowledge, enabling developers to focus more on their business. Furthermore, we aim to provide value by allowing even small teams of developers to make the most of AWS resources.

The next article will delve into the history of solving different problems. End.

Visit the Steve Web Service homepage

SWS Console: Creating Private RDS instances and Bastion EC2 resources.

SteveJin — Fri, 23 Feb 2024 14:45:20 +0000

After creating the AWS EC2 DMS service on the SteveWebService Console, we pondered another issue. Typically, to launch a service, one needs to configure client web, API servers, and a database.

Considering this flow, we naturally thought that configuring RDS instances is necessary in AWS Cloud.

So, we decided to create the service following the flow depicted in the image below, and named it DB & Bastion EC2 Turn Key.

First, when creating an RDS with DB & Bastion EC2 Turn Key, the creation begins with setting up the Bastion EC2. If a Bastion EC2 already exists within the VPC (SWS Project), it won't be created separately.

Additionally, the RDS instance is created privately. The reason for creating it privately is that when you create a VPC using the Sws Console's VPC Turn Key (SWS Project), the Security Group of the RDS is configured so that it can only be accessed via the Bastion EC2.

Visit the Steve Web Service homepage

Visit Steve Web Service AWS VPC Turn Key feature

Now, in the creation process outlined above, we've minimized the elements users need to input to the extent possible, so that with just project selection, database name, and engine type (mysql, mariadb, etc.), the RDS instance can be created in just 10 minutes, as depicted in the image below.

Isn't it incredibly easy? Users can configure RDS with just simple inputs and clicks, even without any prior learning about AWS Cloud.

But we didn't stop there; we've structured the interface to provide detailed screens on how users can access RDS instances via the Bastion EC2.

Through the console, users can download a PEM key and access guidance on how to connect to the Bastion EC2, enabling them to access and utilize the RDS from there. With the SteveWebService tool, users can configure an architecture to access Bastion EC2 and RDS instances privately on AWS Cloud without learning about EC2 or RDS. Isn't it remarkably easy?

Continuing in this vein, we aim to develop tools that assist users in building cloud architectures without the need for learning AWS Cloud, allowing developers to focus more on business. Furthermore, we strive to provide value by enabling even small teams of developers to make the most of AWS resources.

Our next article will delve into the history of solving different problems. End.

Visit the Steve Web Service homepage

SWS Console: Routing multiple private EC2 instances to AWS ALB.

SteveJin — Fri, 23 Feb 2024 09:33:27 +0000

In a previous post related to EC2 DMS, I created a feature that I had discussed with a colleague. As I began exploring technical discussions in online communities, I noticed that people deploying projects on EC2 instances were grappling with similar concerns. One of the challenging concepts that emerged was the configuration of a single ALB to route traffic to multiple instances.

To make this clearer, I'll explain using the image below.

The scenario is as follows: Let's assume we are implementing Microservices Architecture (MSA) by deploying payment, logging, and product servers on separate EC2 instances. The crucial aspect here is to route traffic to the appropriate server when a request comes to a single ALB, ensuring that requests reach the intended server.

The limitation of the existing EC2 DMS setup was that it was implemented with a one-to-one mapping of API servers to ALBs. Consequently, the target group rules were broadly defined, directing all requests to a single EC2 instance.

Visit the Steve Web Service homepage

Visit EC2 DMS Documentation

To address this issue with EC2 DMS, we devised the following flow, as depicted in the image below:

SWS Project (VPC) is selected.
Select NEW ALB.
Choose CUSTOM for Target Path Pattern and input rules. In this case, users set the prefix path for each server's controller, and specify the rule accordingly. For example, if a request starts with /api/payment, it will be routed to the payment EC2 instance.
Enter the Target Health Check Path. For instance, if the path /api/payment/health is requested, a simple text such as "OK" should be displayed without any authentication or authorization checks.
Target Priority determines the priority, ranging from 1 to 999. Higher numbers indicate lower priority.
The rest follows the creation process of EC2 DMS. → Go directly to EC2 DMS creation method.

We implemented the above idea, ultimately assisting people in routing traffic to multiple instances on a single ALB through EC2 DMS. By simply selecting the target ALB and following the same process, we could help route traffic to multiple instances on a single ALB.

If users were to set up the above process manually, they would need to learn various aspects, from creating ALBs to setting path patterns in target groups.

However, achieving our goal with just these settings seems straightforward, doesn't it?

Visit the Steve Web Service homepage

Go to the documentation on routing multiple instances to an ALB with EC2 DMS

We will continue to create tools that enable users to build cloud architectures without extensive AWS Cloud knowledge, allowing developers to focus more on business needs. Furthermore, we aim to provide value so that even small development teams can make the most of AWS resources.

Our next article will address another problem-solving history. End.

Visit the Steve Web Service homepage

SWS Console: Deploying my service to Private EC2 within 10 minutes.

SteveJin — Thu, 22 Feb 2024 16:36:49 +0000

As I began my journey in development, I encountered numerous developers. As I delved into development tasks, I naturally learned about setting up instances and deploying them in the cloud. I thought anyone would eventually start this way, as deploying is a crucial step regardless of whether you're developing API servers or clients. I believed this process would be learned gradually as one gained experience.

However, I discovered that both junior and senior developers, like myself, faced difficulties in this process. This realization led me to ponder if there was a way to alleviate these challenges, and thus, I created EC2 DMS.

The idea was conceived as illustrated in the image below.

Let's assume you want to deploy a Java JAR build project to a Private EC2. According to the diagram, using SWS EC2 DMS functionality, you would upload the JAR build file to Bastion EC2, then transfer the file from Bastion EC2 to Private EC2. Following that, you would configure the environment on Private EC2 based on the build stack, execute the project, and connect the instance to the ALB target group.

However, the process doesn't end there. You also need to configure Security Groups for Bastion EC2, Private EC2, and the Public ALB as shown in the image.

In this process, there are numerous AWS Cloud concepts to learn, which can be overwhelming and headache-inducing. But using the SteveWebService Console, you can build this architecture with minimal input, ensuring it's set up in your AWS Cloud environment as depicted.

The process is as follows:

First, create an AWS VPC Turn Key (SWS Project). When you create an AWS VPC Turn Key (SWS Project), it generates Security Groups structured as shown below. (While various resources are created, the crucial aspect for this scenario is Security Groups, so only the image related to them is shared.)

Once created according to the above structure, users no longer need to design Security Groups. Isn't that easy?

Go to Steve Web Service Page to check

Go to see Steve Web Service AWS VPC Turn Key functionality

Now, through EC2 DMS, you only need to make minimal inputs and selections as shown in the image below. Refer to the image below:

First, select the previously created SWS Project and enter the Project Name. Then, choose the Stack, upload the Java project's JAR build file, and if it's a custom port, change the port number accordingly. Simply click "Create Project".

By doing so, Bastion EC2, Private EC2, a new ALB to connect to the instances, and the target group connected to the Private EC2, as depicted in the initially shared image structure, will be created in just 10 minutes.

Go to Steve Web Service Page to check

Go to see Steve Web Service AWS EC2 DMS functionality

Isn't it easy?

We don't stop at just creating; we also provide management capabilities for these instances. Functions include resizing instance sizes, managing Bastion EC2 IP, issuing SSL certificates for domains purchased through Route 53, and connecting them to ALB, as shown in the image below.

In the provided image, selecting the domain purchased through Route 53 as in step 6 and clicking the "Create SSL Certificate" button completes the SSL certificate setup for that domain.

Next, in step 9, the user only needs to input the Subdomain name, and upon clicking the "Connect Domain" button, the connection to Route 53 with HTTPS:// for the respective subdomain is established.

Isn't it incredibly easy? Users can deploy projects to the cloud and deliver them to users without any knowledge of AWS Cloud.

Go to Steve Web Service Page to check

Go to see Steve Web Service AWS EC2 DMS usage guide

We continue to develop tools that enable users to build cloud architectures without the need for learning AWS Cloud. This helps developers focus more on their business, and further provides value by allowing even small teams of developers to utilize AWS resources to the fullest.

The next article will delve into solving the issue of connecting multiple instances to a single ALB and routing based on paths. End.

Go to Steve Web Service Page to check

SWS Console: Developing a tool to quickly build AWS cloud architectures.

SteveJin — Mon, 19 Feb 2024 13:11:50 +0000

The architecture of AWS Cloud is becoming increasingly complex. As the salary of Cloud DevOps Engineers has risen to between $147,220 and $156,348 in the US, the importance of cloud engineers has increased. Consequently, the cost of hiring developers that companies need to employ has skyrocketed geometrically, and cloud technology is rapidly advancing.

Moreover, as the cloud structures become more complex, junior developers and newcomers need to adapt to increasingly challenging learning curves. Companies are spending significant time and resources training their employees to adapt to these complexities.

Observing these trends led me to the following idea: while everyone is developing in their own way, creating a platform that defines specific cloud architecture templates and allows users to quickly and easily generate resources in their AWS Cloud environment according to these templates with minimal input could potentially save businesses considerable time and money spent on studying, understanding, and applying cloud architectures.

That idea gave birth to the Steve Web Service Console.

The Steve Web Service Console enables users to set up various architecture configurations needed for project deployment, starting from the initial setup of the first AWS architecture VPC to deploying various architecture configurations required for project deployment, with minimal input and button clicks.

Explore Steve Web Service AWS Cloud Quick Builder functionalities

Visit Steve Web Service Page for more information

When you first look at the images below,

We configure both Public and Private Subnets as shown above, and accordingly, set up Security Groups to allocate instance resources privately. However, this task requires a significant amount of learning, and for those who are not seasoned developers or cloud engineers, understanding and studying the structure of the cloud can be time-consuming and costly.

With the Steve Web Service Console, this configuration can be accomplished in just 5-10 minutes.

Moreover, the setup process is very simple. If you have set up the Steve Web Service Console and launched the SWS Console application web locally, simply enter the project name and click one button, as shown in the image below, and the resources will be generated according to the above architecture.

Isn't it remarkably easy? Although it may appear to impose certain constraints, the crucial aspect is that it saves time and effort spent on studying and manually configuring the resources needed to build the defined architecture. Steve Web Service continued to develop to provide such value.

Explore Steve Web Service AWS VPC Turn Key functionalities

Visit Steve Web Service Page for more information

So, I thought next. When we develop SPA projects, there are typically three main methods for deploying them to the AWS cloud:

Uploading to EC2 and running SPA projects directly using Nginx, Apache, or startup scripts.
Dockerizing SPA projects, uploading to ECR, deploying to ECS, and connecting to ELB.
Since SPA projects are ultimately static, exporting them via static web hosting on S3 and CloudFront.

Steve Web Service chose the third option, believing it to be cost-effective and efficient. We oriented the development towards this direction, naming the service Frontend DMS.

The idea was as follows:

Users only need to receive a zip file containing the build folder with bundle.js and index.html of the SPA project. From there, the SWS Console takes care of building the entire architecture.

To reach the CloudFront endpoint, there's a process involved, including uploading the SPA project's build files to S3, configuring static site hosting, and creating and connecting a CloudFront Distribution.

However, with the Steve Web Service Console, there's no need to study or ponder over this process anymore.

This is because the setup is completed with a simple flow as shown below.

How easy is it? Users no longer need to study; they can deploy and build SPA projects in the structure mentioned above.

Explore the Steve Web Service AWS Frontend DMS feature

Visit the Steve Web Service Page for more information

We didn't stop there; we also provided an option to re-upload to S3 and invalidate CloudFront simultaneously, as shown below.

As we continued to focus on problem-solving, reaching even CloudFront deployment, we pondered what the user might want at the end.

That's when domain connection and SSL configuration came to mind. At the end, domain access was essential for users, and although AWS Cloud provides this functionality, there was a lot to study. We believed that resolving this issue was crucial for the significance of this solution.

So, we thought: If users purchase a domain through AWS Route 53 service, the Steve Web Service Console can handle everything thereafter. Users only need to select the domain and enter the subdomain, and the connection is made.

In the above image, when you select a domain purchased through Route 53, and click the "Create SSL Certificate" button, the SSL certificate setup for that domain is completed.

Next, by receiving only the subdomain name from the user in step 6 and clicking the "Connect Domain" button, the connection to Route 53 with the corresponding subdomain is established via HTTPS.

Isn't it incredibly easy? Users can deploy projects to the cloud and export them to users without any knowledge of AWS Cloud.

We will continue to develop tools that help users build cloud architectures without the need for learning AWS Cloud, allowing developers to focus more on their business. Moreover, we aim to provide value so that even a small team of developers can utilize the maximum AWS resources possible.

The next article will delve into the history of solving different problems. End.

Visit the Steve Web Service Page for more information