AWS Boto3 is the Python SDK for AWS. Boto3 can be used to directly interact with AWS resources from Python scripts. In this tutorial, we will look at how we can use the Boto3 library to perform various operations on AWS SQS.
AWS Boto3 is the Python SDK for AWS. Boto3 can be used to directly interact with AWS resources from Python scripts. In this tutorial, we will look at how we can use the Boto3 library to perform various operations on AWS EC2.
AWS Relational Database Service (RDS) is a managed database service that was launched almost 10 years ago. Over the last 10 years, application patterns have evolved which has led to various challenges when it comes to interacting with the database:
- Applications, especially serverless applications, have a large number of open DB connections. RDS only allows a limited number of open connections.
- Custom failure handling code can become hard to manage and error-prone. Handling database failovers is one such example of handling failures.
AWS RDS proxy is a fully-managed database proxy for Amazon RDS. RDS proxy works by pooling and sharing DB connections and thus makes applications more scalable as well as resilient to database failures. They key benefits of using RDS proxy are:
- Connection pooling and sharing: Improves application performance by reducing the number of open database connections
- RDS proxy helps improve application availability during failure scenarios such as a database failover.
- RDS Proxy gives you the choice to use IAM authentication for connecting to the database, thus removing the need for database credentials in the application code.
RDS proxy is currently available for Aurora MySQL, Aurora PostgreSQL, RDS MySQL and RDS PostgreSQL.
AWS’ Boto library is used commonly to integrate Python applications with various AWS services such as EC2, S3, and SQS amongst others. I have generally avoided writing unit-tests for application code that interacts with the boto library because of the complexity involved in mocking and testing these functions.
However, I recently tried out the Moto library which makes it easy to mock AWS services and test code that interacts with AWS.
Some of the benefits of using Moto:
- Testing code that interacts with AWS. Instead of having to test your code in an AWS environment, test AWS interactions locally.
- Easy to learn and get started with.
- Extensive coverage of AWS services.
In this article, we will look at how to add unit tests using Moto.
Zapier is a no-code workflow automation tool that can be used to integrate apps and make them work together. I have been using Zapier for a bunch of my side projects and it was been pretty useful to hook up services like Stripe with Gmail. However, I recently started hitting their free tier limits and started exploring the possibility of building a simple Zapier alternative, mostly for fun.
The requirements that I came up with :
- Completely serverless: I don’t want to manage any infrastructure
- (almost) Free: It should cost close to $0 for my use-case which I will talk about below.
- Multi-step workflows: Currently, Zapier’s free tier only lets you perform one action for a particular trigger. I wanted the ability to perform multiple actions (for e.g. send an email and a slack message) for a particular trigger.
- Webhooks support: I’m a big fan of Zapier’s webhooks functionality and want to replicate that.
- Polling-based workflows: Ability to poll an API endpoint and take action if there is new data available