Learn how to implement API versioning effectively. Explore strategies to manage multiple versions without complicating your code.

TheBurningMonk's blog is a platform for sharing insights and expertise in cloud computing, serverless architecture, and distributed systems design. Through articles, tutorials, and case studies, TheBurningMonk offers insights into building scalable, resilient, and cost-effective cloud-native applications using serverless technologies. Readers can learn about architectural patterns, deployment strategies, and best practices for designing serverless applications that leverage the scalability and flexibility of cloud platforms. Additionally, TheBurningMonk provides updates on the latest developments in serverless frameworks, cloud services, and event-driven architectures to help developers stay ahead of the curve and harness the full potential of serverless computing.

theburningmonk.com

Explore strategies for API versioning using AWS API Gateway and Lambda without duplicating infrastructure or introducing complex logic. Learn about different methods such as URL-based versioning, custom HTTP headers, and using Lambdaliths, along with their trade-offs. The discussion includes approaches to prevent breaking changes and considerations for choosing the right strategy based on version differences, client needs, and infrastructure requirements.

How to version APIs with API Gateway and Lambda

Prefer duplicating Lambda functions over versions

The idea of “Prefer duplicating Lambda functions over versions” is new. My common sense is to go with Versioning, because it is just “right there”.
But, the author argue practically:
<ol>
<li>IAM roles don’t version.</li>
<li>Tracking and testing separate versions is much easier.</li>
</ol>
Reasonable.

Ahhhh, right, don’t change your code, no versioning needed ;)