DevOps

How to set up local cloud environment with LocalStack

Published Jun 19, 2024

Updated Jun 19, 2024

6 min read

How to set up local cloud environment with LocalStack

Developers enjoy building applications with AWS due to the richness of their solutions to problems. However, testing an AWS application during development without a dedicated AWS account can be challenging. This can slow the development process and potentially lead to unnecessary costs if the AWS account isn't properly managed.

This article will examine LocalStack, a development framework for developing and testing AWS applications, how it works, and how to set it up.

Assumptions

This article assumes you have a basic understanding of:

AWS: Familiarity with S3, CloudFormation, and SQS.
Command Line Interface (CLI): Comfortable running commands in a terminal or command prompt.
JavaScript and Node.js: Basic knowledge of JavaScript and Node.js, as we will write some code to interact with AWS services.
Docker Concepts: Understanding of Docker basics, such as images and containers, since LocalStack runs within a Docker container.

What is LocalStack?

LocalStack is a cloud service emulator that runs in a single container on your laptop or in your CI environment. With LocalStack, you can run your AWS applications or Lambdas entirely on your local machine without connecting to a remote cloud provider! Whether you are testing complex CDK applications or Terraform configurations or just beginning to learn about AWS, LocalStack simplifies your testing and development workflow, relieving you from the complexity of testing AWS applications.

Prerequisite

Before setting up LocalStack, ensure you have the following:

Docker Installed: LocalStack runs in a Docker container, so you need Docker installed on your machine. You can download and install Docker from here.
Node.js and npm: Ensure you have Node.js and npm installed, as we will use a simple Node.js application to test AWS services. You can download Node.js from here.
Python: Python is required for installing certain CLI tools that interact with LocalStack. Ensure you have Python 3 installed on your machine. You can download Python from here.

Installation

In this article, we will use the LocalStack CLI, which is the quickest way to get started with LocalStack. It allows you to start LocalStack from your command line. Localstack spins up a Docker instance,

Alternative methods of managing the LocalStack container exist, and you can find them here.

To install LocalStack CLI, you can use homebrew by running the following command:

brew install localstack/tap/localstack-cli

If you do not use a macOS or you don’t have Brew installed, you can install the CLI using Python:

python3 -m pip install --upgrade localstack

To confirm your installation was successful, run the following:

localstack --version

That should output the installed version of LocalStack. Now you can start LocalStack by running the following command:

localstack start

This command will start LocalStack in docker mode, and since it is your first installation, try to pull the LocalStack image. You should see the below on your terminal

After the image is downloaded successfully, the docker instance is spun up, and LocalStack is running on your machine on port 4566.

Testing AWS Services with LocalStack

LocalStack lets you easily test AWS services during development. It supports many AWS products but has some limitations, and not all features are free.

Community Version: Free access to core AWS products like S3, SQS, DynamoDB, and Lambda. Pro Version: Access to more AWS products and enhanced features.

Check the supported community and pro version resources for more details.

We're using the community edition, and the screenshot below shows its supported products. To see the current products supported in the community edition, visit http://localhost:4566/_localstack/health.

This article will test AWS CloudFormation and SQS.

Before we can start testing, we need to create a simple Node.js app. On your terminal, navigate to the desired folder and run the following command:

npm init -y

This command will create a package.json file at the root of the directory. Now we need to install aws-sdk. Run the following command:

npm i aws-sdk

With that installed, we can now start testing various services.

AWS CloudFormation

AWS CloudFormation is a service that allows users to create, update, and delete resources in an AWS account. This service can also automate the process of provisioning and configuring resources. We are going to be using LocalStack to test creating a CloudFormation template.

In the root of the folder, create a file called cloud-formation.js. This file will be used to create a CloudFormation stack that will be used to create an S3 bucket. Add the following code to the file:

const AWS = require('aws-sdk');

const cloudFormation = new AWS.CloudFormation({
  region: 'us-east-1',
  endpoint: 'http://localhost:4566',
  credentials: new AWS.Credentials("test", "test")
});

const params = {
  StackName: 'test-local-stack',
  TemplateBody: `
        {
          "Resources": {
            "TestBucket": {
                "Type": "AWS::S3::Bucket"
            }
          }
        }
    `,
};

cloudFormation.createStack(params, (err, data) => {
  if (err) {
    console.log(err);
  } else {
    console.log(data);
  }
});

In the above code, we import the aws-sdk package, which provides the necessary tools to interact with AWS services. Then, an instance of the AWS.CloudFormation class is created. This instance is configured with: region: The AWS region where the requests are sent. In this case, us-east-1 is the default region for LocalStack. endpoint: The URI to send requests to is set to http://localhost:4566 for LocalStack. You should configure this with environment variables to switch between LocalStack for development and the actual AWS endpoint for production, ensuring the same code can be used in both environments. credentials: The AWS credentials to sign requests with. We are passing new AWS.Credentials("test", "test")

The params object defines the parameters needed to create the CloudFormation stack:

StackName: The name of the stack. Here, we are using 'test-local-stack'. TemplateBody: A JSON string representing the CloudFormation template. In this example, it defines a single resource, an S3 bucket named TestBucket.

The createStack method is called on the CloudFormation client with the params object. This method attempts to create the stack. If there is an error, we log it to the console else, we log the successful data to the console.

Now, let’s test the code by running the following command:

node cloud-formation.js

If we run the above command, we should see the JSON response on the terminal.

{
  "ResponseMetadata": { "RequestId": "6617f848-91b2-42d6-becb-fae9669c8f9d" },
  "StackId": "arn:aws:cloudformation:us-east-1:000000000000:stack/test-local-stack/651b1847"
}

AWS SQS

The process for testing SQS with LocalStack using the aws-sdk follows the same pattern as above, except that we will introduce another CLI package, awslocal. [awslocal](https://github.com/localstack/awscli-local) is a thin wrapper and a substitute for the standard aws command, enabling you to run AWS CLI commands within the LocalStack environment without specifying the --endpoint-url parameter or a profile.

To install awslocal, run the following command on your terminal:

pip3 install awscli-local

Next, let’s create an SQS queue using the following command:

awslocal sqs create-queue --queue-name test-queue

This will create a queue name test-queue and return queueUrl like below:

{
    "QueueUrl": "http://sqs.us-east-1.localhost.localstack.cloud:4566/000000000000/test-queue"
}

Now, in our directory, let’s create a sqs.js file, and inside of it, let’s paste the following code:

const AWS = require('aws-sdk');

const sqs = new AWS.SQS({
  endpoint: 'http://localhost:4566',
  region: 'us-east-1',
  credentials: new AWS.Credentials('test', 'test'),
});

const queueUrl = 'http://sqs.us-east-1.localhost.localstack.cloud:4566/000000000000/test-queue'; //Replace with your queue URL

const params = {
  QueueUrl: queueUrl,
  MessageBody: 'Testing SQS with LocalStack',
};

sqs.sendMessage(params, (err, data) => {
  if (err) {
    console.log(err);
  } else {
    console.log(data);
  }
});

In the above code, an instance of the AWS.SQS class is created. The instance is configured with the same parameters as when creating the CloudFormation. We also created a params object which had the required properties needed to send a SQS message: QueueUrl: The URL of the Amazon SQS queue to which a message is sent. In our case, it will be the URL we got when we created a local SQS. Make sure to manage this in environment variables to switch between LocalStack for development and the actual AWS queue URL for production, ensuring the same code can be used in both environments. MessageBody: The message to send. We call the sendMessage method, passing the params object and a callback that handles error and data, respectively.

Let’s run the code using the following command:

node sqs.js

We should get a JSON object in the terminal like the following:

{
  "MD5OfMessageBody": "0c2a2ee858510ceee21a7d57f96cdc85",
  "MessageId": "e8857ade-45ce-45c7-9d56-3faa0bee70e5"
}

To test if we can receive the SQS message sent, let’s create a sqs-receive.js. Inside the file, we can copy over the AWS.SQS instance that was created earlier into the file and add the following code:

…
const queueUrl = 'http://sqs.us-east-1.localhost.localstack.cloud:4566/000000000000/test-queue'; //Replace with your queue URL

const params = {
  QueueUrl: queueUrl,
  MaxNumberOfMessages: 10,
  VisibilityTimeout: 60,
  WaitTimeSeconds: 20,
};

sqs.receiveMessage(params, (err, data) => {
  if (err) {
    console.log(err);
  } else {
    console.log(data);
  }
});

Run the code using the following command:

node sqs-receive.js

We should receive a JSON object and should be able to see the previous message we sent

{
  "Messages": [
    {
      "MessageId": "e8857ade-45ce-45c7-9d56-3faa0bee70e5",
      "ReceiptHandle": "MmMwOThlYjAtYzRmYi00OTkxLTlhNDMtYzY3YTJjZjJlNzQwIGFybjphd3M6c3FzOnVzLWVhc3QtMTowMDAwMDAwMDAwMDA6dGVzdC1xdWV1ZSBlODg1N2FkZS00NWNlLTQ1YzctOWQ1Ni0zZmFhMGJlZTcwZTUgMTcxNzk3OTQzMy41NjEwNjEx",
      "MD5OfBody": "0c2a2ee858510ceee21a7d57f96cdc85",
      "Body": "Testing SQS with LocalStack"
    }
  ]
}

When you are done with testing, you can shut down LocalStack by running the following command:

localstack stop

Conclusion

In this article, we looked at how to set up a local cloud environment using LocalStack, a powerful tool for developing and testing AWS applications locally. We walked through the installation process of LocalStack and demonstrated how to test AWS services using the AWS SDK, including CloudFormation and SQS.

Setting up LocalStack allows you to simulate various AWS services on your local machine, which helps streamline development workflows and improve productivity. Whether you are testing simple configurations or complex deployments, LocalStack provides the environment to ensure your applications work as expected before moving to a production environment.

Using LocalStack, you can confidently develop and test your AWS applications without an active AWS account, making it an invaluable tool for developers looking to optimize their development process.

This Dot is a consultancy dedicated to guiding companies through their modernization and digital transformation journeys. Specializing in replatforming, modernizing, and launching new initiatives, we stand out by taking true ownership of your engineering projects.

We love helping teams with projects that have missed their deadlines or helping keep your strategic digital initiatives on course. Check out our case studies and our clients that trust us with their engineering.

About the author(s)

Victor Umeh
Software Engineer. Passionate about web developement with specialty in Reactjs and Nextjs. He also interested in web3 and blockchain development. In his free time he plays soccer.
@Vyktoreumeh @vyktoremario

How to host a full-stack app with AWS CloudFront and Elastic Beanstalk

How to host a full-stack JavaScript app with AWS CloudFront and Elastic Beanstalk Let's imagine that you have finished building your app. You have a Single Page Application (SPA) with a NestJS back-end. You are ready to launch, but what if your app is a hit, and you need to be prepared to serve thousands of users? You might need to scale your API horizontally, which means that to serve traffic, you need to have more instances running behind a load balancer. Serving your front-end using a CDN will also be helpful. In this article, I am going to give you steps on how to set up a scalable distribution in AWS, using S3, CloudFront and Elastic Beanstalk. The NestJS API and the simple front-end are both inside an NX monorepo The sample application For the sake of this tutorial, we have put together a very simple HTML page that tries to reach an API endpoint and a very basic API written in NestJS. The UI The UI code is very simple. There is a "HELLO" button on the UI which when clicked, tries to reach out to the /api/hello endpoint. If there is a response with status code 2xx, it puts an h1 tag with the response contents into the div with the id result. If it errors out, it puts an error message into the same div. ` The API We bootstrap the NestJS app to have the api prefix before every endpoint call. ` We bootstrap it with the AppModule which only has the AppController in it. ` And the AppController sets up two very basic endpoints. We set up a health check on the /api route and our hello endpoint on the /api/hello route. ` Hosting the front-end with S3 and CloudFront To serve the front-end through a CMS, we should first create an S3 bucket. Go to S3 in your AWS account and create a new bucket. Name your new bucket to something meaningful. For example, if this is going to be your production deployment I recommend having -prod in the name so you will be able to see at a glance, that this bucket contains your production front-end and nothing should get deleted accidentally. We go with the defaults for this bucket setting it to the us-east-1 region. Let's set up the bucket to block all public access, because we are going to allow get requests through CloudFront to these files. We don't need bucket versioning enabled, because these files will be deleted every time a new front-end version will be uploaded to this bucket. If we were to enable bucket versioning, old front-end files would be marked as deleted and kept, increasing the storage costs in the long run. Let's use server-side encryption with Amazon S3-managed keys and create the bucket. When the bucket is created, upload the front-end files to the bucket and let's go to the CloudFront service and create a distribution. As the origin domain, choose your S3 bucket. Feel free to change the name for the origin. For Origin access, choose the Origin access control settings (recommended). Create a new Control setting with the defaults. I recommend adding a description to describe this control setting. At the Web Application Firewall (WAF) settings we would recommend enabling security protections, although it has cost implications. For this tutorial, we chose not to enable WAF for this CloudFront distribution. In the Settings section, please choose the Price class that best fits you. If you have a domain and an SSL certificate you can set those up for this distribution, but you can do that later as well. As the Default root object, please provide index.html and create the distribution. When you have created the distribution, you should see a warning at the top of the page. Copy the policy and go to your S3 bucket's Permissions tab. Edit the Bucket policy and paste the policy you just copied, then save it. If you have set up a domain with your CloudFront distribution, you can open that domain and you should be able to see our front-end deployed. If you didn't set up a domain the Details section of your CloudFront distribution contains your distribution domain name. If you click on the "Hello" button on your deployed front-end, it should not be able to reach the /api/hello endpoint and should display an error message on the page. Hosting the API in Elastic Beanstalk Elastic beanstalk prerequisites For our NestJS API to run in Elastic Beanstalk, we need some additional setup. Inside the apps/api/src folder, let's create a Procfile with the contents: web: node main.js. Then open the apps/api/project.json and under the build configuration, extend the production build setup with the following (I only ) ` The above settings will make sure that when we build the API with a production configuration, it will generate a package.json and a package-lock.json near the output file main.js. To have a production-ready API, we set up a script in the package.json file of the repository. Running this will create a dist/apps/api and a dist/apps/frontend folder with the necessary files. ` After running the script, zip the production-ready api folder so we can upload it to Elastic Beanstalk later. ` Creating the Elastic Beanstalk Environment Let's open the Elastic Beanstalk service in the AWS console. And create an application. An application is a logical grouping of several environments. We usually put our development, staging and production environments under the same application name. The first time you are going to create an application you will need to create an environment as well. We are creating a Web server environment. Provide your application's name in the Application information section. You could also provide some unique tags for your convenience. In the Environment information section please provide information on your environment. Leave the Domain field blank for an autogenerated value. When setting up the platform, we are going to use the Managed Node.js platform with version 18 and with the latest platform version. Let's upload our application code, and name the version to indicate that it was built locally. This version label will be displayed on the running environment and when we set up automatic deployments we can validate if the build was successful. As a Preset, let's choose Single instance (free tier eligible) On the next screen configure your service access. For this tutorial, we only create a new service-role. You must select the aws-elasticbeanstalk-ec2-role for the EC2 instance profile. If can't select this role, you should create it in AWS IAM with the AWSElasticBeanstalkWebTier, AWSElasticBeanstalkMulticontainerDocker and the AWSElasticBeanstalkRoleWorkerTier managed permissions. The next step is to set up the VPC. For this tutorial, I chose the default VPC that is already present with my AWS account, but you can create your own VPC and customise it. In the Instance settings section, we want our API to have a public IP address, so it can be reached from the internet, and we can route to it from CloudFront. Select all the instance subnets and availability zones you want to have for your APIs. For now, we are not going to set up a database. We can set it up later in AWS RDS but in this tutorial, we would like to focus on setting up the distribution. Let's move forward Let's configure the instance traffic and scaling. This is where we are going to set up the load balancer. In this tutorial, we are keeping to the defaults, therefore, we add the EC2 instances to the default security group. In the Capacity section we set the Environment type to Load balanced. This will bring up a load balancer for this environment. Let's set it up so that if the traffic is large, AWS can spin up two other instances for us. Please select your preferred tier in the instance types section, We only set this to t3.micro For this tutorial, but you might need to use larger tiers. Configure the Scaling triggers to your needs, we are going to leave them as defaults. Set the load balancer's visibility to the public and use the same subnets that you have used before. At the Load Balancer Type section, choose Application load balancer and select Dedicated for exactly this environment. Let's set up the listeners, to support HTTPS. Add a new listener for the 443 port and connect your SSL certificate that you have set up in CloudFront as well. For the SSL policy choose something that is over TLS 1.2 and connect this port to the default process. Now let's update the default process and set up the health check endpoint. We set up our API to have the health check endpoint at the /api route. Let's modify the default process accordingly and set its port to 8080. For this tutorial, we decided not to enable log file access, but if you need it, please set it up with a separate S3 bucket. At the last step of configuring your Elastic Beanstalk environment, please set up Monitoring, CloudWatch logs and Managed platform updates to your needs. For the sake of this tutorial, we have turned most of these options off. Set up e-mail notifications to your dedicated alert e-mail and select how you would like to do your application deployments. At the end, let's configure the Environment properties. We have set the default process to occupy port 8080, therefore, we need to set up the PORT environment variable to 8080. Review your configuration and then create your environment. It might take a few minutes to set everything up. After the environment's health transitions to OK you can go to AWS EC2 / Load balancers in your web console. If you select the freshly created load balancer, you can copy the DNS name and test if it works by appending /api/hello at the end of it. Connect CloudFront to the API endpoint Let's go back to our CloudFront distribution and select the Origins tab, then create a new origin. Copy your load balancer's URL into the Origin domain field and select HTTPS only protocol if you have set up your SSL certificate previously. If you don't have an SSL certificate set up, you might use HTTP only, but please know that it is not secure and it is especially not recommended in production. We also renamed this origin to API. Leave everything else as default and create a new origin. Under the Behaviors tab, create a new behavior. Set up the path pattern as /api/* and select your newly created API origin. At the Viewer protocol policy select Redirect HTTP to HTTPS and allow all HTTP methods (GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE). For this tutorial, we have left everything else as default, but please select the Cache Policy and Origin request policy that suits you the best. Now if you visit your deployment, when you click on the HELLO button, it should no longer attach an error message to the DOM. --- Now we have a distribution that serves the front-end static files through CloudFront, leveraging caching and CDN, and we have our API behind a load balancer that can scale. But how do we deploy our front-end and back-end automatically when a release is merged to our main branch? For that we are going to leverage AWS CodeBuild and CodePipeline, but in the next blog post. Stay tuned....

Sep 11, 2023

12 mins

NestJSAWSTypeScriptNodeJS

Building Scalable AI Applications: Insights from AWS's Michael Liendo

In this episode of the Modern Web Podcast, Rob Ocel, Danny Thompson, and Adam Rackis talk with Michael Liendo, Senior Developer Advocate at AWS, about building practical AI applications and tackling challenges like scalability, multimodal functionality, and cloud infrastructure choices. Michael shares insights on tools like AWS Amplify and DynamoDB, discusses strategies for managing cloud costs, and explores the evolving role of prompt engineering. Michael previews his upcoming talks at AWS re:Invent on AI and scalable B2B SaaS applications. Chapters - 00:00 - Introduction and Guest Welcome - 01:30 - Talking Weather and Life in the Midwest - 03:00 - Exploring Generative AI and Practical Applications - 06:45 - Navigating Cloud Costs and Scalability Considerations - 08:30 - Maintaining Creativity and Customization with AI - 11:00 - Managed Services vs. On-Prem Infrastructure Debate - 15:30 - Choosing a Tech Stack for Side Projects and Startups - 18:45 - Learning Cloud: Paths for Full-Stack Cloud Development - 22:30 - The Role of Cloud Certifications in Today's Market - 26:00 - Preview of Michael’s Upcoming Talks at AWS re:Invent - 32:00 - Where to Find Michael Online Follow Michael Liendo on Social Media Twitter: https://x.com/focusotter Linkedin: https://www.linkedin.com/in/focusotter/ Sponsored by Wix Studio...

Oct 14, 2024

1 min

AIAws AmplifyAWS

Understanding Effects In SolidJS

Understanding Effects In SolidJS In SolidJS, effects are a fundamental concept that helps developers manage side effects and reactive dependencies within their applications. Unlike standard functions that execute once and are done, effects in SolidJS are designed to automatically re-run whenever their dependencies change. This article will explore what effects are, how to use them, manage dependencies, handle multiple signals, and the lifecycle functions that enhance their functionality. What Are Effects? Effects in SolidJS are functions that automatically execute when the signals or reactive values they depend on change. This capability makes effects essential for managing side effects like DOM manipulations, data fetching, and subscriptions. Creating an Effect To create an effect in SolidJS, you use the createEffect function. This function takes a callback that runs whenever the effect is triggered by a change in its dependencies. ` In this example, the effect logs the user’s online status to the console. Each time the isOnline signal changes, the effect re-runs and logs the updated status. Managing Dependencies Dependencies in effects are the reactive values or signals that an effect observes. When any of these dependencies change, the effect re-runs. Interestingly, SolidJS automatically tracks these dependencies, meaning you don’t need to manually specify them, which reduces the risk of errors. When an effect is initialized, it runs once even if its dependencies haven't changed. This initial run is useful for setting up the effect, initializing variables, or subscribing to signals. ` Subscribing to Signals When an effect observes a signal, it essentially subscribes to it. This subscription allows the effect to re-run whenever the signal's value changes. ` In this example, the effect logs the current temperature whenever it changes. Managing Multiple Signals Effects in SolidJS can observe multiple signals simultaneously. This means that a single effect can track changes in multiple reactive values, re-running whenever any of them change. ` Here, the effect monitors both temperature and humidity signals. It re-runs when either signal changes, ensuring that it always logs the latest values. Nested Effects SolidJS allows effects to be nested within each other. Each nested effect independently tracks its own dependencies, ensuring that changes in an inner effect don’t inadvertently trigger an outer effect. ` In this example, changes to dependencies in the inner effect will not affect the outer effect. This separation prevents unintended behaviors and keeps effects isolated from one another. Lifecycle Functions SolidJS offers lifecycle functions that give you more control over when effects are initialized and disposed of. This can include running a side effect only once, or cleaning up a task when it is no longer needed. onMount The onMount function is used when you need to run a side effect only once, typically when a component is initialized. Unlike effects, which can re-run multiple times, onMount ensures that the callback is executed only once. ` This function is perfect for tasks like fetching data or setting up subscriptions that only need to happen once when the component mounts. onCleanup The onCleanup function is used to clean up tasks when a component is unmounted. This is particularly useful for clearing intervals, removing event listeners, or unsubscribing from services, thereby preventing memory leaks. ` In this example, onCleanup ensures that the interval is cleared when the component is unmounted, preventing it from running indefinitely in the background. Understanding the Execution Model of Effects in SolidJS SolidJS introduces a fine-grained reactivity) system that sets it apart in the UI development landscape. Unlike React, where effects are tied to component lifecycles and can sometimes trigger unnecessary re-renders, SolidJS operates at a much more granular level. It tracks dependencies down to individual signals or computations, enabling highly efficient updates. When you create an effect using createEffect, SolidJS automatically monitors every reactive signal accessed within that effect. It builds a precise dependency graph, which maps out exactly which effects should be re-executed when specific signals change. This approach ensures that only the necessary parts of your application update in response to state changes, resulting in more efficient rendering and overall better performance. Conclusion Effects in SolidJS are a powerful feature that enable you to react to changes in your application's state dynamically. By leveraging createEffect and using lifecycle functions like onMount and onCleanup, you can create robust and responsive applications. Understanding how to effectively use effects will help you build more efficient, maintainable, and bug-free SolidJS applications....

Aug 23, 2024

3 mins

SolidJS

AI Leadership: Data-Driven Decision Making & Avoiding "Analysis Paralysis" with Jerry Reghunadh

In this episode of Leadership Exchange, host Rob Ocel chats with Jerry Reghunadh, Senior Director of Enterprise Architecture at Data Nimbus, about leadership, AI adoption, and data-driven decision-making. Jerry shares his career journey, insights on leveraging tools like ChatGPT and Copilot, and strategies for building effective data pipelines. They explore how companies can avoid "analysis paralysis," adopt AI strategically, and evaluate new technologies to solve real-world problems. Tune in for practical advice on aligning innovation with business goals and staying competitive in a rapidly evolving tech landscape. Chapters 00:00 – Introduction 00:31 – Jerry’s Leadership Journey 02:01 – Discussing AI in Leadership 03:59 – Experimenting with AI Tools 06:24 – Overcoming Analysis Paralysis 09:18 – Importance of Early AI Adoption 13:12 – AI’s Impact on Efficiency 14:30 – Sponsor Message 16:26 – Setting Realistic Goals for AI 19:41 – Data Management and AI 23:09 – Is AI Just a Fad? 27:22 – Testing New Technologies 29:56 – Final Thoughts on AI 30:25 – Connect with Jerry 30:44 – Closing Remarks 31:20 – Outro Follow Jerry on Social Media Linkedin: https://www.linkedin.com/in/jerrymannel/ Sponsored by This Dot: thisdot.co...

Nov 18, 2024

1 min

AIEngineering Leadership

Let's innovate together!

We're ready to be your trusted technical partners in your digital innovation journey.

Whether it's modernization or custom software solutions, our team of experts can guide you through best practices and how to build scalable, performant software that lasts.

How to set up local cloud environment with LocalStack

How to set up local cloud environment with LocalStack

Assumptions

What is LocalStack?

Prerequisite

Installation

Testing AWS Services with LocalStack

AWS CloudFormation

AWS SQS

Conclusion

Victor Umeh

You might also like

How to host a full-stack app with AWS CloudFront and Elastic Beanstalk

Building Scalable AI Applications: Insights from AWS's Michael Liendo

Understanding Effects In SolidJS

AI Leadership: Data-Driven Decision Making & Avoiding "Analysis Paralysis" with Jerry Reghunadh

Let's innovate together!

You might also like

How to host a full-stack app with AWS CloudFront and Elastic Beanstalk

Building Scalable AI Applications: Insights from AWS's Michael Liendo

Understanding Effects In SolidJS

AI Leadership: Data-Driven Decision Making & Avoiding "Analysis Paralysis" with Jerry Reghunadh