Hi Reader ππ½,
I hope you are alright and you're enjoying the summer.
Tobi & I are currently thinking hard about what comes next. In the past few months, we focused on publishing more content on our blog & social media. We want to have as much high-quality content covering AWS as possible. But we do see a lack of hands-on projects that can be used in the real world. We're not only talking about a simple API with a Lambda function. But about projects that are required if you work for a company. Setting up a landing zone, configuring the identity center (SSO), and setting up a proper development workflow with sandbox accounts. We feel like this is missing a lot. We'll probably focus on that in the near future π
Enough about our thoughts, let's dive right into today's topic: API Gateway.
Here is a one-pager about API Gateway.
β
AWS API Gateway is a fully-managed API from AWS. It is a crucial part of your serverless applications because it acts as the front door to the internet.
AWS API Gateway has a lot of different options and configuration opportunities. For example:
API Gateway is beginner-friendly as itβs easy to deploy your first API and there are no upfront or idling costs you need to fear.
AWS API Gateway comes in three different flavors, with very different feature sets and different pricing. A small wrap-up before going into details:
As said before, API Gateway is not just an HTTP mediator - itβs a feature-rich, high-value, and little error-prone front door to your applications ecosystem.
When working with REST or HTTP gateways, an API consists of programmable resources that can be mapped to specific HTTP methods and paths. These resources are connected to integration endpoints where requests are forwarded. Transformations can be applied to modify requests according to the backend's expectations, including validations. After receiving the response from the integration, response transformations can be applied before returning it to the client.
API Gateway provides powerful authorizer capabilities for authentication and authorization. Let's explore two key options:
By leveraging these authorizers, you can secure your APIs, protect routes and methods, and customize the authentication and authorization process to suit your specific requirements.
Weβve learned about the different API Gateway types, which leads us to two prominent use cases.
The typical web application is a client-server combination: a frontend, e.g. a web page or a mobile app. A backend server to communicate with the frontend.
On the serverless side, your backend is a construct of one or multiple Lambda functions that include your business logic. Exposing those functions to the internet is done via a REST or HTTP API Gateway that allows you to actively enforce rate-limiting, request validation, transformation, routing, authentication, and authorization without writing much or any code at all.
Many applications require real-time communication between the clients and the backend. If you look at messaging apps, you donβt want all your clients to actively poll for new messages every few seconds as it causes unnecessary server load and also causes a high latency between a message that has been sent and the actual delivery at the receiver.
With WebSockets API Gateway a client can open a connection to the gateway that is fully managed by the gateway itself. The only thing that needs to be actively implemented is how connection events are handled and what you want to do with those connections. A common pattern is to save the connection identifiers that are provided by the gateway to DynamoDB. Via a connection identifier, you can actively push messages to the corresponding client.
We hope you enjoyed this issue. Let us know what you think about this issue and our future plans with the AWS Fundamentals Community π―
β
Join our community of over 8,800 readers delving into AWS. We highlight real-world best practices through easy-to-understand visualizations and one-pagers. Expect a fresh newsletter edition every two weeks.
β Reading time: 12 minutes π Main Learning: CloudWatch Launches re:invent 2024 βοΈ Read the Full Post Online π Hey Reader ππ½ re:invent happened already two weeks ago and there were some amazing launches π CloudWatch got a lot of love at that re:invent. This is why we are showing you our top CloudWatch launches for this year. We've worked through all of them, tried to get them working with our example application of the CloudWatch Book, and are now busy updating the book βπ½. Let's dive into...
β Reading time: 14 minutes π Main Learning: Feature Flags with AWS AppConfig πΎ GitHub Repository βοΈ Read the Full Post Online π Hey Reader ππ½ There's no other field where it's so common to have "a small side-project" like in the software industry. Even though it's possible to build things as quickly as ever before due to cloud providers, tools, platforms, and AI, many indie founders (and also large enterprises) tend to fall into the same trap: they tend to build features that users do not...
β Reading time: 17 minutes π Main Learning: Observability at Scale with Open-Source πΎ GitHub Repository βοΈ Read the Full Post Online π Hey Reader ππ½ Welcome to this edition of the AWS Fundamentals newsletter! In this issue, we're focusing on observability with open-source tools on AWS. As most of you already know, we can use Amazon CloudWatch and X-Ray to monitor our application from every angle. But what if we want to hybrid setup where we run certain parts of our ecosystem outside of AWS?...