DEV Community: Valentin Kuharic

Want to learn fast? Then "reinvent the wheel" all the time.

Valentin Kuharic — Wed, 23 Aug 2023 15:00:39 +0000

The job of a software developer can be summarized into two words: constantly evolving. Anti-static. The nature of software demands it since modern programs, apps, and websites require us to use a plethora of abstraction layers and tools that we can't always know how they really work. Each tool or layer we bring into our environment abstracts some part of the development process behind its API that we will then use. This is a normal process with the fantastic benefit of enabling the developer to create complex, stable, and beautiful applications and tools that would otherwise require whole teams of experts just a couple of years ago to construct. This phenomenon has a downside that we must be aware of, especially in the modern web world. So many processes and behaviors get abstracted that we begin to learn the APIs of those tools, not the programming itself.

Most of the newcomers to the world of software development begin their journey in the web world. The beginnings are rough and hard, and the front end is a great starting point since it provides visual feedback and is the most rewarding part for most people. After spending the humble beginning writing calculators, managing arrays with loops, or handling input and output to the console, the ability to create websites so quickly feels ground-breaking. Naturally, this progress leads a new developer to the UI libraries and frameworks of the modern day: React, Angular, and such.

We tend to forget how amazing these tools are and just how much they speed development up. A decent React developer can easily take a Figma design file and recreate the UI and interactivity without breaking a sweat. They help us handle the UI, updating state, routing, and more, and they introduce their APIs to do so. In a rush to get a job and start earning money, this makes new, fresh, and inexperienced developers rush to these tools, sparking the numerous "What is the best frontend framework to learn" debates.

This has the often forgotten consequence of new developers learning frameworks, not programming itself. They learn the APIs of their tools and how to use them, get a job, and then struggle to keep up with the more complex codebases. Writing UIs and connecting them with backends usually works well, but problems arise when the apps get complicated to the point where custom state management practices are required, reducing the number of requests to the backend should be tackled, or decoupling of the presentation layer from the other code needs to be done, or even rewriting the UI from one library to another. This inevitably brings challenges to the developer, where a clear lack of competence gets shown and the developer struggles to keep up. The pace of modern development doesn't help, making it hard to, between a full-time job and other parts of life, find enough time and energy to try to work on one's personal projects. It is my own opinion that most fresh developers struggle with this, myself included. It's a balancing act all of us need to manage.

Software is not easy, and between college and Udemy tutorials there is a lot of sweat, failed projects, and keystrokes needed to grasp the concepts and get stuff done. This brings me to the title of this post: reinvent the wheel. I constantly hear the advice "Stop going through tutorials, think of an idea, and start working on it", which is the best way to learn in my opinion. But there is an addition I'd like to recommend - start reinventing the wheel, which will further deepen your understanding of your codebase.

Maybe you're using the RxJs library to aid with state management in your front-end project. It's quite a complex library and takes some brain power to grasp the concepts and start using it well. Why not try and recreate its reactive primitives? It's easier than it seems, and the new-found intuition and understanding will reshape your thinking about RxJs. It's incredible how much this practice changes your perspective. They don't say "To fix it, you first need to know how it works" with no reason. Maybe you use Express for writing backend apps in Node. Have you ever wondered how the routes work? What's happening underneath the pretty syntax?

With the power of understanding the hidden layers comes the benefit of making fewer bugs, quicker debugging, and even the ability to modify some behavior otherwise inaccessible. If one has the time, I strongly recommend to try and tackle an unknown variable in your toolset, and by recreating just the most basic parts of it, you may come out a stronger engineer on the other side.

Shielding Your Instances with Private Subnets on AWS

Valentin Kuharic — Tue, 22 Aug 2023 10:00:05 +0000

📜 Table of contents

Building a Secure AWS Network: Protecting Instances with Private Subnets
- Table of contents
- 1. Introduction
- Disclaimer
- 2. Introduction to VPCs and deploying a basic instance
- 2.1. VPCs
- 2.2. CIDR blocks, subnets and security groups
  - 2.2.1. CIDR blocks
  - 2.2.2. Subnets
  - 2.2.3. Security groups
  - 2.2.4. Route tables
  - 2.2.5. Internet gateway
  - 2.2.6. DNS resolution
- 2.3. Setting up a basic deployment
  - 2.3.1. Creating the VPC
  - 2.3.2. Enabling DNS resolution
  - 2.3.3. Creating the subnets
  - 2.3.4. Making the subnets public (route tables and Internet gateways)
  - 2.3.3. Initial VPC setup
  - 2.3.2. Creating our managed backend application
  - 2.3.3. Creating our database instance
- 2.3.4. Basic deployment visualisation
- 3. Challenges of exposing instances to the Internet
- 3.1. Principle of least privilege
  - 3.1.1. Explanation
  - 3.1.2. Examples
- 4. Fixing the mistakes (new architecture)
- 4.1. Backend: Load-balancing the backend + NAT
  - 4.1.1. Approach
  - 4.1.2. Creating the subnets
  - 4.1.3. Creating and configuring the environment
  - 4.1.4. Backend design visualisation
- 4.2. Database: Protecting the database with a jump host + security group access rules
  - 4.2.1. Creating subnets
  - 4.2.2. Creating the database instance
  - 4.2.3. Creating the jump host
  - 4.2.4. Connecting to the database
  - 4.2.5. Configuring traffic rules
  - 4.2.5.1. Jump host security group
  - 4.2.5.2. Database instance security group
- 4.3. Final architecture visualisation
- 6. Conclusion

📝 1. Introduction

This post will cover various methods for enhancing security for AWS instances through the strategic use of public and private subnets. We'll explore the foundational concepts of Virtual Private Clouds (VPCs) and demonstrate how you can harness the capabilities of a VPC in conjunction with various network nodes to shield your systems from external threats. Later chapters will cover various scenarios, pinpointing potential challenges and their solutions in certain configurations.

Note that this article will focus exclusively on the communication channels between various network areas and nodes, as well as the rules governing interactions between the internet and the private network. Vulnerabilties stemming from the applications themselves or any other architectural issues will not be covered.

🤚 Disclaimer

This article will touch upon several advanced techniques in computer networking that readers should have a foundational understanding of to fully grasp the content. While we will provide explanation for most basic concepts and provide definitions, the reader should familiarize themselves with any new concepts they come across to fully understand the content.

Constructing your architecture incrementally often proves more efficient and less time-consuming than striving for a comprehensive build right from the get go.

2. Introduction to VPCs and deploying a basic instance

ℹ️ Note!
Basic knowledge of computer networks is required.

2.1. VPCs

VPC (Virtual Private Cloud) is a virutal private network you own via your AWS account. In contrast to real, physical machines, routers and switches it is virtually constructed, but the concepts remain the same.

VPCs can be thought of as real networks with the same features by which they provide a structured way to deploy your AWS instances. By default, a VPC is logically isolated from the Internet effectively functioning as a separate network.

The AWS network is a collection of Availability Zones, which are physically represented as data centers. They are interconnected and they form the AWS network. These AZs are then grouped into regions. When we put all this together, we can visually represent the different areas and overlaps like so:

Visualisation shows a sample AWS region composed of three AZs. Inside the regions we have our private VPC that's spanning across three AZs (we can configure our VPC to reach one or more AZs). Using the internet gateway we can enable communication with the Internet (more on this later).

2.2. CIDR blocks, subnets and security groups

2.2.1. CIDR blocks

The basic concept of computer networks is that each node in a network is assigned a unique address by which we recognize it as a node. Just as each house in our street has a house number, each node in a computer network has a so-called IP address.

Armed with that knowledge, we can represent the scope of our private network as a range of IP addresses. A good analogy would be that in a street we would assign numbers to houses from 20-44, so the same logic would apply to networks - a VPC has a range of IP addresses.

ℹ️ Note!
Basic knowledge of IP addresses is required. Use the following link to learn how IP addresses are comprised.

To keep things simple, we'll take only IPv4 addresses into account. Each IPv4 address consists of four 8 bit fields. Meaning the smallest address is 0.0.0.0 and the largest one is 255.255.255.255.

This separation of 4 distinct parts is very useful since we can easily subdivide our total IP range into sections. For example, we can say that some abstract distinct section of our network will have IP address range between 24.24.24.0 and 24.24.24.255. In this case the number of addresses this section has been assigned is 256 addresses.

We need a simple, formal way of representing these ranges. Our written example is fine, but we can condense this information into a structured, standardized format that computers can also read.

A CIDR block is a notation we can use to represent the IP ranges. Let's take a look at an example of a CIDR block:

$$25.25.25.0/24$$

denotes an IP range from 25.25.25.0 to 25.25.25.255.

The $/24$ suffix indicates the count of consecutive leading 1-bits (from left to right) in the network mask. This just means the number of bits that are fixed.

Finally, we can now define our private network space with a CIDR block that has 16 static bits. An example would be:

$$192.168.0.0/16$$

2.2.2. Subnets

So far we have defined our VPC range. Referencing the image of above of defining a sample VPC space, we can notice different "subnets" inside the VPC.

Subnets are a powerful concept of dividing our network into distinct parts. This is extremely useful since it helps us organize our nodes inside the network.

Let us consider an example where we have multiple database nodes and multiple application nodes in our network. We will assign each node in the network its own rules for accessing other parts of the network. As our network expands this would become exponentially more cumbersome and difficult to manage.

Subnets allow us to set and define these rules of communication and access to a specific range of our network; then all nodes inside the subnet will adhere to these rules. This greatly simplifies managing our nodes.

2.2.3. Security groups

In addition to subnets, another pivotal aspect of securing our AWS architecture is the implementation of Security Groups. While subnets manage network segmentation, security groups take on the role of controlling inbound and outbound traffic at the instance level. They act as virtual firewalls that regulate the traffic allowed to and from instances associated with them.

Security groups operate based on rules that explicitly permit or deny specific traffic flows. These rules can be defined in terms of allowed IP addresses, port ranges, and protocols. Unlike network access control lists (ACLs), which operate at the subnet level, security groups are associated with individual instances.

By configuring security groups, you can create a strong defense mechanism to safeguard your instances from unauthorized access and potential security breaches. As you continue to explore the intricacies of AWS security, a comprehensive understanding of both subnets and security groups will be instrumental in designing a well-protected and robust environment for your applications.

At this point we have introduced the vital tools of controlling network ranges and assigning communication rules to those sub-ranges (subnets) and to the individual nodes themselves. Later we will apply these concepts on real world examples to see how to effectively use them to create a secure network.

2.2.4. Route tables

In the vast networking landscape of AWS, route tables play a central role in directing traffic flow. They contain a set of rules, called routes, that determine how traffic is forwarded between subnets, the internet, and other connected networks.

Each subnet in a VPC must be associated with a route table, which dictates the traffic routing for the subnet. A VPC is created with a main route table by default, but additional custom route tables can also be created. When a subnet doesn't have an explicitly associated route table, it falls back to the main route table.

Configuring the route table accurately ensures that your network's traffic reaches its intended destination efficiently. For instance, if you want a subnet to communicate with the internet, you would modify the route table associated with that subnet to include a route to an internet gateway.

2.2.5. Internet gateway

An Internet Gateway serves as a critical bridge, enabling communication between resources in your VPC and the internet. It offers a two-way portal: it allows the internet to access your instances (when permitted) and lets your instances access the internet.

To facilitate this connectivity, you must attach an Internet Gateway to your VPC and then configure the appropriate route in the associated route table. With this setup, EC2 instances in your VPC can directly communicate with the internet, as long as they have an Elastic IP or Public IP.

Remember, while the Internet Gateway paves the way for internet connectivity, the actual accessibility is governed by security groups and network ACLs, ensuring a layered approach to security.

2.2.6. DNS resolution

The Domain Name System (DNS) translates user-friendly domain names (e.g., "www.example.com") into IP addresses that machines understand. Within a VPC in AWS, DNS resolution is automatically enabled, allowing instances to resolve domain names to their corresponding IP addresses. When EC2 instances are launched, they are assigned both private and public DNS hostnames, provided they're in a subnet set to assign public IPs. Keeping DNS resolution and hostnames enabled in a VPC is crucial for many applications, especially those dependent on DNS for communication.

🚨 Warning!
We have covered these concepts on a high-level and their implementation in a real AWS network are more complicated and introduce various little rules of application. In the later chapters we will create a real deployment and we will cover some of these, but I strongly recommend that you try to create these rules yourself. Be aware that full network configuration contains more rules and concepts.

2.3. Setting up a basic deployment

Let's create a simple deployment containing a database and a backend application.

2.3.1. Creating the VPC

We'll ignore the default VPC and create our own. We'll set our CIDR block as 24.24.0.0/24 as shown on the image below.

2.3.2. Enabling DNS resolution

Enable DNS resolution and DNS hostnames in the VPC settings.

2.3.3. Creating the subnets

After creating the VPC we'll create just one public subnet where our instances will live. We'll use CIDR block 24.24.1.0/24.

2.3.4. Making the subnets public (route tables and Internet gateways)

By default, all created subnets are private since they don't have access to the Internet. This is due to the default route table, which sets the communication rules for the subnet.

Firstly, let's create an Internet Gateway and assign it to our VPC.

Now our VPC has access to traffic from the Internet.

Create a new route table. We will associate this route table with the subnets we want to make public, so let's set the ruleset to the following traffic rules:

Access to all space inside VPC
Access to the internet gateway

Now the nodes inside the subnet can access traffic from the Internet.

2.3.3. Initial VPC setup

So far, we have the following configuration:

2.3.2. Creating our managed backend application

Let's create our managed backend instances. The node itself that will live in our VPC is a Linux EC2 instance, but we will use Elastic Beanstalk service to manage our instances.

ℹ️ Note!
Elastic Beanstalk is an AWS service for managing and configuring various other AWS services, mainly used to orchestrate Linux machines. Learn more about it here.

Select the prefered platform, in this case Node will be used.

We'll configure it to deploy our instances inside our public subnet. Make sure to select the proper VPC and subnet. Since we'll directly serve traffic to our instance, make sure to check the Public IP address box to assign a public IP to our instance.

After finishing the configuration wizard, Elastic Beanstalk will spin up and configure our instances. Find the URL in the environment details screen to access the application.

This is how the web page should look like:

🚨 Warning!
You may possibly encounter an issue while deploying the environment with misconfigured service roles. Take a look at this link for more information. Dont forget to select the instance profile!

2.3.3. Creating our database instance

To demonstrate a basic deployment of a database, we will deploy an instance running a relational database software. AWS provides a service for doing exactly that, called RDS (Relational Database Service). RDS wizard requires that RDS instances live in a subnet spread across two availability zones. Specifically we're required to create a subnet group.

So far we have created only one public subnet. Navigate to the VPC service and create another public subnet. Make sure it's placed in a different AZ compared to the first public subnet! Now that we have two public subnets in different AZs, navigate to RDS service and create a database subnet group that includes these two subnets.

🚨 Warning!
Remember to assign the correct route table to the subnet, otherwise no traffic from the Internet can pass through to the instance.

Now we're ready to finally create the database instance. Navigate to the RDS service and launch the instance creation wizard. Make sure to properly configure the connectivity settings, including the correct VPC and subnet group. Make sure to enable Public access.

ℹ️ Note!
For testing purposes I recommend using the free tier preset for instance class and storage.

2.3.4. Basic deployment visualisation

So far, we have created the following configuration:

3. Challenges of exposing instances to the Internet

Our current deployment is valid and works. But when we're designing a system for a production application we must always take security into account. With enough traffic we will eventually encounter malicious users and minimizing potential security risks is a must.

3.1. Principle of least privilege

3.1.1. Explanation

The Principle of Least Privilege (PoLP) dictates that in a computing environment, all nodes, modules, processes, users, or programs should have access only to the precise information required to execute their tasks. By confining privileges and access rights, we inherently limit the potential vulnerabilities of our system. This is a very powerful concept for minimizing possible attack surfaces our system design might leave open.

Imagine a network comprising several nodes. If an attacker compromises one node, the extent of their reach largely depends on the privileges associated with that node. Considering the principle of least privilege and applying it to our network, the intruder's access is limited, since they can potentially access only a minimal amount of information. This contrasts with a scenario where nodes have unrestricted access, granting the attacker access to the entirety of our network.

This idea can be taken as far as you want; for instance, you can specify rules for read-only or write-only actions.

3.1.2. Examples

User Accounts on Operating Systems: On most operating systems, there are user accounts with varying privileges. Typically, there are administrator accounts with full system access and standard user accounts with limited access. If a standard user account is compromised, the attacker can't make system-wide changes. This limitation is due to the PoLP; the standard account only has the necessary privileges to run applications and not to modify system settings.

Database Management: In a database system, not all users need the ability to edit or delete tables. Some might only require read-only access, while others might need more comprehensive permissions for data entry. By tailoring access to individual roles, you can ensure that even if a read-only account gets compromised, the attacker cannot alter the database's data or structure.

Web Applications: Consider a web application where users can view, post, and edit content. While every user can view posts, perhaps only the original poster can edit or delete their own content. Implementing the PoLP ensures that even if a user's session is hijacked, the malicious actor can only affect the content associated with that specific user and not content from other users.

4. Fixing the mistakes (new architecture)

So far we have created a working deployment and we have explained the security risks associated with it. Now we'll introduce new concepts in computer networking and apply them to create a secure environment for our applications. We will be sticking to an example of an application deployment and a database deployment.

4.1. Backend: Load-balancing the backend + NAT

4.1.1. Approach

Our current deployment consists of a Linux machine with a public IP, directly accessible from the internet. We aim to enhance its security by placing it within a private network. Instead of direct access, we'll introduce a gatekeeper - in our case, a load balancer - that mediates communication between the internet and our private machine.

We'll set up an Elastic Beanstalk environment to launch machines in a private subnet running our sample Node application. Through the configuration settings, we'll ensure the environment is load-balanced, with the load balancer situated in a public subnet. This setup allows the load balancer to be the public entry point, directing traffic to our private infrastructure. Although the EC2 instances are in a private subnet, they still need internet access for updates. To accommodate this, we'll associate them with a NAT gateway in the private subnet, allowing only incoming traffic.

🔥 Tip
Learn more about load balancers here.

🔥 Tip
Learn more about NAT gateways and how they work here.

4.1.2. Creating the subnets

To create our architecture, we need two public subnets for our load balancer. Create two appropriately names public subnets with the method shown in this article. We will also need one private subnet for our application EC2 instances, so create one private subnet.

Create a NAT gateway and add it to the private subnet.

4.1.3. Creating and configuring the environment

Once the subnets are ready to go, navigate to Elastic Beanstalk and launch the environment creation wizard. Choose the environment name and configure the environment:

Choose a sample Node app as the desired platform
In the networking settings:
1. Choose your VPC
2. Choose the desired private subnet
3. Choose the appropriate security group
In the Instance traffic and scaling:
1. Choose the environment type as load balanced
2. Set the load balancer as public
3. Select the load balancer public subnets created earlier

The Elastic Beanstalk wizard will do the rest. After a successfull launch, the application should be accessible via the EB public URL.

ℹ️ Note!
The mentioned configuration may take a substantial time to launch (10 minutes or more). Be patient.

4.1.4. Backend design visualisation

4.2. Database: Protecting the database with a jump host + security group access rules

4.2.1. Creating subnets

Firstly, let's create the private subnets for the database. We need at least two. In this case we'll them private-db-subnet-1 and private-db-subnet-2 and assign IPv4 CIDR blocks of $24.24.2.0/24$ and $24.24.3.0/24$.

🚨 Warning!
Make sure the subnets have different Availability zones.

Then create the subnet group for the new database instance, consisting of these two subnets.

We'll need a public instance for our jump host, which we'll cover shortly. Create a public instance following the method shown earlier. Consider naming it appropriately, in this case we'll choose the name public-db-jump-host-subnet-1.

4.2.2. Creating the database instance

Create an RDS instance in your VPC and set the correct subnet group. At this point, the RDS instance will launch but it won't be accessible since it lives in private subnet space. We will make it accessible from the Internet via a jump host.

4.2.3. Creating the jump host

ℹ️ Note!
A jump host configuration is not an ideal approach, but it's a great learning example to grasp different traffic rules and the idea of protecting network instances. It is a potential point of vulnerability as it's exposed to the internet. It's crucial to harden its security, apply timely patches, and follow best practices to minimize risks.

A jump host (or bastion host) is a special-purpose node (computer, virtual machine) in a computer network configured to withstand attacks and act as a gateway to access resources inside a private network from the external world.

In this context, we'll utilize the jump host as a bridge to connect to our RDS instance situated in a private subnet.

We'll configure our jump host as a Linux machine using the EC2 service. We'll launch a simple EC2 instance in the public subnet, exposed to the Internet. By configuring the SSH keys an outside user will be able to securely connect to a public node in our network, from which they'll be able to access protected nodes.

ℹ️ Note!
Basic knowledge of SSH cryptographic protocol is required. Learn the basics here.

Let's create a Linux machine with EC2.

Choose instance name
Use Amazon Linux 2023 64-bit image or newer
Choose t3.micro instance type (free tier eligible)
Create a new key pair for login (by creating a new pair, the browser will prompt you to download the key)
Configure the network settings
1. Select your VPC
2. Select the jump host public subnet as the desired subnet
3. Set Auto-assign public IP to Enable
4. Make sure the wizard assigns a new security group tp the instance by selecting the option Create security group
5. Make sure the inbound security group rules allow SSH traffic on port 22 from anywhere (more on this later)
Submit the form

Now the EC2 instance should boot up within a couple of minutes.

4.2.4. Connecting to the database

Now our jump host and database should be properly configured for the outside user to gain access via the secure node. To connect to the database the user can SSH into the secure node like so:

ssh ec2-user@<MACHINE IP ADDRESS> -i <PATH_TO_PRIVATE_KEY>

with the desired output:

   ,     #_
   ~\_  ####_        Amazon Linux 2023
  ~~  \_#####\
  ~~     \###|
  ~~       \#/ ___   https://aws.amazon.com/linux/amazon-linux-2023
   ~~       V~' '->
    ~~~         /
      ~~._.   _/
         _/ _/
       _/m/'
Last login: Mon Aug 21 12:54:33 2023 from <REMOTE USER IP>
[ec2-user@ip-<VPC PRIVATE NETWORK IP> ~]$

This confirms correct configuration of the jump host.

🔥 Tip
For .pem files used for SSH access, you should set the permissions to be read-only by the owner. This ensures that the private key remains confidential and isn't accidentally modified.

You can set the correct permissions using the `chmod` command:

```
chmod 400 /path/to/your_key.pem
```

To securely access a database on a remote machine without exposing it directly, we can create an SSH tunnel. This technique involves forwarding a local port on your machine to a port on the remote database server, essentially making the database accessible as if it were running locally.

The command for setting up this SSH tunnel is:

ssh -L _LOCAL_PORT_:_REMOTE_DATABASE_HOST_:_REMOTE_DATABASE_PORT_ _JUMP_HOST_USERNAME_@_JUMP_HOST_PUBLIC_IP_ -i _PATH_TO_PRIVATE_KEY_

LOCAL_PORT: A free port on your local machine.
REMOTE_DATABASE_HOST: The hostname or IP address where the database resides.
REMOTE_DATABASE_PORT: The port the database listens to.
JUMP_HOST_USERNAME: Username associated with the jump (or bastion) host.
JUMP_HOST_PUBLIC_IP: The jump host's public IP address.
PATH_TO_PRIVATE_KEY: Directory path to the SSH private key for authentication.

After setting up the SSH tunnel, connect to the database using your desired database tool or API as if it's on your local machine. Access it at localhost:_LOCAL_PORT_.

4.2.5. Configuring traffic rules

We have demonstrated how to protect a private database instance by not exposing it to the Internet directly, but rather provide access via a jump host. This is a huge improvement from the original design but there is still room to improve. We will be specfically focusing on security group rules for the jump host and the database to futher comply with the Principle of least privilege.

4.2.5.1. Jump host security group

Let's navigate to EC2, select the jump host, and review its security group.

So far, the jump host listens only for SSH traffic, which is the desired behavior. The potential security risk is that any user, from anywhere in the world, can attempt to connect to the jump host, denoted by the $0.0.0.0/0$ source rule. While SSH itself is secure, limiting the source addresses can significantly reduce the risk of brute-force attacks. Our current outbound rules allow an attacker to potentially reach other parts of the network.

For inbound rules:

Limit Source: Tighten the inbound rules by allowing only trusted IP addresses, such as your company's VPN, specific employee IP addresses, or other controlled networks. This minimizes the exposure to potential attackers by narrowing down the list of IPs that can initiate a connection.

For outbound rules:

Limit Destination: Outbound traffic from the jump host should be restricted to the necessary destinations. Specifically, it should be able to communicate only with the private IP address of the database instance and any other essential services. This configuration ensures that even if the jump host is compromised, the attacker can't use it as a platform to target other unrelated resources or systems.
Specify Port: While the jump host primarily serves as a bridge to the database, ensure that it's only allowed to communicate on the specific port your database listens on. This minimizes potential misuse of the jump host.

4.2.5.2. Database instance security group

Let's navigate to RDS, select our database instance, and review its associated security group rules:

For inbound rules:

Limit Source: By default, avoid having a wide-open $0.0.0.0/0 source rule. Instead, only allow inbound traffic from trusted sources. The primary source should be the jump host's private IP, ensuring direct connectivity only through the jump host. Depending on your setup, you might also consider connections from other essential components or services. Specify Port: Ensure that only the specific port your database is listening on is open. This further reduces potential vulnerabilities.

For outbound rules:

Limit Destination: Your database instance should have a limited scope for outbound connections. It's best to only allow the necessary communication, which might include connecting to specific services or updates. Restricting the outbound traffic ensures that data can't be unexpectedly exfiltrated.
No Wildcard Rules: Avoid using wildcard rules that allow the database to connect to any IP on any port. Remember, you want to ensure that if your database were ever compromised, its potential to do harm is restricted.

4.3. Final architecture visualisation

👏 6. Conclusion

Securing cloud deployments is an intricate task that requires methodical planning and execution. Throughout this guide, we've taken a dive into some foundational steps for improving the security of AWS Elastic Beanstalk and RDS instances. By placing our EB instances in private subnets, harnessing load balancers in publicly accessible spaces, and adding an additional layer of protection to our RDS databases with a jump host, we've made significant strides in fortifying cloud deployments on AWS.

However, it's essential to understand that this is merely an introductory guide. Real-world production environments often demand a myriad of additional techniques, strategies, and concepts to ensure comprehensive protection such as firewall configurations, intrusion detection systems, monitoring and incident response mechanisms.

Also check out my website for more here! Feel free to reach out for more info, suggestions and collaborations.

Kamiq - a Typescript, lightweight, Nest-like, batteries-included web framework

Valentin Kuharic — Thu, 10 Aug 2023 15:42:32 +0000

Table of contents
1. Prelude
Disclaimer
2. Enough intro - show me the code.
2.1. Configuring the server
2.2. Example
2.3. Controllers and routes
- 2.3.1. Controllers
- 3.3.2. Routes
- 2.3.3. Parameters
- 2.3.4. Middlewares
- 2.3.5. Gaurds
2.4. Error handling
- 2.5. Operations
- 2.6. Kamiq errors
3. Here's the repo
4. There is a lot more to do
5. Outro

1. Prelude

On my last job, I was handling a project consisting of a legacy backend + frontend codebase where I was constantly refactoring code - it was either unusable, totally unreadable, or both. To make things even worse, the backend was lacking any structure or goal - it was just code thrown around that somehow managed to work most of the time. In the midst of all the refactoring I found myself slowly adding some architectural elements to the codebase, since it was the only way any new code addition could be maintained later. The codebase didn't even separate the controller logic from service logic!

With time, things started to take shape, and all my architectural additions helped made the codebase kind of usable. Since moving away from Express wasn't a choice at the time, but numerous new features constantly asked for some new abstractions and design patterns just to keep things organized, I slowly found myself with a backend project that I tailored to my kind of thinking.

In the meantime, I left that job but all those concepts stuck with me, so as a learning project I decided to wrap them in a standalone package that can be used cleanly and simply. I never wrote a package before, but I thought this would be a short, fun and productive endeavour. Here I am sharing it with the world so we can discuss, learn and figure out what makes a good framework together. With that, I present to you: Kamiq!

⚠️ Disclaimer

Before you dive in:

In this post I'll be talking about a personal learning project I've been working on. Expect a half-baked but interesting project and a discussion on what makes a fun to use web framework.

2. Enough intro - show me the code.

Short description first:

Kamiq is a TypeScript framework for building server-side applications with heavy decorator usage. It combines object-oriented and functional programming approaches to achieve it's minimal syntax design. Kamiq is built on top of Express.js and by design offers high interoperability with Express, enabling the user to easily port over their existing Express.js code including routes, middlewares and more.

I'm not treating this project as something I'd like to push through to being complete or production ready - it's merely a learning project and a discussion on node web frameworks in a codebase format. I'm always open to learning new stuff and one of the best ways to learn is to reinvent the wheel, which is what I'm doing here.

The following script covers the most important parts of the project and doesn't cover more specific features and possibilities. Check out the full README on the Github repository (link at the end).

Right, let's get to it.

2.1. Configuring the server

To configure your server, instantiate an object from the Server class. Use the public functions to set your configuration object and any other properties.

import "reflect-metadata";
import { Server } from "kamiq";
import { DefaultErrorHandler, DefaultRequestLogger } from "kamiq/middlewares";

import { SampleController } from "./controllers/sampleController";

const server = new Server();

server.setPort(8001);
server.useJsonBodyParser(true);
server.useController(SampleController);
server.useCors(true);
server.setGlobalRequestLogger(new DefaultRequestLogger());
server.setGlobalErrorHandler(new DefaultErrorHandler(true));

server.start();

2.2. Example

Here's an example of how a controller looks like:

import { BaseController } from "kamiq";
import { Middleware, Post, Req, Res } from "kamiq/decorators";
import { MySampleMiddleware } from "../middlewares/sampleMiddleware.middleware";
import { MySampleMiddleware2 } from "../middlewares/sampleMiddleware2.middleware";

export class SampleController extends BaseController {
  path = "/users"; // Base path for the following routes.

  @Guard(new AgencyAuthorizer(), {
    ignore: true, // Optional way to ignore a guard (or middleware)
  }) // Guards
  @Middleware(new LogSignInEvent("user")) // Middlewares
  @Post("/siginin") // Get controller registeres the route with a GET method and handles errors
  signIn(
    @Req() req: Request,
    @Res() res: Response,
    @Body() body: IUserSignIn,
    @Param("userId") userId: string
  ) {
    const { password } = body;

    const signIn = AuthService.signIn(userId, password); // Kamiq operation

    if (signIn.error) throw new AuthorizationError(signIn.error); // Picked up by global err handling middleware

    res.json({ msg: "success" });
  }
}

Now let's brake it down:

2.3. Controllers and routes

2.3.1. Controllers

Controllers are classes that extend the BaseController class. In each controller class you provide the path property - a route prefix for all routes defined in the class.

3.3.2. Routes

Each route is a function with the name of your choosing to which a decorator is attached with the HTTP method name: @Get() for a GET method, @Post() for POST etc. An HTTP decorator combined with a handler function forms a route. HTTP method decorators take in a string argument that is the route specific suffix. Note that this also supports dynamic routes by adding parameters to the route, as shown above in the example with :userId.

2.3.3. Parameters

The route handler itself supports multiple decorators that you can inject to get access to various properties of the request lifecycle. Since Kamiq uses Express.js to process HTTP requests, you can inject Express Request and Response objects into the hander like shown above with the @Req() and @Res() decorators. Also, you have access to @Body, @Query(), @Param(), which extract some specific data from the request as shown above.

2.3.4. Middlewares

Kamiq also supports middlewares, which you can attach to routes by using the @Middleware decorator. Middlewares are classes that extend the KamiqMiddleware interface, which is very similar to Nest's interface where the use() function is really just a vanilla Express.js middleware function.

This also has a nice side-effect where middleware functions can be passed arguments which can alter their behaviour. Consider the middleware as shown:

export class MySampleMiddleware implements KamiqMiddleware {
    private readonly someValue: boolean;

    constructor(someValue: boolean) {
        this.someValue = someValue;
      }

    async use(req: Request, res: Response, next: NextFunction): Promise<void> {

        // Can use someValue to change behavior...

        next()
    }
}

    // Route
    @Middleware(new MySampleMiddleware(false))
    @Middleware(new MySampleMiddleware2())
    @Post('/users')
    createUser(@Req() req: Request, @Res() res: Response) {

        // @ts-ignore

        res.send('user created.')
    }

Note that if a route has multiple middlewares attached, the order of execution is respected.

Middlewares also accept a second argument, an options object where you can specify middleware execution instructions like the ability to bypass execution while testing with the ignore property.

2.3.5. Guards

Guards are special type of middlewares that follow the rule of single responsibility by only handlding authorization and authentication logic. They implement an interface similar to the middleware interface but they return a boolean value, corresponds to a successful or a failed operation, where a successful one means the request proceeds to the next middleware in it's lifecycle and a failure results in an authentication error (or a custom error you can define).

2.4. Error handling

Error handling in routes is hidden in how they are registered on server start. When routes are being registered they are wrapped in an requestErrorHandler middleware which wraps the route handler in a try/catch block. This ensures any error being thrown, by the application or the user, will be caught.

Catching errors is now taken care of, but we still need to handle them. Kamiq offers a public function you can access on the server object called setGlobalErrorHandler which takes in a class that implements the KamiqErrorMiddleware interface. This is a wrapper for an express error middleware that you can pass to the function which will register the middleware and process all caught errors.
Kamiq provides a default defaultErrorHandler middleware you can use - or of course, you can easily write your own.

A BaseError class is included in the package that extends the Node's Error, making it trivial to write your own custom errors. Simply extend the BaseError class, add your own logic and due to the fact that all route handlers are wrapped in a try/catch block, simply throw your custom error anywhere in the handlers:

@Get('/test')
ping(@Res() res: Response) {

        throw new CustomAuthError("my error message!")

        res.send('success')
    }

and Kamiq will handle everything for you.

2.5. Operations

Operations are a special function type that aide with inter-layer communication within your codebase. Let's consider a simple backend architecture, consisting of three layers: presentation, service and data-access layer.

Errors should be handled at the controller level, making communication between the layers troublesome, considering any logic may error. This also raises the question of how to handle user-invoked errors at sub-controller levels.

Any general function can be an Operation by attaching the Operation() decorator to it.

Operation functions are general functions that are wrapped in a try/catch block and have an OperationResult return type:

export type OperationResult<T> =
  | { success: true; data: T }
  | { success: false; error: Error };

This ensures any Operation function will return an object with the success property set to true if the operation was successful, together with the data property. In case of failure, success will be false, and the error property will be returned, making it very simple for the receiver of the result to conditionally handle errors:

// Operation function

class MyService {
  @Operation
  static myOperationFunction() {
    throw new Error("oops!");
  }
}

// Operation receiver
function mockControllerFunction() {
  const operationResult = MyService.myOperationFunction();

  // handling the result:
  if (operationResult.error) {
    // handle error case (throw the error and it will be caught)
  }

  const result = operationResult.success;
  // continue...
}

Tip: Combine service level functions as Operations with the controller-level error handling to create bulletproof controller-service logic.

2.6. Kamiq errors

Kamiq offers descriptive, prettified framework-level error handling. If you make any configuration or definition errors at the framework level, Kamiq will throw it's custom error to help you resolve the problem. Here's an example of such error being thrown, invoked due to a misconfigured port variable:

InvalidArgumentError: 
   ┌ Kamiq encountered an error! ────────────────────────────────────────────┐
   │                                                                         │
   │                                                                         │
   │   InvalidArgumentError:                                                 │
   │   Port must be a number between 1 and 65535. Provided port is 5236203   │
   │                                                                         │
   │   Suggestion: Please check your server configuration.                   │
   │                                                                         │
   │                                                                         │
   │                                                                         │
   └─────────────────────────────────────────────────────────────────────────┘

there's only a few of such errors as of now, but more checks can be easily added.

3. Here's the repo

You can visit the repository here, or visit the npm page here.

4. There is a lot more to do

It ain't much, but it's honest work, right?

There's a lot of features I'd like to add, and many bugs I'd like to fix. Many important functionalities are missing, such as:

Handling cookies
Handling content types
File uploading and management
Monitoring
Input validation and sanitization
Rendering templates
Sessions

and more.

5. Outro

Thank you for reading this through. I'd like to hear your opinion on this project and can't wait to learn from your ideas and discussions. Check out the repository and feel free to voice your opinions. I know there's plenty wrong I did, but improving it is why I'm sharing this in the first place. Enjoy!

Cover image by Trina Snow (reinventing the wheel, get it?)

Beginner-friendy guide to error handling in TypeScript, Node.js, Express.js API design

Valentin Kuharic — Tue, 21 Dec 2021 22:10:37 +0000

1. Introduction to the topic

1.1. Overview

Error handling is pain. You can get pretty far without handling errors correctly, but the bigger the application, the bigger the problems you’re going to face. To really take your API building to the next level, you should tackle the challenge head-on. Error handling is a broad subject, and it can be done in many ways, depending on the application, technologies and more. It’s one of those things that are easy to understand, but hard to fully grasp.

1.2. What we’ll be doing

In this article, we’re going to explain a beginner-friendly way of handling errors in Node.js + Express.js API with TypeScript. We are going to explain what an error is, different types of errors that can crop up and how to handle them in our application. Here are some of the things we’ll be doing in the next chapters:

learning what “error handling” really is and the types of errors that you’ll encounter
learning about the Node.js Error object and how can we use it
learning how to create custom error classes and how they can help us develop better APIs and Node applications
learning about Express middleware and how to use them to handle our errors
learning how to structure the error information and present it to the consumer and developer

1.3. Prerequisites

DISCLAMER! This article assumes you already know some stuff. Even though this is beginner-friendly, here’s what you should know to get the most out of this article:

working knowledge of Node.js
working knowledge of Express.js (routes, middleware and such)
basics of TypeScript (and classes!)
basics of how an API works and is written using Express.js

Okay. We can begin.

2. What is error handling and why do you need it?

So what exactly is “error handling” really?

Error handling (or exception handling) is the process of responding to the occurrence of errors (anomalous/unwanted behaviour) during the execution of a program.

Why do we need error handling?

Because we want to make bug fixing less painful. It also helps us write cleaner code since all error handling code is centralized, instead of handling errors wherever we think they might crop up. In the end - the code is more organized, you repeat yourself less and it reduces development and maintenance time.

3. Types of errors

There are two main types of errors that we need to differentiate and handle accordingly.

3.1. Operational Errors

Operational errors represent runtime problems. They are not necessarily “bugs”, but are external circumstances that can disrupt the flow of program execution. Even though they're not errors in your code, these situations can (and inevitably will) happen and they need to be handled. Here are some examples:

An API request fails for some reason (e.g., the server is down or the rate limit is exceeded)
A database connection cannot be established
The user sends invalid input data
system ran out of memory

3.2. Programmer errors

Programmer errors are the real “bugs” and so, they represent issues in the code itself. As mistakes in the syntax or logic of the program, they can be only resolved by changing the source code. Here are some examples of programmer errors:

Trying to read a property on an object that is not defined
passing incorrect parameters in a function
not catching a rejected promise

4. What is a Node error?

Node.js has a built-in object called Error that we will use as our base to throw errors. When thrown, it has a set of information that will tell us where the error happened, the type of error and what is the problem. The Node.js documentation has a more in-depth explanation.

We can create an error like this:

const error = new Error('Error message');

Okay, so we gave it a string parameter which will be the error message. But what else does this Error have? Since we’re using typescript, we can check its definition, which will lead us to a typescript interface:

interface Error {
    name: string;
    message: string;
    stack?: string;
}

Name and message are self-explanatory, while stack contains the name, message and a string describing the point in the code at which the Error was instantiated. This stack is actually a series of stack frames (learn more about it here). Each frame describes a call site within the code that lead to the error being generated. We can console.log() the stack,

console.log(error.stack)

and see what it can tell us. Here’s an example of an error we get when passing a string as an argument to the JSON.parse() function (which will fail, since JSON.parse() only takes in JSON data in a string format):

As we can see, this error is of type SyntaxError, with the message “Unexpected token A in JSON at position 0”. Underneath, we can see the stack frames. This is valuable information we as a developer can use to debug our code and figure out where the problem is - and fix it.

5. Writing custom error classes

5.1. Custom error classes

As I mentioned before, we can use the built-in Error object, as it gives us valuable information.

However, when writing our API we often need to give our developers and consumers of the API a bit more information, so we can make their (and our) life easier.

To do that, we can write a class that will extend the Error class with a bit more data.

class BaseError extends Error {
  statusCode: number;

  constructor(statusCode: number, message: string) {
    super(message);

    Object.setPrototypeOf(this, new.target.prototype);
    this.name = Error.name;
    this.statusCode = statusCode;
    Error.captureStackTrace(this);
  }
}

Here we’re creating a BaseError class that extends the Error class. The object takes a statusCode (HTTP status code we will return to the user) and a message (error message, just like when creating Node’s built-in Error object).

Now we can use the BaseError instead of Node’s Error class to add the HTTP status code.

// Import the class
import { BaseError } from '../utils/error';

const extendedError = new BaseError(400, 'message');

We will use this BaseError class as our base for all our custom errors.

Now we can use the BaseError class to extend it and create all our custom errors. These depend on our application needs. For example, if we’re going to have authentication endpoints in our API, we can extend the BaseError class and create an AuthenticationError class like this:

class AuthenticationError extends BaseError {}

It will use the same constructor as our BaseError, but once we use it in our code it will make reading and debugging code much easier.

Now that we know how to extend the Error object, we can go a step further.

A common error we might need is a “not found” error. Let’s say we have an endpoint where the user specifies a product ID and we try to fetch it from a database. In case we get no results back for that ID, we want to tell the user that the product was not found.

Since we’re probably going to use the same logic for more than just Products (for example Users, Carts, Locations), let’s make this error reusable.

Let’s extend the BaseError class but now, let’s make the status code default to 404 and put a “property” argument in the constructor:

class NotFoundError extends BaseError {
  propertyName: string;

  constructor(propertyName: string) {
    super(404, `Property '${propertyName}' not found.`);

    this.propertyName = propertyName;
  }
}

Now when using the NotFoundError class, we can just give it the property name, and the object will construct the full message for us (statusCode will default to 404 as you can see from the code).

// This is how we can use the error
const notFoundError = new NotFoundError('Product');

And this is how it looks when it’s thrown:

Now we can create different errors that suit our needs. Some of the most common examples for an API would be:

ValidationError (errors you can use when handling incoming user data)
DatabaseError (errors you can use to inform the user that there’s a problem with communicating with the database)
AuthenticationError (error you can use to signal to the user there’s an authentication error)

5.2. Going a step further

Armed with this knowledge, you can go a step further. Depending on your needs, you can add an errorCode to the BaseError class, and then use it in some of your custom error classes to make the errors more readable to the consumer.

For example, you can use the error codes in the AuthenticationError to tell the consumer the type of auth error. A01 can mean the user is not verified, while A02 can mean that the reset password link has expired.

Think about your application’s needs, and try to make it as simple as possible.

5.3. Creating and catching errors in controllers

Now let’s take a look at a sample controller (route function) in Express.js

const sampleController = (req: Request, res: Response, next: NextFunction) => {

  res.status(200).json({
    response: 'successfull',
    data: {
      answer: 42
    }
  });
};

Let’s try to use our custom error class NotFoundError. Let’s use the next() function to pass our custom error object to the next middleware function that will catch the error and take care of it (don’t worry about it, I’ll explain how to catch errors in a minute).

const sampleController = async (req: Request, res: Response, next: NextFunction) => {

    return next(new NotFoundError('Product'))

  res.status(200).json({
    response: 'successfull',
    data: {
      answer: 42
    }
  });
};

This will successfully stop the execution of this function and pass the error to the next middleware function. So, this is it?

Not quite. We still need to handle errors we don’t handle through our custom errors.

5.4. Unhandled mistakes

For example, let’s say you write a piece of code that passes all syntax checks, but will throw an error at runtime. These mistakes can happen, and they will. How do we handle them?

Let’s say you want to use the JSON.parse() function. This function takes in JSON data formated as a string, but you give it a random string. Giving this promise-based function a string will cause it to throw an error! If not handled, it will throw an UnhandledPromiseRejectionWarning error.

Well, just wrap your code inside a try/catch block, and pass any errors down the middleware line using next() (again, I will explain this soon)!

And this really will work. This is not a bad practice, since all errors resulting from promise-based code will be caught inside the .catch() block. This has a downside though, and it’s the fact that your controller files will be full of repeated try/catch blocks, and we don’t want to repeat ourselves. Luckily, we do have another ace up our sleeve.

5.5. handleAsync wrapper

Since we don’t want to write our try/catch blocks in every controller (route function), we can write a middleware function that does that once, and then apply it on every controller.

Here’s how it looks:

const asyncHandler = (fn: any) => (req: Request, res: Response, next: NextFunction) => Promise.resolve(fn(req, res, next)).catch(next);

It may look complicated at first, but it’s just a middleware function that acts as a try/catch block with next(err) inside the catch(). Now, we can just wrap it around our controllers and that’s it!

const sampleController = asyncHandler(async (req: Request, res: Response, next: NextFunction) => {
  JSON.parse('A string');

  res.status(200).json({
    response: 'successfull',
    data: {
      something: 2
    }
  });
});

Now, if the same error is thrown, we won’t get an UnhandledPromiseRejectionWarning, instead, our error handling code will successfully respond and log the error (once we finish writing it, of course. Here’s how it will look like):

6. How do I handle errors?

Okay, we learned how to create errors. Now what?

Now we need to figure out how to actually handle them.

6.1. Express middlewares

An express application is essentially a series of middleware function calls. A middleware function has access to the request object, the response object, and the next middleware function.

Express with route each incoming request through these middlewares, from the first down the chain, until the response is sent to the client. Each middleware function can either pass the request to the next middleware with the next() function, or it can respond to the client and resolve the request.

Learn more about Express middleware here.

6.2. Catching errors in Express

Express has a special type of middleware function called “Error-handling middleware”. These functions have an extra argument err. Every time an error is passed in a next() middleware function, Express skips all middleware functions and goes straight to the error-handling ones.

Here’s an example on how to write one:

const errorMiddleware = (error: any, req: Request, res: Response, next: NextFunction) => {
  // Do something with the error
  next(error); // pass it to the next function
};

6.3. What to do with errors

Now that we know how to catch errors, we have to do something with them. In APIs, there are generally two things you should do: respond to the client and log the error.

6.3.1. errorReponse middleware (responding to the client)

Personally, when writing APIs I follow a consistent JSON response structure for successful and failed requests:

// Success
{
    "response": "successfull",
    "message": "some message if required",
    "data": {}
}

// Failure
{
    "response": "error",
      "error": {
        "type": "type of error",
        "path": "/path/on/which/it/happened",
        "statusCode": 404,
        "message": "Message that describes the situation"
      }
}

And now we’re going to write a middleware that handles the failure part.

const errorResponse = (error: any, req: Request, res: Response, next: NextFunction) => {
  const customError: boolean = error.constructor.name === 'NodeError' || error.constructor.name === 'SyntaxError' ? false : true;

  res.status(error.statusCode || 500).json({
    response: 'Error',
    error: {
      type: customError === false ? 'UnhandledError' : error.constructor.name,
      path: req.path,
      statusCode: error.statusCode || 500,
      message: error.message
    }
  });
  next(error);
};

Let’s examine the function. We first create the customError boolean. We check the error.constructor.name property which tells us what type of error we’re dealing with. If error.constructor.name is NodeError (or some other error we didn’t personally create), we set the boolean to false, otherwise we set it to true. This way we can handle known and unknown errors differently.

Next, we can respond to the client. We use the res.status() function to set the HTTP status code and we use the res.json() function to send the JSON data to the client. When writing the JSON data, we can use the customError boolean to set certain properties. For instance, if the customError boolean is false, we will set the error type to ‘UnhandledError’, telling the user we didn’t anticipate this situation, otherwise, we set it to error.constructor.name.

Since the statusCode property is only available in our custom error objects, we can just return 500 if it’s not available (meaning it’s an unhandled error).

In the end, we use the next() function to pass the error to the next middleware.

6.3.2. errorLog middleware (logging the error)

const errorLogging = (error: any, req: Request, res: Response, next: NextFunction) => {
  const customError: boolean = error.constructor.name === 'NodeError' || error.constructor.name === 'SyntaxError' ? false : true;

  console.log('ERROR');
  console.log(`Type: ${error.constructor.name === 'NodeError' ? 'UnhandledError' : error.constructor.name}`);
  console.log('Path: ' + req.path);
  console.log(`Status code: ${error.statusCode || 500}`);
  console.log(error.stack);
};

This function follows the same logic as the one before, with a small difference. Since this logging is intended for developers of the API, we also log the stack.

As you can see, this will just console.log() the error data to the system console. In most production APIs logging is a bit more advanced, logging to a file, or logging to an API. Since this part of the API building is very application-specific, I didn’t want to dive in too much. Now that you have the data, choose what approach works best for your application and implement your version of logging. If you’re deploying to a cloud-based deploying service like AWS, you will be able to download log files by just using the middleware function above (AWS saves all the console.log()s).

7. You can handle errors now.

There you go! That should be enough to get you started with handling errors in a TypeScript + Node.js + Express.js API workflow. Note, there’s a lot of room for improvement here. This approach is not the best, nor the fastest, but is pretty straightforward and most importantly, forgiving, and quick to iterate and improve as your API project progresses and demands more from your skills. These concepts are crucial and easy to get started with, and I hope you’ve enjoyed my article and learned something new.

Here's a GitHub repository I made so you can get the full picture: (coming soon)

Think I could’ve done something better? Is something not clear? Write it down in the comments.

Anyone else you think would benefit from this? Share it!

Get in touch: Telegram, Linkedin, Website

Thank you 🙂