DEV Community: Artur Ceschin

Serverless APIs on AWS with API Gateway and Lambda Functions (First Steps)

Artur Ceschin — Thu, 29 Feb 2024 14:10:47 +0000

In this article will explore how serverless computing works; despite its name, it still depends on servers. Additionally, we will provide an AWS tutorial, so make sure you have an active account.

Understanding ways to deploy your application

First, let's examine the traditional method of running and storing your project: Typically, we "rent" computing resources, such as a virtual machine, from cloud providers like **AWS, Azure, or GCP, among can access we have access to these resources, we configure our project by installing dependencies and running it on a designated port.

Using the traditional method on AWS, a suitable service for this approach is Amazon EC2 (Elastic Compute Cloud). With EC2, you can select the operating system and customize the hardware specifications according to your project's requirements. However, it's important to note that the more hardware resources you allocate, the higher the cost will be.

EC2 guarantees 24/7 availability for your application. The cost varies based on instance type and allocated resources. A primary EC2 instance with 500MB of memory typically costs USD 4.00/month. However, this method may have problematic characteristics depending on your specific needs.

Manual Updates: To keep your project up-to-date on services like Amazon EC2, you'll need to update it manually. Although this gives you complete control over your machine, it also means you are responsible for ensuring that everything is up-to-date.
Scaling Responsibility: When you scale your server, you can either increase the power of existing instances (vertical scaling) or create new instances (horizontal scaling). This provides you with greater flexibility but requires careful planning to ensure that your infrastructure effectively meets your needs.
EC2 incurs charges per hour, even when it's not in use. Although you can save costs by shutting down your project during idle periods, it also means that it won't be accessible in case of emergencies. However, you can downscale or upscale your server to adjust your project's computational needs during idle hours.
Using EC2 requires an understanding of infrastructure.

Serverless

At first glance, 'Serverless' might imply no servers at all. However, in reality, it means utilizing a server to host your APIs without needing you to manage it directly. Instead, cloud providers like AWS take care of the server management on your behalf.

When discussing Serverless, we refer to 'FaaS' (Function As a Service). Each cloud provider offers Serverless products, with AWS offering AWS Lambda.

Serverless computing typically comes with significantly lower costs, especially for small and medium applications.

In Serverless architecture, our application only runs upon API requests, which can result in a 'Cold Start' the first time. Our serverless platform checks if the application is running and looks for a previously started container to handle requests quickly. If it is not running, it creates one within milliseconds using technologies like Firecracker. Subsequent requests for the same service are handled without starting a new container, known as a 'Warm,' ensuring speedy response times for users.

Keeping our Serverless Functions small and granular is crucial to ensure that our 'Cold Start' is as fast as possible. Moreover, the container will shut down if there is no activity on the server for a while, usually between 5 to 15 minutes. This process helps us save significant costs by using resources only when necessary.

It is important to note that we do not pay for the time the container executes. Instead, we are billed based on how many times the function is executed and the duration of each execution.

Hands-on Tutorial

Let's see this process in practice on AWS.

I'll name my function listUser and use Node.js with the arm64 architecture. It's cost-effective and works well for our needs, as our application won't rely heavily on system methods.

To change the default execution role, we'll create a new role with basic permissions. Lambda allows us to customize permissions for each function. By default, Lambda enables CloudWatch, ensuring all our logs are readily available. This is particularly useful for tracking errors and viewing the execution details of our applications.

For "Advanced settings", we'll keep everything as default, leaving it empty. Then, we'll move on to creating the function.

As mentioned earlier, Lambda automatically integrates with CloudWatch to log every request, which is particularly useful for error handling. To observe this in action, insert a throw new Error() function before the main function continues. For example:

export const handler = async (event) => {
  throw new Error('An error occurred here');
  const response = {
    statusCode: 200,
    body: JSON.stringify('Hello from Lambda!'),
  };
  return response;
};

After inserting this, click 'Deploy,' navigate to the 'Test' tab, and send a request. It doesn't matter what you send for this example; I typically send an object with an email. Then, click on ' Test'.

Next, go to CloudWatch > Logs > Log Group, and you'll find the logs there! You'll likely see something similar to this:

After creating the function, navigate to the Configuration page. Here, you'll find options for "Memory", "Ephemeral storage", and "Timeout". It's important to note that increasing these values can affect pricing. By default, "Memory" is set to 128 MB, but you can increase it to 10 GB. The "Ephemeral storage" is temporary and cleared each time the Lambda function is invoked, making it essential for our function to be stateless. The minimum storage value is 512 MB, and the maximum is 10 GB.

Additionally, consider the "Timeout" setting. The minimum timeout is 1 second, and the maximum is 15 minutes. However, Lambda functions are intended to be fast, and if your process exceeds 15 minutes, the function will be terminated.

Now, how can we see that working? Lambda wasn't just built for API development! It was designed with event-driven scenarios in mind. Lambda works with triggers. For example, we might want to execute our Lambda function when an HTTP request is sent or our S3 bucket changes, such as an upload. In such cases, we can configure our Lambda function to be invoked.

Let's start with an HTTP trigger example; go to your Lambda > Configuration > Function URL > Create function URL

In the 'Auth type' section, I'll leave it set to 'NONE, which will generate a basic 'Policy statement.' I won't make any changes there. Next, in the 'Invoke mode' section, I'll stick with the default option, 'BUFFERED.' I'll keep the CORS configuration as it is for now and then click on Save.

Once saved, we'll get a URL. If you click on that URL, you'll probably see something like this:

Now, let's explore how to upload multiple files containing logic and libraries to AWS Lambda.

This exercise will demonstrate that Lambda functions can consist of multiple files and utilize various libraries. While the application we're building is simple, it will showcase the flexibility of Lambda in handling multiple packages and files.

I'll create a new folder and initialize a Node.js project by running yarn init -y. This will set up the basic configuration for our project.

Next, I'll create a src folder within the project directory. Inside this folder, I'll create an index. mjs file. Utilizing the new ECMAScript Modules syntax with import and export, this file will serve as the entry point for our Lambda function.

Now, let's create another folder named utils and add a file named response.mjs. In this file, we'll define a function called response that takes a statusCode and a body, converting the body to a string before returning it as part of the response object.

export function response(statusCode, body) {
  return {
    statusCode,
    body: JSON.stringify(body)
  };
}

Now, in our index.mjs file, let's define a 'handler' function. For demonstration purposes, we'll import randomUUID from the node:crypto module and jwt from the jsonwebtoken library, which we'll install using yarn add jsonwebtoken.

import { randomUUID } from 'node:crypto';
import jwt from 'jsonwebtoken';
import { response } from "./utils/response.mjs";

export async function handler(event) {
  const token = jwt.sign({
    sub: randomUUID(),
  }, process.env.JWT_SECRET);

  return response(200, {
    users: [
      {
        id: randomUUID(),
        name: 'Artur',
        token
      }
    ]
  });
}

To set **environment variables **in Lambda, navigate to your Lambda configuration and locate the 'Environment variables' section below the Function URL. Here, you can add the key-value pairs for your variables.

Now, our code will have access to the environmental variable.

Now, let's discuss how to upload our code. We have two options: uploading a zip file directly or using the code stored in an S3 bucket. To start, click the 'Upload from' button in the top right corner and choose your preferred option; I will use the zip option for now.

Let's upload the zip file containing the code we just created. Once uploaded, your Lambda function configuration should look like the following image:

But if we access the URL provided, you will probably see the Internal Server Error error. We haven't set the correct path to access our handler. To fix that, go to the Runtime settings section, click on edit, and change it to the desired path for the handler. In my case, that will be live009/src/index.handler

We've uploaded our code, but how do we see it in action? It's a bit of a manual process—like flipping a switch and hoping for the best! But fear not. There are better ways to do this; we'll dive into those in the following tutorials.

But first, let's address a couple of things. Firstly, we haven't told our Lambda function which methods it should be able to handle—like POST, PUT, GET, or DELETE. And have you noticed how our URLs are all over the place and don't make much sense? Yeah, we need to fix that, too.

Introducing Amazon API Gateway! This fantastic service enables us to define precisely how our** HTTP routes** should operate*. It acts as a **traffic controller for our requests, guaranteeing they **always reach the correct destination. Additionally, it performs other essential tasks such as **caching and configuring authentication*, ensuring that only authorized personnel can access our resources!

To get started, go to API Gateway and select the HTTP API option. This option is faster and more cost-effective than the REST API option. After making your selection, click on the 'Build' button. This will take you to a screen that looks similar to the one below:

In the image, I selected Lambda as my integration, chose our listUser Lambda function, and gave our API a name (you can name it whatever you like).

Next, I clicked' Next' to set the HTTP method. In the 'Configure routes' section, I put the URL code to GET, changed the path to '/users', and specified that it should be redirected to the listUsers function when this request happens.

Then, in the Configure stages section, I kept the settings as default for now and clicked Create to complete the process.

Once created, you can access the Invoke URL, and add '/users' at the end of the URL. This will trigger the Lambda function we set up earlier, and you'll see the return we defined previously.

Using S3 as our Trigger

To conclude this tutorial, we will now create a function that will execute each time a new file is uploaded to an S3 bucket.

To begin, follow the same steps we did earlier to create a new Lambda function. Once the function is created, navigate to the 'Configuration' section and choose 'Triggers' in the left sidebar. Click on the 'Add trigger' button.

In the trigger configuration, select 'S3' as the trigger source, pick the bucket you have previously created, and specify that the event should be triggered when a new object is created. If you only want to trigger for JSON files, you can set the event suffix to '.json'. Before clicking 'Add', make sure to check the 'Recursive invocation' option.

To see what data is passed in the event object to our handler function, add a console.log(event) within the function. Then, open your S3 bucket and CloudWatch. Create a simple JSON file like the one below:

[{"email": "artur.ceschin@gmail.com", "name": "Artur Ceschin"}, {"email": "Joe.doeh@gmail.com", "name": "Joe Doeh"}]

Upload this file to your S3 bucket, and check CloudWatch to see the console.log output. You should see something like this:

Records: [
    {
      eventVersion: '2.1',
      eventSource: 'aws:s3',
      awsRegion: 'us-east-1',
      eventTime: '2024-02-27T22:09:31.025Z',
      eventName: 'ObjectCreated:Put',
      userIdentity: [Object],
      requestParameters: [Object],
      responseElements: [Object],
      s3: [Object]
    }
  ]

For better readability, you can stringify the event object using console.log('EVENT=>', JSON.stringify(event, null, 2)). This will provide a nicely formatted output in your CloudWatch logs.
If you try to upload a file that is not a .json file, it does not trigger our Lambda.

Let's now read the file uploaded to our S3 bucket. First, let's modify our Lambda function to log the bucket name and key of the uploaded file:

import { S3Client, GetObjectCommand } from '@aws-sdk/client-s3';

export const handler = async (event) => {
  const [record] = event.Records;

  const bucket = record.s3.bucket.name;
  const key = record.s3.object.key;

  console.log('FILES', { bucket, key });
};

After uploading a new file, check CloudWatch logs. You should see output like this:

FILES { bucket: 'artur.ceschin.dev', key: 'users2.json'}

Now, let's read the contents of the file. We'll use the @aws-sdk/client-s3 package, which comes pre-installed in AWS Lambda. We'll import the S3Client and GetObjectCommand methods to locate and retrieve the file from our S3 bucket. Here's the updated code:

import { S3Client, GetObjectCommand } from '@aws-sdk/client-s3';

export const handler = async (event) => {
  const [record] = event.Records;

  const bucket = record.s3.bucket.name;
  const key = record.s3.object.key;

  const s3Client = new S3Client({});
  const command = new GetObjectCommand({ Bucket: bucket, Key: key });

  const response = await s3Client.send(command);

  console.log('RESPONSE =>', response);
};

However, if you run this code and upload a file, you'll likely encounter an 'Access Denied' error. Navigate to your Lambda function's Configuration > General Configuration> Edit to fix this. At the bottom of 'Basic settings,' click the link: View the processJSON-role-x5iz5f89. This will take you to the IAM role associated with your Lambda function.

Next, click Add permission > Create inline policy. Select the service (S3) and search for 'GetObject.' Add the ARN of your bucket as the resource. Leave all actions as ',' and click **Add ARN. Finally, click **Next, provide a description, and click **Create policy*. In the two images below, you can see the two processes you will encounter as described:

After completing that process, you will likely see your request in CloudWatch. But what if we want to read the JSON file inside our object?

In the code below, we retrieve the Body from the request, push chunks (pieces from our object) to our array, and then display them in the console.log.

export const handler = async (event) => {
    const [record] = event.Records

    const bucket = record.s3.bucket.name
    const key = record.s3.object.key

    const s3Client = new S3Client({})
    const command = new GetObjectCommand({Bucket: bucket, Key: key})

    const { Body } = await s3Client.send(command)
    const chunks = []
    for await (const chunk of Body) {
      chunks.push(chunk)
    }

    const buffer = Buffer.concat(chunks).toString('utf-8')

    console.log('Buffer =>', buffer)
};

Wow, we've covered a lot in this tutorial! I hope you found it enjoyable and informative. If you have any doubts or suggestions, please leave them in the comments below. Before we wrap up, let's briefly discuss the pros and cons of using Lambda functions:

Props ✅

Having a deep understanding of your infrastructure is not necessary.
Maintaining your infrastructure is easier than maintaining other services.
Automatic configuration is available through CloudWatch.
The service is highly scalable.
You only pay for what you use.
The responsibilities are minimal.
Triggers can be set up based on events.

Cons 🛑

A cold start can be an issue if there are too many requests, as it can slow down the process.
Lambda has some size limitations that may impact your usage. These include:
- a maximum code size of 250MB
- 10GB of Ephemeral storage
- a timeout limit of 15 minutes
- a maximum memory usage of 10GB
It can get complicated, especially when one Lambda function calls another.
Cost can be a concern if there are too many requests, mainly when using API Gateway. In this case, it may be more expensive than providing an instance that runs 24/7.

Conclusion

In this article, we explored serverless computing using AWS Lambda, a cost-effective and scalable solution. We have compared it with traditional methods and highlighted its automation benefits and the simplified deployment process it offers.

Our tutorial has covered the process of setting up Lambda functions, configuring triggers, and handling events such as S3 file uploads. We have also shown some challenges, such as cold starts and size limitations, and provided solutions to overcome them.

Overall, AWS Lambda is a powerful tool for modern applications that streamlines deployment reduces costs, and simplifies scalability.

If you have any questions or suggestions for the next articles, please comment below! 👋

Deploying React apps to production on AWS ☁️

Artur Ceschin — Mon, 22 Jan 2024 12:52:24 +0000

In this article, we will explore how to deploy your Front-End project on AWS. I will demonstrate this using a React project, but these steps can be applied to Vue, Angular, or any other stack.

To follow this tutorial, you will need to meet the following 3 requirements.

You will first require an AWS account. To set up your account, you'll need to provide your credit card information as AWS charges based on usage. However, storing your project can be exceptionally affordable, and most services offer free tiers. This means you can store your projects for free if you stay within the limits of the free tier usage. This is the screen you encounter after providing your information for AWS. You can choose the best option for your needs—I am opting for the free version.👇
You will also require a domain because we need access to the DNS configurations to point it within AWS. However, this step is optional, as AWS will generate a default URL for you to test.
The final requirement is a React project or any other front-end project, allowing us to generate the build folder.

In order for us to deploy our static front-end projects, all we need is to do is find a service that can store our files, and the file we will be using is the Simple Storage Service commonly now as S3.
Go to yout

Navigate to your S3 Service:
- First things first, head over to your AWS Console.
- Dive into the S3 service.
Discover Your Buckets:
- Look around, and you'll spot buckets.
- They're where you stash everything from your frontend project to cat GIFs.
Create a Fresh Bucket:
- Hit the "Create Bucket" button – this is your backstage pass to storage.
- Choose a name that is unique across all AWS accounts!
Choose Your Storage Spot - Select Location:
- Time to pick a location for your bucket.
- Consider things like pricing and how speedy you want your files to be – it's a bit like choosing a vacation spot.
- I opted for US East (N. Virginia) as it seemed fitting for my storage requirements. However, feel free to select the location that aligns with your specific needs and preferences. 🌍
Proceed with Default Options:
- For the rest of the setup, I stuck to the defaults.

And there you have it – your bucket is ready to roll! 🚀

Once created, simply click on the newly made bucket. Upload the files from your build or dist directory in your React project into this bucket. Click on upload and you're done with the S3 configuration!

CloudFront

Now, how do we access these files? We'll utilize our famous Content Delivery Network (CDN) This magic 🪄 spreads our project across different places. Even though our app lives in North Virginia, it keeps the delay super low for users all over the globe. And guess what? We're going to use AWS's CloudFront to make it happen!
To do that go to the CloudFront service and create a new one, once you do that you will have to fill a fell inputs.

The initial step involves configuring the Origin settings. Begin by selecting our S3 project in the Origin domain section. Subsequently, choose the Origin access. For our setup, we will opt for Origin access control settings (recommended). Upon selection, you'll need to designate your Origin access control. If you haven't created one, use the default options to set it up. Leave the remaining settings in this section at their default values.
Now, onto the Default cache behavior section. Most of these settings can stick to the defaults. However, let's change a couple of things. Under Viewer protocol policy, switch it to Redirect HTTP to HTTPS.

Web Application Firewall (WAF)

Web Application Firewall (WAF):
WAF has a fixed price, which can be quite costly. While it's a good consideration for APIs, since we're only handling static files, it's unnecessary. Therefore, I'll select the option Do not enable security protections.
Settings:
In the settings, the first option you'll encounter is the Price class. I'll opt for Use all edge locations (best performance), which might come at a slightly higher cost. But, it's good to consider your own goals and the server's location.
For the Custom SSL certificate, if you don't have your own domain, you can leave it as is, and CloudFront will generate a domain for you. Additionally, in the Supported HTTP versions, consider checking the HTTP/3 option.

Now, for the Default root object field, this is where you define the name of the object (files) that will be served when a user requests the root URL. To achieve this, we'll input index.html.
Just keep the default settings for the rest and click Create Distribution.

This is a demo gif of all that process that we've done so far:

After creating, you'll likely land on a page that looks like this:

All we need to do now is to click in the Copy Policy button, and click in the link Go to S3 bucket permissions to update policy. Now click in Edit in the Bucket policy Section and paste your policies and save. Now we have allowed CloudFront to access our S3 Bucket 👏.

Now, when you navigate to the general area of your CloudFront Distribution, you will find a Details section with the title Distribution Domain Name. This title is accompanied by a generic link created by AWS, allowing you to access your live application. If you copy and paste this link into a web browser, you will likely see your project running under this domain 🚀.

Changing to your own custom domain:

The process may vary slightly depending on the provider with whom you created and purchased your personal domain. However, you should be able to access your domain and change your DNS servers. To configure our DNS, we will use another AWS Service called** Route 53*. In this service, choose the option **Create hosted zone* and fill in the necessary information.

Enter your domain without the www, like this: arturceschin.com.
The description is entirely optional and doesn't affect anything; it's just for your personal reference.
Keep it set as Public hosted zone.
Click on CREATE!

Pay attention to your Name servers; these are the ones you'll need to configure in your DNS Server.** Make sure to use all four.**

Simply copy and paste these Name servers into your other domain provider's settings and save. Keep in mind that this process may take up to 2 hours!

Once that is set, navigate to your CloudFront settings. Click on 'Edit,' and go to the section labeled Alternate domain name (CNAME). Click Add item and enter your domain twice: once with www at the beginning and once without. 🌐

Let's set up our Custom SSL certificate using another AWS service called Certificate Manager—and it's free! Click on Request a public certificate and then Next.

Now, just follow the image below: set one domain like before and another with . to make all subdomains valid. This is called a wildcard.

Choose DNS validation and keep the other options as they are. Click Request. Your request will be pending validation. To resolve this, click your Certificate ID and choose Create records in Route 53.

In about five minutes, your status should change to Issued ✅ if you completed the previous step of copying your Name Servers to the DNS Servers in your domain provider and waited for about two hours for that process to complete.

Now, go to your CloudFront settings once again, navigate to the Custom SSL certificate section, and choose the certificate we just created. The Custom SSL certificate should suggest the certificate, similar to the image below.⬇️⬇️

Go to Save Changes and wait for a moment, while it is deploying.

Now, what we need to do is set up the redirection so that when we access our domain, the request is directed to CloudFront. To achieve this, follow these steps:

Go to the Route 53 service.
Navigate to your hosted zone.
Click on Create Record.
Choose the Alias option.
Select Alias to CloudFront distribution.
Choose the desired CloudFront distribution.
Click on Create Record.

Just like to the image below:

Now, we will repeat the same process, but set the Record name to www.

After you've done all that, and your deploy is finished, you should see your project with your cool custom URL 🤩.

But, heads up! When you access it and hit refresh, you might get smacked with an error saying your access is denied. Just like in the image 👇.

But to fix that, all we need to do is set it up so that if we encounter an error like "Access Denied," we automatically redirect to something like index.html. Here's how:

Go to your CloudFront Distribution.
Navigate to the Error pages section.
Click on Create custom error response.
Choose the HTTP error code to be 403 Forbidden.
Click on Customize error response and set it to Yes.
Set Response page path to be /index.html and click on Create custom error page.
Wait for a few minutes for the deployment to take effect.

Check out the image below for guidance.

With all that set, you should be able to see your application with no more errors, and the deployment of your Front-End project is done. 👏🚀

Conclusion

Deploying your Front-End project on AWS offers numerous advantages, including scalable storage with Amazon S3, efficient content delivery through CloudFront's CDN, and seamless integration with Route 53 for DNS management and AWS Certificate Manager for your SSL Certificates. It's the winning combo for a seamless Front-End deployment. Ready to embrace the power of AWS to enhance your Front-End deployment experience? 🚀✨

Stateful vs Stateless

Artur Ceschin — Mon, 06 Nov 2023 03:27:08 +0000

In this article, I will explain what stateful and stateless applications are, highlight their differences, and discuss considerations when choosing in a cloud context. But before delving into these topics, let's begin with a brief explanation of what 'state' means in an application.

The state of an application (or anything else, really) is its condition or quality of being at a given moment in time—its state of being. Whether something is stateful or stateless depends on how long the state of interaction with it is being recorded and how that information needs to be stored.
Red-Hat Stateful vs Stateless

That is a good overview of what we are going to see, but what exactly is 'state' in an application?

The term 'state' can have various meanings in different contexts, but it typically refers to data or information that can be modified, often associated with user interactions.

What are the differences between Stateful and Stateless?

Stateless

By default, the web is designed to be stateless. In a stateless architecture, each interaction between the user and the application is created from scratch every time. The application does not store the user's session or preferences locally. Examples of stateless applications include static content websites and search engines. These stateless applications offer several advantages:

Easier to Develop, Design, and Maintain: Stateless applications are simpler to create, design, and keep up.
Highly Scalable: They can easily distribute requests across multiple servers, making them suitable for high levels of traffic.
Flexible and High Availability: Stateless applications can adapt to different scenarios, making them more resilient to failures and capable of handling numerous requests.

Stateful

Stateful applications are commonly used to provide a more personalized and consistent user experience. For example, each user can have their own preferences and customizations. Examples of stateful applications include:

An e-commerce application, which can be stateful because it stores user profile configurations and shopping data.
However, stateful applications have their downsides:

Local Data Storage: User data is stored locally, which means that user sessions are maintained on the server. Once the communication is closed, the data is lost.
Complexity: Managing state across multiple sessions and components can be challenging in terms of design and architecture.
Scalability: Distributing stateful components across multiple servers requires careful planning and infrastructure.

Stateless vs Stateful in the Cloud Context

They are both good for their own specific circumstances, but technologies have advanced, and so the necessity of building scalable applications using microservices and containers and deploying them in the cloud. For those cases, it is usually better for the application to be stateless, but why?

Let's start by creating a simple scenario where we have a configured auto-scaling system, allowing our infrastructure to scale based on resource demand. In this setup, clients access our load balancer, which then routes them to different servers.

To make this system work, it's crucial that we avoid storing user data on individual servers like in a stateful application. This is because, in another request, the load balancer may direct the client to a different server where the user's session data is not available. The ideal approach is to ensure that all servers have access to user details by storing session information in a centralized database. This way, regardless of which server handles the request, it can retrieve the user's information from the shared database. This architecture follows a stateless approach, where data is stored externally, allowing any server to access user details without relying on local storage.
This image provides a better illustration of the example above. We store user data in a database like PostgreSQL, images in Amazon S3, and the contents of the e-commerce cart in a DynamoDB database. By doing this we can assure the all servers can acess different data when needed.

Especially when developing APIs, it's preferable to use stateless applications. Both RESTful APIs and GraphQL APIs follow stateless principles by default.

While it is possible to develop and deploy stateful applications using containers in the cloud, the flexibility and simplicity of developing applications using stateless architecture make it preferable when creating highly scalable software.

I hope you enjoyed this brief overview, feel free to interact in the chat, I see you in the next one 👋🏼!