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

Vercel vs. VPS - What's the drama, and which one should you choose?

Vercel vs. VPS - What's the drama, and which one should you choose? Vercel recently announced an update to their pricing. For some users, that meant a significant increase in costs, which has led to some discussions about the costs of using cloud providers like Vercel, with a few suggesting that a VPS is a far superior and cost-effective solution. Does it make sense to move your popular app to a VPS and save hundreds of dollars? As you might have guessed, the issue is far more nuanced than some tweets suggest. Let's break it down. Integrations Let's talk about the elephant in the room first. Vercel is tailored explicitly for Next.js, providing tooling for conformance checks, continuous deployment, branch previews, and more. All of that works out of the box, and if you were to figure all of that out on your own, you'd be spending a lot of time and money on it, exposing yourself to potential bugs, problems, and disturbances in your workflow. If you're a one-person startup, you may get away with setting up a simple CI/CD pipeline on a VPS, but as your team grows, you'll need to invest more time and money into maintaining it. And that's not even considering the time you'll spend onboarding new team members and teaching them how to use your custom setup. That being said, some tools can make things easier for you and standardize the process. For example, coolify does a great job of providing a simple and easy-to-use interface for deploying Next.js apps to a VPS. You could also deploy a Docker container with all the necessary tools and configurations, but that's another can of worms. There’s also OpenNext adapter that lets you deploy across different environments, such as AWS. While that takes care of the deployment part, it doesn't solve the potential need for other integrations like conformance checks, branch previews, etc. Scaling and Performance Scaling is sometimes overrated in software engineering. Especially at the beginning of a greenfield project, you're better off focusing on building a great product and getting users than worrying about scaling. That said, it's essential to have a plan for scaling when the time comes, not to mention projects that are already popular and are considering moving to a VPS. I'm not saying you can't successfully run a popular high-traffic project built in Laravel from a Debian server in your basement. But I'm also not suggesting that you should optimize your hosting costs at the expense of investing precious time and energy into building and configuring infrastructure that could be better spent on building your product, especially given the fact that most cloud providers offer a free tier that can handle a decent amount of traffic. And there is one more thing to consider. Vercel has a global network of edge nodes that can cache your content and serve it to users from the nearest location, which can significantly improve your app's performance. If your app is targeted at a global audience, serving it from one server located in a single region may provide a suboptimal experience for users in other areas. Edge Nodes Speaking of edge nodes and Vercel, there has been a pretty significant announcement made by Vercel recently. They have moved away from edge rendering back to Node.js. The reason is that while they initially thought it may be worth the trade-off, having your compute resources far away from your database makes the app slower. Furthermore, the cost benefits of edge rendering are less significant than they initially thought. That doesn't mean they moved away from edge nodes completely. Static assets and the essential HTML and CSS are still served by the edge nodes. With networks getting fast and Node.js more performant, however, the argument for having a VPS with a CDN instead of a cloud provider like Vercel becomes more compelling. Skill Requirements Running a VPS requires a certain level of technical expertise. You must know how to set up and configure a server, install and configure software, manage security, monitor performance, and troubleshoot problems. If you're uncomfortable with these tasks, you may spend a lot of time learning and troubleshooting. While learning new things is great, it's not always the best use of your time, especially if you're trying to build a product. Part of the cost of using a cloud provider like Vercel is that they take care of all the technical details so you can focus on building your product. Suppose you're not comfortable with managing servers. In that case, it is worth paying extra for the convenience of not having to worry about it while benefiting from a global network of edge nodes and integrations that can save you time and money in the long run. If you're a developer who enjoys tinkering with servers and learning new things, running a VPS can be a fun and rewarding experience. Similarly, running a VPS may be a good option for you if you're a small team with a dedicated DevOps person who can handle all the technical details. But suppose you're a solo founder or a big company with an abundant budget. In that case, you may be better off using a cloud provider like Vercel that can save you time and money in the long run, allowing you to validate PRs in real-time and comment on a build preview in the process. Security A considerable concern when running a VPS is security. You must keep your server updated with security patches, configure firewalls, monitor logs for suspicious activity, and take other steps to protect your server from attacks. There are a lot of bots out there scanning the internet for vulnerable servers, and if you're not careful, you could end up with a compromised server that's being used to send spam, mine cryptocurrency, or launch DDoS attacks. Most cloud providers take care of these things for you, so you don't have to worry about them. Speaking of DDoS attacks, cloud providers usually have built-in DDoS protection that can help mitigate the impact of an attack. If you're running a VPS, you'll need to set up your own DDoS protection, which can be a complex and expensive process, or set up a CloudFlare in front of your server, effectively giving into a cloud provider anyway. That being said, I have read a few horror stories about landing an enormous bill from a cloud provider after a DDoS attack, so it's not all sunshine and rainbows. However, if you opt for a cloud hosting solution such as Vercel and unfortunately get attacked, remember they can be chill about it and refund some of the costs. Be aware of the possibility of a DDoS attack, though, and set up limits and alerts to prevent it from happening in the first place. Tech Stack Flexibility While you don't have to worry about keeping your server up to date when using a cloud provider, it is unfortunate that most cloud providers are usually late in supporting the newest Node.js versions. Despite Node.js 20 being the latest LTS version, some cloud providers' features still don't support it. If you plan to use bleeding-edge technologies or have specific requirements that cloud providers don't support, you may be better off running a VPS. Cost Finally, let's talk about cost. Running a VPS can be cheaper than using a cloud provider like Vercel, especially if you have a high-traffic app generating a lot of revenue. However, you need to consider the hidden costs of running a VPS, such as the time and money you'll spend on maintaining it, the cost of setting up and configuring a server, the cost of monitoring and troubleshooting problems, and the cost of scaling and performance optimization. If we take a model app that transfers around 1.5 TB of data per month, does a bit of computation, and we apply the new Vercel pricing, it could look something like this: 1. Base Plan Cost: $20 per month 2. Additional Fast Data Transfer: 500 GB x $0.15/GB = $75 (1 TB included in the base plan) 3. Additional Fast Origin Transfer: 50 GB x $0.06/GB = $3 (100 GB included in the base plan) 4. Additional Edge Requests: 2 million x $2/million = $4 (10 million included in the base plan) 5. Additional Function Execution Time: 200 GB-hours x $0.18/GB-hour = $36 (1,000 GB-hours included in the base plan) That would bring our total cost to $138 per month, assuming you pay for only one seat. If we decided to run a VPS instead, we would need something with at least 4 GB RAM, 2 vCPUs, and 80 GB SSD storage. A VPS with those specs would cost around $20 per month. You would also need to add the cost of a CDN, which would amount to $20 per month if you chose the CloudFlare Pro plan. That would bring our total cost to $40 per month. In this case, running a VPS would be significantly cheaper than using Vercel. However, this assumes that you know how much your app will scale in advance or that you're willing to go through the hassle of migrating your application to a larger server when the time comes. The thing is, if you're starting a new project, you could probably start with the free tier of a cloud provider like Vercel, later transfer to the Pro plan, and scale up as needed. In many cases, the appeal of the pay-as-you-go model is worth paying a bit extra in the long run. Conclusion Should you move your popular app to a VPS and save some dollars? The answer is it depends. It all boils down to assessing your project's specific needs, technical expertise, and growth expectations. The recent uproar regarding Vercel's pricing changes has illuminated this dilemma, presenting a classic case of convenience versus cost. Vercel stands out for its seamless integration with Next.js, providing out-of-the-box solutions that significantly reduce the time and effort required for deployment and ongoing maintenance. This convenience is especially valuable for developers leveraging modern development practices with minimal setup. Additionally, Vercel's edge network capabilities offer significant performance benefits for global applications, ensuring faster load times and improved user experience. However, these benefits come at a cost, which can be significantly higher than running a VPS, especially as your application scales. For those with the requisite skills, a VPS can offer a more cost-effective solution without the constraints of a platform-centric approach. This route grants more control over the hosting environment and potentially lowers costs at the expense of increased complexity in setup, scaling, and maintenance. It's also important to consider the non-financial costs associated with each option. Vercel provides a robust, developer-friendly environment that can significantly accelerate development cycles and reduce the burden on your team. On the other hand, managing a VPS requires a steep learning curve and ongoing attention to security, performance, and scalability. TLDR: If you're a solo founder or a small team looking to deploy and scale your application with minimal overhead quickly, Vercel is likely the best choice. If you are a Linux enthusiast or have a dedicated DevOps team, you can create a decent setup with a VPS and a CDN, but be prepared to invest time and effort into maintaining it. If you are a bigger company or team, the decision will likely depend on your specific needs, growth expectations, and budget constraints....

May 8, 2024

8 mins

DevOpsNodeJSJavaScriptVercel

How to automatically deploy your full-stack JavaScript app with AWS CodePipeline

How to automatically deploy your full-stack JavaScript app from an NX monorepo with AWS CodePipeline In our previous blog post (How to host a full-stack JavaScript app with AWS CloudFront and Elastic Beanstalk) we set up a horizontally scalable deployment for our full-stack javascript app. In this article, we would like to show you how to set up AWS CodePipeline to automatically deploy changes to the application. APP Structure Our application is a simple front-end with an API back-end set up in an NX monorepo. The production built API code is hosted in Elastic Beanstalk, while the front-end is stored in S3 and hosted through CloudFront. Whenever we are ready to make a new release, we want to be able to deploy the new API and front-end versions to the existing distribution. In this article, we will set up a CodePipeline to deploy changes to the main branch of our connected repository. CodePipeline CodeBuild and the buildspec file First and foremost, we should set up the build job that will run the deploy logic. For this, we are going to need to use CodeBuild. Let's go into our repository and set up a build-and-deploy.buildspec.yml file. We put this file under the tools/aws/ folder. ` This buildspec file does not do much so far, we are going to extend it. In the installation phase, it will run npm ci to install the dependencies and in the build phase, we are going to run the build command using the ENVIRONMENT_TARGET variable. This is useful, because if you have more environments, like development and staging you can have different configurations and builds for those and still use the same buildspec file. Let's go to the Codebuild page in our AWS console and create a build project. Add a descriptive name, such as your-appp-build-and-deploy. Please provide a meaningful description for your future self. For this example, we are going to restrict the number of concurrent builds to 1. The next step is to set up the source for this job, so we can keep the buildspec file in the repository and make sure this job uses the steps declared in the yaml file. We use an access token that allows us to connect to GitHub. Here you can read more on setting up a GitHub connection with an access token. You can also connect with Oauth, or use an entirely different Git provider. We set our provider to GitHub and provided the repository URL. We also set the Git clone depth to 1, because that makes checking out the repo faster. In the Environment section, we recommend using an AWS CodeBuild managed image. We use the Ubuntu Standard runtime with the aws/codebuild/standard:7.0 version. This version uses Node 18. We want to always use the latest image version for this runtime and as the Environment type we are good with Linux EC2. We don't need elevated privileges, because we won't build docker images, but we do want to create a new service role. In the Buildspec section select Use a buildspec file and give the path from your repository root as the Buildspec name. For our example, it is tools/aws/build-and-deploy.buildspec.yml. We leave the Batch configuration and the Artifacts sections as they are and in the Logs section we select how we want the logs to work. For this example, to reduce cost, we are going to use S3 logs and save the build logs in the aws-codebuild-build-logs bucket that we created for this purpose. We are finished, so let's create the build project. CodePipeline setup To set up automated deployment, we need to create a CodePipeline. Click on Create pipeline and give it a name. We also want a new service role to be created for this pipeline. Next, we should set up the source stage. As the source provider, we need to use GitHub (version2) and set up a connection. You can read about how to do it here. After the connection is set up, select your repository and the branch you want to deploy from. We also want to start the pipeline if the source code changes. For the sake of simplicity, we want to have the Output artefact format as CodePipeline default. At the Build stage, we select AWS CodeBuild as the build provider and let's select the build that we created above. Remember that we have the ENVIRONMENT_TARGET as a variable used in our build, so let's add it to this stage with the Plaintext value prod. This way the build will run the build:prod command from our package.json. As the Build type we want Single build. We can skip the deployment stage because we are going to set up deployment in our build job. Review our build pipeline and create it. After it is created, it will run for the first time. At this time it will not deploy anything but it should run successfully. Deployment prerequisites To be able to deploy to S3 and Elastic Beanstalk, we need our CodeBuild job to be able to interact with those services. When we created the build, we created a service role for it. In this example, the service role is codebuild-aws-test-build-and-deploy-service-role. Let's go to the IAM page in the console and open the Roles page. Search for our codebuild role and let's add permissions to it. Click the Add permissions button and select Attach policies. We need two AWS-managed policies to be added to this service role. The AdministratorAccess-AWSElasticBeanstalk will allow us to deploy the API and the AmazonS3FullAccess will allow us to deploy the front-end. The CloudFrontFullAccess will allow us to invalidate the caches so CloudFront will send the new front-end files after the deployment is ready. Deployment Upload the front-end to S3 Uploading the front-end should be pretty straightforward. We use an AWS CodeBuild managed image in our pipeline, therefore, we have access to the aws command. Let's update our buildspec file with the following changes: ` First, we upload the fresh front-end build to the S3 bucket, and then we invalidate the caches for the index.html file, so CloudFront will immediately serve the changes. If you have more static files in your app, you might need to invalidate caches for those as well. Before we push the above changes up, we need to update the environment variables in our CodePipeline. To do this open the pipeline and click on the Edit button. This will then enable us to edit the Build stage. Edit the build step by clicking on the edit button. On this screen, we add the new environment variables. For this example, it is aws-hosting-prod as Plaintext for the FRONT_END_BUCKET and E3FV1Q1P98H4EZ as Plaintext for the CLOUDFRONT_DISTRIBUTION_ID Now if we add changes to our index.html file, for example, change the button to HELLO 2, commit it and push it. It gets deployed. Deploying the API to Elastic Beanstalk We are going to need some environment variables passed down to the build pipeline to be able to deploy to different environments, like staging or prod. We gathered these below: - COMMIT_ID: #{SourceVariables.CommitId} - This will have the commit id from the checkout step. We include this, so we can always check what commit is deployed. - ELASTIC_BEANSTALK_APPLICATION_NAME: Test AWS App - This is the Elastic Beanstalk app which has your environment associated. - ELASTIC_BEANSTALK_ENVIRONMENT_NAME: TestAWSApp-prod - This is the Elastic Beanstalk environment you want to deploy to - API_VERSION_BUCKET: elasticbeanstalk-us-east-1-474671518642 - This is the S3 bucket that was created by Elastic Beanstalk With the above variables, we can make some new variables during the build time, so we can make sure that every API version is unique and gets deployed. We set this up in the install phase. ` The APP_VERSION variable is the version property from the package.json file. In a release process, the application's version is stored here. The API_VERSION variable will contain the APP_VERSION and as a suffix, we include the build number. We want to upload this API version by indicating the commit ID, so the API_ZIP_KEY will have this information. The APP_VERSION_DESCRIPTION will be the description of the deployed version in Elastic Beanstalk. Finally, we are going to update the buildspec file with the actual Elastic Beanstalk deployment steps. ` Let's make a change in the API, for example, the message sent back by the /api/hello endpoint and push up the changes. --- Now every time a change is merged to the main branch, it gets pushed to our production deployment. Using these guides, you can set up multiple environments, and you can configure separate CodePipeline instances to deploy from different branches. I hope this guide proved to be helpful to you....

Sep 15, 2023

9 mins

AWSNxNodeJSJavaScript

How to Handle Async Data Fetching Using CreateResource in SolidJS

In this article, you will learn how to handle async data fetching using createResource in SolidJS. The article assumes that you have a basic understanding of SolidJS. If you need a refresher, I recommend looking at the official SolidJS website to get started with SolidJS. You can also visit solidjs.framework.dev/ for a list of SolidJS libraries and resources. What is createResource? createResource is a special Signal designed specifically to handle async data fetching. Signals are the cornerstone of reactivity in SolidJS. They contain values that change over time, but unlike typical values, Signals are also event emitters. When the data kept in the Signal is changed, the Signal emits events in the system so things that depend on the Signal value can be notified. Signals are similar to “observables'', “streams”, or “subjects” in other reactive programming technologies. For more information on Signals, check out the SolidJS Documentation. The purpose of createResource is to wrap async values (any value that returns as a promise) in a way that makes them easy to interact with in Solid's execution model. This is useful because it ensures that the async function is non-blocking. How does createResource work? For createResource to work, it needs an argument which is a function that returns a promise. It returns a data getter that wraps the value returned from the fetcher function. Easy right? The resulting Resource Signal (products) also contains reactive loading and error properties that make it easy to control the view based on the current status. Let’s see how all of these are used in an example. In this example, we created a fetcher function that makes a call to get a list of products, and this function is passed in as an argument to createResource. createResource returns a Signal which has reactive properties like loading, error, latest, etc. We use the properties to conditionally render JSX based on the current reactive state. createResources can also take in a source Signal as the first argument and the async fetcher function as the second. The source Signal is provided as the query to the async fetcher function which returns a promise. A change in the source Signal calls an internal fetch method to fetch new data based on the change. If you are familiar with React-query, source Signals are similar to query keys. Let’s write an example that fetches users’ profiles from GitHub. It takes the username as input and returns the user’s profile details. Here we are fetching a GitHub user’s info. We have an input field that receives the username and set it as a Signal. The createResource takes the source Signal as the first argument and the async fetcher function as the second argument. An internal fetch method will be called anytime the Signal value changes. So if we enter a different username into the input field, createResource is aware of that change, and fetches new data based on the new Signal value. Refetch and Mutate The second value that comes back from createResource contains a mutate method for directly updating the internal Signal, and a refetch method to reload the current query even if the source hasn't changed. Mutate is useful for "optimistic mutations" like when you want to automatically update a todo list that is fetched from the server when someone clicks the add button. Refetch is useful when you know the data returned from the server changes constantly and you would like to get the latest information. For example, if you are building an application that needs to show the current price of Bitcoin in US dollars, you will need to refetch the data because the prices fluctuate. Why is createResources special? For small examples, createResource can be as simple as just setting a Signal. However, it interacts with the broader Solid framework in different ways: When your app is server-side rendered, createResource is fetched on the server while effects and Signal setters aren't, so resources work a lot better with solid start. Any loading resources will put your app in suspense mode which can automatically provide benefits when interacting with the Solid router. Conclusion In this article, we saw how to handle async data fetching using createResource. We also explored some use cases, and when and how to use some properties and methods returned by createResource. You can find the live example for this blog post on StackBlitz. If you would like to learn more about SolidJS, check out solidjs.framework.dev for a list of libraries and resources....

Feb 27, 2023

5 mins

JavaScript

Svelte 5 is Here!

Svelte 5 was finally released after a long time in development. Fortunately, we've been able to test it for some time, and now it has a stable release. Let's dig into its features and why this is such a significant change, even though Svelte 4 code is almost 100% compatible. Svelte syntax everywhere This is one of my favorite additions. Previously, Svelte syntax was limited to a component element. Refactoring code from a component and moving it to a JavaScript file worked differently. Now you can use the .svelte.js or .svelte.ts extension, which allows you to use the same syntax everywhere. It's important to note that it's a way to express that this is not just JS, and what you write may be compiled to something else, just like .svelte files are not just html even though they look very similar. Runes The introduction of runes is one of the most significant changes in Svelte. Many users felt attracted to variables being instantly reactive in previous versions. ` There was, however, a lot of magic underneath and a considerable amount of work from the compiler to make it behave reactively. $state In Svelte 5, a reactive variable has to be explicitly declared using the $state rune, which brings a clear distinction between what is reactive and what isn’t. ` In the previous code, $state is not an actual function being called; it's a hint for the compiler to do something special with this declaration. Rune names always start with a dollar sign ($) and do not need to be imported. However, there’s much more to the changes than just the way we declare reactive variables. Runes bring a lot of new features that make Svelte 5 a great improvement. In Svelte 5, objects or arrays use Proxies to allow for granular reactivity, meaning that individual properties in an object are reactive, even if they are nested objects or arrays. If you modify a property, it will only update that property and will not trigger an update on the whole object. It also supports triggering updates when methods like array.push are called. In previous versions, an assignment was required to trigger an update: ` To have a similar behavior of svelte 4 (no deep reactivity), use the $state.raw() rune. This syntax of .* is common for related features of a rune: $state.raw() will require an assignment to trigger reactivity. ` Because proxies are used, you may need to extract the underlying state instead of the proxy itself. In that case, $state.snapshot() should be used: ` $derived We will use $derived and $derived.by to declare a derived state. The two runes are essentially the same, except one allows us to use a function instead of an expression, allowing for more complex operations to calculate the derived values. ` $effect Effects are useful for running something triggered by a change in state. One of the things you'll note from the $effect rune is that dependencies don't need to be explicit. Those will be picked from reactive values read synchronously in the body of the effect function. ` Something to bear in mind is that these dependencies are picked each time the effect runs. The values read during the last run become the dependencies of the effect. ` Depending on the result of the random method, foo or bar will stop being a dependency of the effect. You should place them outside the condition so they can trigger reruns of the effect. *Variants* of the effect rune are $effect.pre, which runs before a DOM update, and $effect.tracking(), which checks for the context of the effect (true for an effect inside an effect or in the template). $props This rune replaces the export let keywords used in previous versions to define a component's props. To use the $props syntax, we can consider it to return an object with all the properties a component receives. We can use JavaScript syntax to destructure it or use the rest property if we want to retrieve every property not explicitly destructured.. ` $bindable If you want to mutate a prop so that the change flows back to the parent, you can use the $bindable prop to make it work in both directions. A parent component can pass a value to a child component, and the child component is able to modify it, returning the data back to the parent component. ` $inspect The $inspect rune only works in dev mode and will track dependencies deeply. By default, it will call console.log with the provided argument whenever it detects a change. To change the underlying function, use $inspect.with().with): ` $host The host rune gives access to the host element when compiling as a custom element: ` ` Other changes Another important change is that component events are just props in Svelte 5, so you can destructure them using the $props() rune: ` A special children property can be used to project content into a component instead of using slots. Inside the components, use the [@render[(https://svelte.dev/docs/svelte/@render) tag to place them. ` Optional chaining (?.) prevents from attempting to render it if no children are passed in. If you need to render different components in different places (named slots before Svelte 5, you can pass them as any other prop, and use @render with them. Snippets Snippets allow us to declare markup slices and render them conveniently using the render tag (@render). They can take any number of arguments. ` Snippets can also be passed as props to other components. ` ` Conclusion Some exciting changes to the Svelte syntax were introduced while, at the same time, maximum compatibility efforts were made. This was a massive rewrite with numerous improvements in terms of performance, bundle size, and DX. Besides that, a new CLI has been released, making the whole experience of starting a project or adding features delightful. If you haven't tried Svelte before, it's a great time to try it now....

Nov 27, 2024

4 mins

Svelte

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

Vercel vs. VPS - What's the drama, and which one should you choose?

How to automatically deploy your full-stack JavaScript app with AWS CodePipeline

How to Handle Async Data Fetching Using CreateResource in SolidJS

Svelte 5 is Here!

Let's innovate together!

You might also like

Vercel vs. VPS - What's the drama, and which one should you choose?

How to automatically deploy your full-stack JavaScript app with AWS CodePipeline

How to Handle Async Data Fetching Using CreateResource in SolidJS

Svelte 5 is Here!