Hi friends of the cloud 👋

first things first: we've put in the hard work in the last weeks and finally moved to the final stages, having all of our chapters proof-read for the last time!

For giving you a few insights into our last few weeks, which not only consisted of iterating chapters but also with heavily underestimating seemingly small things:

• converting into different formats, like PDF, mobi and ePub is not easy 🙈
• it takes a lot of iterations to move a chapter from a first draft into something that's really worth sharing 📚
• there are great tools out there for everything, but it still takes time and effort 👩‍💻
• you can't plan for everything, e.g. the incoming sun-down of Revue. For us this was quite positive, as we completely moved to ConvertKit - what a great product! 🌟

... and much more 😜

Nevertheless: we're here now and we'll release in January 2023. You'll receive another email within the next days about the final date. 📤 🎉

I hope you're already as excited as we are! 🙏

Let's finish this newsletter with an introduction to AWS API Gateway! 🏗 It's a small extract from the upcoming book! 📚

​

---

​

AWS API Gateway - Not Just A Simple HTTP Mediator

AWS API Gateway is another crucial part of serverless applications on AWS. It’s a fully-managed service that acts as a front door for the internet to your application’s ecosystem.

Contrary to other methods that allow exposure to the internet, like Lambda function URLs, it’s not only a simple way to trigger invocations via external sources but also does access control, data transformations, rate-limiting, and much more. It’s also not limited to Lambda functions but many other AWS services or any backend that speaks HTTP.

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.

Finding the Right Gateway Type

AWS API Gateway comes in three different flavors, with very different feature sets and different pricing. A small wrap-up before going into details:

• REST: a collection of HTTP resources and methods that map down to other AWS services like Lambda. It’s the most common and flexible gateway type and does help you to do many otherwise tedious tasks like request validation or data transformations without writing any code.
• HTTP: comparable to REST, but comes with a reduced set of features. It’s drastically cheaper though and easier to set up in the first place — a preferable choice for most Serverless applications.
• WebSockets: for building real-time applications with the publish/subscribe pattern. It allows you to push messages via steadily open communication channels in both directions. AWS API Gateway does the heavy lifting of managing your connections so you can focus on building your application.

REST Gateway for full-fledge APIs that reduce boilerplate code in your backend applications

The high-value benefits of managed services are not only about not having to operate underlying infrastructure and therefore reducing your costs for operations. It’s also about generally reducing the need for a lot of boilerplate implementation code that can be error-prone and conflicting in many ways.

And that’s exactly what all AWS API Gateway types do very well as it comes with many no or low-code but high-value features that neither require deep knowledge nor long experiences.

HTTP Gateway for simple, cheap and secure applications expose

HTTP APIs are designed for a minimal feature set, increasing the speed to deploy your first API while not having to fear high costs per API call. As with REST Gateways, HTTP Gateways are also RESTful API products allowing you to map HTTP resources and methods to your AWS services.

WebSockets for Real-Time communication between Clients and Servers

Imagining web applications, we mostly think about clients like browsers or mobile apps that are making HTTP calls to exposed services and afterward wait for the responses.

Depending on the connections between the client and the server, this includes low or high latencies as each request involves a complete roundtrip between the client and server. Also, connections are not steadily kept open, so initial requests can take longer due to TLS handshakes that are rather compute-intense. If clients are actively waiting for data to update, they need to regularly poll and cause load on your servers even if the data didn’t update yet.

But that’s not the only client-server communication option.

WebSockets enable you to keep steady connection channels between your application and your client that allow sending messages in both directions. This allows you to actively push messages to clients. With the publish/subscribe pattern, you can easily cluster clients to manage which data clients should receive.

Use Cases

We’ve learned about the different API Gateway types, which leads us to two prominent use cases.

Exposing your Serverless Applications to the Internet

The typical web application is a client-server combination: a frontend - regardless if it’s a web page or mobile app - that communicates via a backend via HTTP. 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 and transformation, routing, authentication, and authorization without writing much or any code at all.

Real-Time Communication Between Your Clients and Your Backends

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.

Understanding the Different Steps That a Request Passes Through

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 application's ecosystem.

If looking at REST or HTTP gateways, an API is a collection of programmable resources. Those resources can map to one or several HTTP methods and to a path that is either very specific or does contain a proxy wildcard so it covers a set of paths.

Each of those resources needs to be connected to an integration endpoint to which a request will be forwarded. This can be for example a Lambda function or any HTTP-speaking endpoint. You can choose to either forward the request as-is or apply transformations that will modify the request in a way that the corresponding backend expects it to be. This can also include validations. After the response is received from the integration, you can apply response transformations before it’s returned to the client.

A wrap-up about all those core capabilities which will be explored in detail in the next paragraphs:

• Endpoint creation - setting up an API and configuring HTTP routes and methods
• Access Control - authenticating and authorizing requests to protect your APIs and allow a secure multi-tenant usage of your application.
• Integrations - integrate your API method with a backend.
• Request Validation - validate your request before sending it to your destination and save the boilerplate code at your backends.
• Data Transformations - apply data mapping templates to automatically convert request data to expected inputs.
• Gateway Responses - apply mappings to convert outputs to expected responses.
• CORS - set up cross-domain rules to allow integration of your API endpoints in different web touch-points.
• Deploying APIs - deploying your APIs to the internet.
• Caching - cache requests to lower latencies.
• Monitoring - track the requests to your API endpoints.

[...]

---

​

That's it for today.

We already wish you a great & successful new year! 🎊

All the best,​
Sandro & Tobi 💛