Gregor Hohpe said something that has me mulling over for some time now. Essentially, he asked, “Should we narrow the definition of serverless to mean just function-as-a-service (FaaS)?” “Serviceful” For context, I’m firmly in the “serverless means serviceful” camp: a) Serverless is a mindset: To leverage managed services to deal with undifferentiated heavy lifting so …
Should “serverless” just mean “function-as-a-service”? Read More »
Real-time applications have become increasingly popular, and most of us use one or more real-time chat applications, such as WhatsApp.
One of the key challenges with these applications is efficiently managing user connections. We might have a large number of connected users, but these connections are idle most of the time.
Unfortunately, many services that offer WebSockets support (such as API Gateway, AppSync and IoT Core) charge for connection time. It means we have to pay to keep users connected, even when they aren’t actively sending or receiving messages.
This can become very inefficient as our application scales. And that’s where Momento Topics come in!
Real-time notifications have become a big part of modern applications. They let us push updates to users instantly and are essential part of messaging apps, social media and online games.
It’s one of the most common use cases for WebSockets.
But building a WebSockets system that can scale to millions of concurrent users is no small task!
In this guide, we will see how Momento Topics abstract away the hard parts of WebSockets and makes it easy to add real-time features to your application with a few lines of code.
Many apps have leaderboards nowadays. From games to fitness apps that display step counts among friends. It’s a common way to gamify applications!
However, building a scalable leaderboard service can be challenging. A common approach is to model a leaderboard as a Redis sorted set, but that means managing infrastructure and paying for uptime for the Redis cluster.
Only if there’s a truly serverless caching solution that gives you pay-per-use pricing ;-)
In this post, we look at how you can implement fine-grained access control using Cognito access tokens and scopes. We will discuss the trade-offs of this approach and the cost implications of enabling Cognito’s Advanced Security Features (required for this approach to work).
Personally, I think this is too costly an approach and doesn’t offer enough upside in return.
Unless you’re using Advanced Security Features already, or your application has a high value per user (e.g. a B2B enterprise application), this approach may be difficult to justify in terms of return on investment.
A common narrative is that one should always use access tokens to call your APIs, while ID tokens are strictly for identifying users.
But how much of that actually makes sense when you use Cognito authorizers with your API?
Are ID tokens inherently less secure?
What is the cost of using access tokens instead?
Ultimately, is it safe to use ID tokens, or should you switch to access tokens?
Authentication and authorization are two distinct things.
API Gateway has built-in integration with Cognito, which handles authentication, but no fine-grained authorization.
There are many ways to implement a fine-grained authorization with API Gateway. In this new post, I will show you one of these ways and give you the pros & cons and when to use it.
This is a cost-efficient approach that leverages Cognito, but without needing its more expensive Advanced Security Features.
Back in 2018, I shared several ways to implement fan-out/fan-in with Lambda. A lot has changed since, so let’s explore the solution space in 2024.
Remember, what’s “best” depends on your context. I will do my best to outline the trade-offs you should consider.
Many students and clients have asked me how to implement Map-Reduce workloads serverlessly. In most cases, they are actually asking about Fan-Out/Fan-In!
At a glance, the two patterns look very similar and they are often used interchangeably in conversations. So in this post, let’s compare them and see how they differ.
If you’re using CDK, you should use L3 constructs to encapsulate common patterns and best practices in your architecture.
However, sometimes you’d find a 3rd-party L3 construct that does most of what you want, but you need to customize how it configures some of its resources. That can be tricky because you don’t own the source code, and the construct author might not be willing to make the changes you want.
In this article, let me show you an easy and effective way to do this without having to clone and maintain a copy of the construct yourself.
By continuing to use the site, you agree to the use of cookies. more information
The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.