Building KabadiLink: A Smart Scrap Collection Platform with AWS Serverless
Discover how KabadiLink aims to simplify scrap collection by connecting households with collectors. Learn how AWS Amplify, Amazon API Gateway, AWS Lambda, Amazon DynamoDB, CloudWatch, and AWS SAM support the application's architecture and deployment.
Building KabadiLink: A Smart Scrap Collection Platform with AWS Serverless
Introduction
Waste management is an important challenge in modern cities. Households generate recyclable materials every day, including plastic, paper, metal, and electronic waste. However, coordinating scrap collection can be inconvenient for households and difficult to manage for collectors.
This inspired us to build KabadiLink, a platform designed to connect households with scrap collectors and make the collection process more organized.
In this article, I'll explain the problem KabadiLink addresses, its key features, and how AWS services support its frontend and backend architecture.
The Problem We Want to Solve
Traditional scrap collection often relies on phone calls, personal contacts, and informal arrangements. This can make scheduling, tracking requests, and recording collected materials difficult.
KabadiLink aims to improve this experience by providing a digital platform where users can submit pickup requests and collectors can manage collection activities.
What Is KabadiLink?
KabadiLink is a scrap collection platform designed to connect households that have recyclable waste with collectors who can collect it.
Its planned core workflows include:
- Pickup requests: Users can provide a pickup address, select a collection date and time slot, and specify waste categories and estimated quantities.
- Waste categorization: Pickup requests can include categories such as plastic, wet waste, and electronic waste.
- Collector workflow: Collectors can view requests and update collection statuses.
- Weight recording: Collectors can record the actual weight of collected materials.
The goal is to make scrap collection easier to coordinate and help recyclable materials reach appropriate collection channels.
Why We Chose AWS
We wanted to build a web application with a frontend and backend that could be developed and deployed separately while communicating through APIs.
AWS provides managed services that support this architecture without requiring us to maintain traditional servers.
For KabadiLink, we used AWS Amplify for frontend hosting, Amazon API Gateway for API endpoints, AWS Lambda for backend logic, Amazon DynamoDB for data storage, Amazon CloudWatch for logs, and AWS Serverless Application Model (AWS SAM) to define and deploy backend resources.
Understanding the Architecture
The application follows a straightforward request flow:
- A user interacts with the KabadiLink frontend.
- The frontend sends an HTTP request to an API endpoint.
- Amazon API Gateway receives the request and connects it to the backend.
- AWS Lambda executes the application logic.
- Amazon DynamoDB stores or retrieves pickup information.
- The API returns a response to the frontend.
- Amazon CloudWatch logs help with troubleshooting and debugging.
AWS Amplify hosts the frontend, while the serverless backend handles application requests and data operations.
This separation makes it easier to organize frontend and backend development.
AWS Services Used
1. AWS Amplify: Hosting the Frontend
AWS Amplify is used to deploy and host the KabadiLink frontend.
It makes the web application accessible through a hosted website rather than requiring users to run it locally.
During deployment, environment variables help configure the frontend, including the URL of the backend API. With a Vite-based application, these variables must be available during the build process.
2. Amazon API Gateway: Connecting the Frontend and Backend
Amazon API Gateway provides HTTP endpoints through which the frontend communicates with the backend.
KabadiLink includes routes for operations such as:
-
GET /pickups— retrieve pickup requests.
-
POST /pickups— create a pickup request.
-
PATCH /pickups/{id}/status— update a pickup's status.
-
PATCH /pickups/{id}/weigh-in— record actual collection weights.
These endpoints create a defined interface between the frontend and backend.
Using HTTP methods and structured routes also helps organize application operations and makes API behavior easier to test.
3. AWS Lambda: Running Backend Logic
AWS Lambda executes backend code without requiring us to manage a traditional server.
It handles application operations such as processing pickup requests, retrieving records, updating statuses, and recording weights.
Lambda allows us to focus on application logic while AWS manages the underlying compute infrastructure.
4. Amazon DynamoDB: Storing Pickup Data
Amazon DynamoDB provides NoSQL storage for pickup information.
The application needs to manage data such as collection dates, time slots, addresses, waste quantities, and pickup statuses.
DynamoDB provides a managed database that integrates with Lambda and supports the backend's data-storage requirements.
5. Amazon CloudWatch: Debugging and Monitoring
CloudWatch provides logs that help us investigate backend execution and API failures.
During development, troubleshooting errors highlighted how important it is to inspect logs rather than relying only on what appears in the frontend.
Clear logs help developers investigate problems involving request validation, data types, database operations, and backend execution.
6. AWS Serverless Application Model: Deploying Infrastructure
AWS Serverless Application Model (AWS SAM) is an open-source framework for building serverless applications on AWS.
We used AWS SAM to define and deploy backend resources. Keeping infrastructure definitions in a template makes deployments more structured and repeatable.
This also helps organize backend infrastructure alongside application code.
Connecting the Frontend to the Backend
One of the most important parts of building KabadiLink is ensuring that the frontend and backend communicate correctly.
Both sides must agree on API URLs, HTTP methods, request payloads, response structures, and data types.
For example, when a user submits a pickup request, the frontend sends the pickup date, selected time slot, address, and estimated waste quantities to the API. The backend processes the request and stores the pickup information in DynamoDB.
The frontend can then use the API response to display the result to the user.
During integration, an important lesson was that deploying a frontend and backend does not automatically guarantee that the complete workflow works. Each API operation needs to be tested against the deployed backend.
The application can also use a demo fallback for demonstrations when the backend is unavailable. However, demo data must be distinguished from records successfully persisted in AWS.
Challenges and Lessons Learned
Understanding errors across multiple services
When an API request fails, the cause may be in the frontend, API Gateway, Lambda, or database operation. CloudWatch logs and systematic testing are important for identifying the source of the issue.
Maintaining consistent data formats
The frontend and backend must use compatible field names, identifiers, data types, and status values. Data-format mismatches can cause errors even when an endpoint is configured correctly.
Managing deployment configuration
Environment variables are an important part of connecting the deployed frontend to the backend. Understanding how Vite uses variables during builds helps avoid configuration problems.
Planning for security
A frontend role selector alone does not provide secure authorization. A production-ready version should include authentication, backend authorization, request validation, and appropriate permissions for each user role.
These lessons have helped us understand that cloud application development involves not only deploying services but also testing, debugging, monitoring, and securing the complete application.
What's Next?
As KabadiLink develops further, our priorities include:
- Completing end-to-end testing of all pickup API operations.
- Adding secure authentication and role-based authorization.
- Improving API validation and error handling.
- Developing collection history and activity dashboards.
- Exploring notifications for pickup confirmations and status changes.
- Using collection data to understand recyclable material volumes and collection patterns.
These improvements would help make the platform more reliable and useful for households and collectors.
Conclusion
KabadiLink explores how cloud technology can help make scrap collection more organized and convenient.
By combining AWS Amplify, Amazon API Gateway, AWS Lambda, Amazon DynamoDB, Amazon CloudWatch, and AWS SAM, the project demonstrates how a frontend and a serverless backend can be brought together to support a real-world use case.
Building KabadiLink has strengthened our understanding of API integration, serverless architecture, cloud deployment, debugging, and data management.
Our broader goal is to use technology to improve the coordination of scrap collection and encourage more effective recycling.
KabadiLink is a step toward making recycling easier to coordinate through a connected digital platform.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article