LocalStack Interacting with Client Code

LocalStack Interacting with Client Code

·

2 min read

Using Docker for local development offers several advantages: isolation, consistency, reproducibility, efficiency, portability, easy cleanup, and security. You get the gist.

These are also the great advantages of LocalStack shipping as a Docker image.

Let’s say your product is a multi-functional web application that does all sorts of operations for your clients. The backend is handled by AWS-managed services, so your main focus is providing the best user experience possible. For the development phase, your setup would look something like this diagram, the center of attention being the React app, while the rest are necessary dependencies:

A new frontend engineer is joining the team and they want to get their setup running as fast as possible so that they can start making much-needed improvements to the app. Of course, they would say that talk is cheap, they want to see the code:

  1. Clone the repository:

     git clone https://github.com/tinyg210/stack-bytes-apigw-lambda-s3.git
    
  2. Switch to the module folder:

     cd stack-bytes-apigw-lambda-s3/frontend-client-local-machine
    
  3. Run the preconfigured docker-compose file in detached mode:

     docker compose up -d
    
  4. Install the React app dependencies:

     npm install
    
  5. Run the web application:

     npm start
    

That’s it. In just five easy steps your new developer can start understanding and working on the app. No need for days of waiting to obtain all the necessary credentials and permissions for a new AWS account and no accidental cost spikes for learning purposes.

We can now see that our sophisticated app is running on localhost:3000. It is communicating with the API Gateway, which uses 2 separate Lambdas for creating and fetching, and an S3 bucket for storing the text files that contain the quotes that we want to remember forever. The reason why everything was so fast is a combination of features that are there to enhance the developer experience. The docker-compose file simply requests the LocalStack image, makes sure the right ports are exposed, and adds some configs regarding the network and access to the Docker socket (we’ll talk about it soon). But the more important parts lay in these lines:

volumes:
      - "../stack-bytes-lambda/target/apigw-lambda.jar:/etc/localstack/init/ready.d/target/apigw-lambda.jar"
      - "../init-resources.sh:/etc/localstack/init/ready.d/init-resources.sh"

These are the init hooks that ensure the needed resources are created at startup.

From here on, the endpoints are quickly configured for local development, and everything is set:

Notice how fast getting someone onboarded is. This combination facilitates swift resource replication across multiple environments, enabling rapid team integration and productive collaboration. 👍