In this blog post, I’ll walk you through the steps for setting up continuous replication of an AWS CodeCommit repository from one AWS region to another AWS region using a serverless architecture. CodeCommit is a fully-managed, highly scalable source control service that stores anything from source code to binaries. It works seamlessly with your existing Git tools and eliminates the need to operate your own source control system. Replicating an AWS CodeCommit repository from one AWS region to another AWS region enables you to achieve lower latency pulls for global developers. This same approach can also be used to automatically back up repositories currently hosted on other services (for example, GitHub or BitBucket) to AWS CodeCommit.
This solution uses AWS Lambda and AWS Fargate for continuous replication. Benefits of this approach include:
- The replication process can be easily setup to trigger based on events, such as commits made to the repository.
- Setting up a serverless architecture means you don’t need to provision, maintain, or administer servers.
- You can incorporate this solution into your own DevOps pipeline. For more information, see the blog Invoke an AWS Lambda function in a pipeline in AWS CodePipeline.
Note: AWS Fargate has a limitation of 10 GB for storage and is available in US East (N. Virginia) region. A similar solution that uses Amazon EC2 instances to replicate the repositories on a schedule was published in a previous blog and can be used if your repository does not meet these conditions.
async/await freed us from callback hell, but people have started abusing it — leading to the birth of async/await hell.
In this article, I will try to explain what async/await hell is, and I’ll also share some tips to escape it.
What is async/await hell
I’ve been helping out on a project recently where we’re doing a number of integrations with third-party services. The integration platform is built on AWS Lambda and the Serverless framework.
Aside from the data hygiene questions that you might expect in an integration project like this, one of the first things we’ve run into is a fundamental constraint in productionizing Lambda-based systems. As of today, AWS Lambda has the following limits (among others):
- max of 1000 concurrent executions per region (a soft limit that can be increased), and
- max duration of 5 minutes for a single execution
In May the European Union’s General Data Protection Regulation goes into effect, two years after passage by the European Parliament. This radical new privacy law, which covers any business that processes information about EU residents, will dramatically affect the way data is collected, stored, and used, including for U.S. companies doing business abroad.
In the U.S., lawmakers are now circling waters bloodied by revelations regarding potential abuse of Facebook’s social media data, with CEO Mark Zuckerberg scheduled to testify on Capitol Hill this week about the “use and protection of user data.” Facebook’s woes, following continued reports of major data breaches at other leading companies, have amplified calls for GDPR-like legislation in the U.S.
This project intends to provide a complete description and re-implementation of the WhatsApp Web API, which will eventually lead to a custom client. WhatsApp Web internally works using WebSockets; this project does as well.
With iOS 11.3, Apple has silently added support for the basic set of new technologies behind the idea of “Progressive Web Apps” (PWAs). It’s time to see how they work, what are their abilities and challenges, and what do you need to know if you already have a published PWA.