Reviving BookNook: From an Unfinished Local API to an AWS-Deployed Reading Tracker
This is my submission for the GitHub Finish-Up-A-Thon Challenge.
What I Built
I built BookNook, a personal reading tracker API that helps users manage books they are reading, planning to read, or have completed.
The API supports:
- Adding a book
- Viewing all books
- Viewing one book by ID
- Updating book details
- Deleting a book
- Uploading a book cover image
The revived version is now deployed on AWS and uses:
- Node.js and Express for the backend API
- Amazon DynamoDB for storing book records
- Amazon S3 for storing book cover images
- AWS Elastic Beanstalk for public deployment
- AWS IAM roles and policies for permissions
- GitHub for version control
- GitHub Copilot for refactoring, code review, and documentation support
Live Demo
API Health Endpoint
http://booknook-api-prod.eba-mhycv2pm.us-east-1.elasticbeanstalk.com/api/health
This endpoint confirms that the deployed API is healthy and connected to AWS services.
Expected response:
{
"status": "healthy",
"database": "DynamoDB connected",
"storage": "S3 configured",
"region": "us-east-1"
}
View All Books
http://booknook-api-prod.eba-mhycv2pm.us-east-1.elasticbeanstalk.com/api/books
This endpoint returns all books stored in DynamoDB.
Uploaded Book Cover Image
This shows that the cover image upload flow works. The API uploaded the image to Amazon S3 and stored the cover URL with the book record.
Repository
GitHub repository:
https://github.com/eghareabuwa-arch/booknook-api/tree/aws-version
I used a separate branch for the revived AWS version:
main - original/local-Azure version
aws-version - revived AWS-deployed version
Before: The Unfinished Project
BookNook originally started as a local Node.js and Express API experiment. I had earlier worked with Azure services such as Azure SQL Database, Azure Blob Storage, and Azure Key Vault.
The earlier version helped me understand cloud-backed APIs, but it was not fully finished because:
- It was mainly tested locally.
- It did not have a public API link.
- It was not deployed for others to test.
- The documentation was incomplete.
- The Azure resources were later deleted due to cost concerns.
- The project needed a clear before-and-after completion story.
At that point, BookNook was a working prototype, but it was not fully shipped.
After: The Revived AWS Version
For this challenge, I revived BookNook by rebuilding the cloud backend on AWS and deploying it publicly.
The completed AWS version now has:
- A public API hosted on AWS Elastic Beanstalk
- Book records stored in Amazon DynamoDB
- Book cover image uploads stored in Amazon S3
- A working public health endpoint
- A working public books endpoint
- A working public S3 cover image URL
- IAM permissions configured for the deployed app
- GitHub repository and AWS branch
- Challenge-ready README documentation
The project moved from a local unfinished API to a publicly accessible cloud API.
AWS Architecture
Client / Browser / Postman / curl
|
v
AWS Elastic Beanstalk
(Node.js Express API)
|
|----> Amazon DynamoDB
| Stores book records
|
|----> Amazon S3
Stores uploaded book cover images
DynamoDB stores structured book data such as title, author, genre, status, rating, notes, coverUrl, and addedAt.
S3 stores uploaded image files. The API uploads the book cover image to S3 and stores the public image URL in DynamoDB.
How GitHub Copilot Helped
GitHub Copilot helped me during the finishing process in several ways.
First, it helped me think through how to refactor the earlier cloud-backed API idea into an AWS-based structure using DynamoDB and S3.
Second, it helped me preserve the same REST API structure while changing the underlying cloud provider. I was able to maintain endpoints such as:
GET /api/health
POST /api/books
GET /api/books
GET /api/books/:id
PUT /api/books/:id
DELETE /api/books/:id
POST /api/books/:id/cover
Third, Copilot helped me review the Express API structure and improve documentation. I used it to organize the README, endpoint descriptions, and before-and-after story.
Copilot did not replace my work, but it helped me move faster, stay organized, and continue when I got stuck.
Screenshot to insert here: Copilot screenshot, if available.
Challenges I Faced
1. Moving from Azure to AWS
I originally worked with Azure, but I deleted the Azure resource group because of cost concerns. I decided to continue the project on AWS using available free credit.
2. Changing the Backend Cloud Services
The old idea used Azure SQL and Azure Blob Storage. The revived version uses DynamoDB and S3.
Azure SQL / local database idea -> Amazon DynamoDB
Azure Blob Storage idea -> Amazon S3
Local-only API -> AWS Elastic Beanstalk deployment
3. UUID Package Issue
The uuid package caused a compatibility issue with require(). I fixed it by using Node.js built-in:
crypto.randomUUID()
4. DynamoDB Permission Error
After deploying to Elastic Beanstalk, the health endpoint initially returned an unhealthy response because the Elastic Beanstalk EC2 role did not have permission to scan DynamoDB.
The missing permission was:
dynamodb:Scan
I fixed this by attaching DynamoDB permissions to the Elastic Beanstalk EC2 role.
5. S3 Upload Permission Error
The cover upload initially failed because the deployed app did not have permission to upload objects to S3.
The missing permission was:
s3:PutObject
I fixed this by attaching S3 permission to the Elastic Beanstalk EC2 role.
6. S3 Public Access Issue
After the image uploaded, the browser initially returned AccessDenied. I fixed this by updating the bucket public access settings and bucket policy so the uploaded cover image could be viewed through its public S3 URL.
What I Learned
This project helped me understand the difference between building locally and actually shipping.
I learned how to:
- Configure AWS CLI
- Create and use DynamoDB
- Create and use S3
- Deploy a Node.js API to Elastic Beanstalk
- Configure Elastic Beanstalk environment variables
- Fix IAM role permission issues
- Upload files from an API to S3
- Use Git branches to separate the original version from the revived version
- Document a project for public submission
Use of Underlying Technology
The project uses a real AWS cloud architecture with Elastic Beanstalk, DynamoDB, S3, IAM, Node.js, Express, GitHub, and GitHub Copilot.
Usability and User Experience
The API is simple to test through a browser, Postman, or curl. The health endpoint clearly shows whether the API is connected to DynamoDB and S3.
Originality and Creativity
BookNook solves a practical personal problem: tracking books, reading progress, notes, ratings, and cover images.
Completion Arc
The project has a clear before-and-after journey.
Before:
Local prototype
Azure experiment
No public API link
Incomplete deployment
Incomplete documentation
After:
AWS-deployed API
DynamoDB database
S3 cover image upload
Public API health endpoint
Public books endpoint
Public S3 cover image URL
GitHub repository and AWS branch
Challenge-ready documentation
Final Links
GitHub repository:
https://github.com/eghareabuwa-arch/booknook-api/tree/aws-version
Live API health endpoint:
http://booknook-api-prod.eba-mhycv2pm.us-east-1.elasticbeanstalk.com/api/health
Live books endpoint:
http://booknook-api-prod.eba-mhycv2pm.us-east-1.elasticbeanstalk.com/api/books
Live uploaded cover image:
Final Reflection
This challenge helped me push BookNook from “almost done” to actually shipped.
Before, it was a local/cloud experiment. Now, it is a deployed AWS API with persistent storage, cover image upload, public links, documentation, and a clear before-and-after journey.
The biggest win for me was learning how to move from a working local backend to a cloud-hosted API that others can test.
Top comments (0)