In the last two articles (here and here) we implemented some of the Serverless Patterns described in this article from Jeremy Daly. In this article, we’re going to concentrate in just one pattern, the Notifier. We’re going to do this, because of the [recent announcement] from AWS that you can now use an SQS queue as a Dead Letter Queue for an SNS topic. If you read the article, you will see that this DLQ is complementary to the DLQ you might define in a function that is triggered by an SNS topic, as Otavio Ferreira explains here.

In this article I will continue with the implementation of some Serverless Patterns described in this article from Jeremy Daly about [Serverless Patterns]. Check the first post here Let’s start! Common setup All the projects will have a common setup, which is fairly simple. First, initialize a NodeJS project: yarn init Then install the serverless framework as a dev dependency yarn add serverless --dev And finally create a script to deploy the project

I think that the best way to learn something is to practice it and to try to explain it, so this is what I’m going to do in the next series of posts. These posts will be based on the amazing article from Jeremy Daly about Serverless Patterns. I’m not going to copy Jeremy’s words here, so for each pattern, go to the article and read it. I’ll provide a technical implementation here and I will mention more resources I found interesting.

Congratulations! Your startup is starting to bring attention to many people and you’re starting to have clients from different countries and continents. But your lambdas and API gateway are still in your initial region, and that might add some latency to some users. Apart from that, you want to increase the reliability of your system. So, you decide to go multi-region. Can you do that easily? In this article, we’ll see how to do that.

If you’re doing something more than a few tests with Lambda and API Gateway, there will be a time where you will like to stop using the AWS-created endpoints for your APIs and start using your own domain. You know, instead of telling your clients, “please, go to https://lk7z14x78h.execute-api.eu-west-1.amazonaws.com/dev/helloWorld", you will like to point them to something like “api.authenticatedservices.net/helloWorld”. In this article, we’ll see how to do that. Disclaimer This article is a summary of two articles (this one and this one) from Alex DeBrie (who you should follow if you’re interested in serverless).

In the previous article, we saw how to secure an API Gateway endpoint using Cognito user pools. We used the built-in capabilities of the user pools to create the users, sign them up, etc. But many applications nowadays don’t create users on their own; they use [social login] and rely on third-party social services such as Facebook or Google to manage users for them. In this article, we’ll see how we can adapt our previous code to allow users to sign-up and sign-in to our service using their Google account.

In many occasions, you don’t want your whole API open to the public. Maybe you want to make some endpoints available to authenticated users. In this article we’re going to see how to do that using Amazon Cognito User Pools and AWS Amplify. Let’s start! Amazon Cognito User Pools As the documentation says, a user pool is a user directory in Amazon Cognito. You can allow your users to sign-up, sign-in, etc.

My good friend Edu Ferro has a very nice blog called eferro’s random stuff in which he posts the most interesting blogs, talks and podcasts he’s read, viewed and heard lately. I like the idea and, now that I have a bit more free time, I’ll try to do the same, at least once every month. I’m not going to post here podcasts and talks, basically because all the ones I listen I get them from Edu’s blog, so I’m just going to concentrate in blogs.

Last September I turned 40. You know, in the movies, when someone turns forty he buys a new brand card, gets divorced and tries something new. I still don’t have a car and, although I’m not married, I still live with my partner, but I did start something new. In my case, was an old “aspiration” (I tried it 7 years ago): learning to play guitar. Not that I want to be the next Angus Young but I never had any musical education and I always wanted to be able to play an instrument, especially guitar.

In the last article we talked about securing Azure Functions and we saw how to insert a message into an Event Hub. To insert the message, we needed the connection string to be in an application setting. This is not the most secure way to store a connection string. We talked that it would be a much better option to store it in Key Vault. Until a couple of days ago, to do that we needed to use a library to get the secret from Key Vault and then use an imperative binding to be able to insert the message into the Event Hub.