Serverless Game of Thrones-themed API

This serverless API uses AWS SAM, Lambda, DynamoDB, and API Gateway to deliver detailed information on iconic knights from the Game of Thrones universe.

Comment

🛡️ Game of Thrones Serverless API – Project Story

🔥 Inspiration

This project was inspired by a series of YouTube videos from experienced cloud developers who discussed the best ways to get started in the cloud and which hands-on projects were most effective for learning. I wanted to build something fun yet technically rich—so I combined my interest in Game of Thrones lore with a goal to deepen my cloud engineering skills.

📚 What I Learned

Throughout this project, I learned:

  • Infrastructure as Code (IaC): How to define and manage AWS resources using AWS SAM instead of relying on the web console. This approach made the process faster, repeatable, and more maintainable.
  • Serverless Architecture: Understanding how AWS Lambda, API Gateway, and DynamoDB can be combined to build a scalable, event-driven backend.
  • AWS SDK (Boto3): Gained practical experience calling AWS services programmatically from within Lambda functions.
  • Testing Serverless APIs: Learned to write unit tests for Lambda route handlers, and the challenges involved in mocking AWS services.
  • Containerization with Docker: My first hands-on experience with Docker, particularly for local testing of Lambda functions.
  • NoSQL Data Modeling: Designed a DynamoDB schema for knight data, learning to think in access patterns instead of fixed schemas.
  • Frontend Integration: Integrated a React + TypeScript frontend to make the API more accessible with a seamless UI.

🛠️ How I Built It

I developed this project incrementally, milestone by milestone:

  1. Set up AWS SAM to scaffold the project and declare AWS resources (Lambda, API Gateway, DynamoDB) using template.yaml.
  2. Created Lambda functions to serve data about knights in response to HTTP requests.
  3. Integrated DynamoDB to store and query knight information efficiently.
  4. Tested endpoints locally using Docker and the SAM CLI.
  5. Deployed using sam deploy, managing resources via CloudFormation stacks.
  6. Implemented unit tests to validate endpoint behavior.
  7. Built a React + TypeScript frontend to consume the API and display knight data in a user-friendly format.

⚔️ Challenges Faced

Like most real-world cloud projects, this one came with its share of challenges:

  • Unit testing Lambda routes: Mocking AWS services reliably during tests took time and experimentation.
  • Learning Docker: I had never worked with containers before, so understanding how Docker ties into local testing was a steep learning curve.
  • DynamoDB data modeling: Designing an efficient schema in a NoSQL, schema-less environment required a shift in mindset from relational database thinking.
  • Cold start latency: I encountered slower response times during initial API requests and had to research best practices to reduce Lambda cold start impact.
  • IAM Permissions: Fine-tuning permissions for each Lambda function was tricky. I faced issues where functions failed silently due to missing access rights.
  • Cross-Origin Resource Sharing (CORS): When connecting the frontend, I ran into CORS issues which I had to resolve through proper API Gateway configuration.

🌩️ Final Thoughts

This project helped me internalize how powerful and flexible serverless architecture can be. It was a hands-on experience that reinforced cloud fundamentals while teaching me how to build something scalable, cost-effective, and fun. I now feel much more confident working with AWS services in a professional, infrastructure-as-code-first workflow.

Built With

Share this project:

Updates

Submission history