Building a digital platform to tackle the global plastic waste crisis

Martin Pllu, October 2021

This is the first in a series of articles about the technology we’re using at unwaste.io to tackle the world’s growing plastic waste problem.

In this article we’ll:

• Lay out our ambitious strategy for using data and digital technology to transform how plastic waste is managed in the Global South.
• Take a tour of our cloud-native technical architecture, based on Serverless and Infrastructure as Code principles.
• See how the use of a single programming language — Typescript — across all layers of our application gives us a huge degree of code reuse and agility.
• Look at the automated build pipelines that help us iterate quickly while maintaining code quality and security.
• Explore how we run a live service for five dollars per day that has already collected detailed data on over 48,000 waste plastic bottles across five African countries.

Our mission

The world is drowning in plastic. One million plastic bottles are purchased around the world every minute, producing vast quantities of waste as shown in these shocking graphics. Less than 6% of plastic bottles are recycled. Most end up being thrown into landfill or being washed into the ocean. The tsunami of plastic is accelerating — plastic production has been forecast to grow 60% by 2030 and 300% by 2050 [1].

In mid-2020 we formed unwaste.io. We want to use digital technology to help tackle the global plastic crisis in two ways:

1. Collecting high quality data to show where plastic waste comes from and where it ends up. The data can be used to hold plastic producers accountable for their waste and help producers, consumers and governments work together to achieve a circular economy. We want our platform to play a key role in enforcing Extended Producer Responsibility (EPR) legislation being considered in many countries. EPR will make bottle producers financially and physically responsible for the management of the waste they generate.
2. Creating a digital marketplace for plastic waste enabling the millions of waste collectors in the Global South to trade plastic waste directly with local recycling companies. These collectors, often exploited by middle-men, endure harsh working conditions for — at best — a few dollars per day. Our marketplace aims to change the economics of waste collection, allowing collectors to make a better living and attracting millions more to the industry. We want to enable a giant human-centred plastic reprocessing machine.

Wastebase launch and plans for scale up

We launched our Wastebase Android app at the start of 2021, focussing initially on countries in sub-Saharan Africa. We’ve built relationships with Data Partners — environmental organisations in Mozambique, Kenya, Tanzania and Zambia — who have now scanned and collected over 40,000 waste bottles. Detailed data is collected for each bottle including exact location, brand, manufacturer, country of origin, colour and weight.

Our next goal is to scale this effort up via crowdfunding. This allows sponsors all over the world to pay for collection in countries badly affected by plastic waste. Sponsors see exactly what their money pays for with detailed monthly personal reports. If you’re interested in sponsoring these efforts, please see https://startsomegood.com/wastebase.

We’re also about to start the first field trials of our “plastic waste marketplace” mobile app feature with our partner organisations, an exciting first step towards changing the economics of plastic reprocessing by allowing waste collectors to trade directly with local recyclers.

What is plastic reprocessing?

Mechanically and thermally working with waste plastic to make it into a finished product (such as a chair or new bottle) or an intermediate product (plastic flakes/granules) which can be made into a finished product. Typically involves a combination of washing, shredding, grinding, and mild heating.

Technical principles

To realise our ambitious vision, we need a technology stack that meets these criteria:

• Scalable. Over 20 million people make a living as waste collectors in the Global South [2], each one of them a potential member of the Wastebase platform. With plastic production accelerating we need technology that can scale to meet the challenge.
• Secure. Our system must prevent fraud in the trading system, ensure the integrity of the data that we collect, and be robust in the face of cyber security threats.
• Well-tested. Large numbers of users will rely on Wastebase to provide a trading platform and a high-quality, accurate data set. We make extensive use of automated tests to ensure the quality of the system.
• Private. Waste pickers are persecuted and marginalised. Our platform must help protect their personal data — we use GDPR as the gold standard of data privacy and we apply its principles in everything we build.
• Cost-effective. The unit price of plastic is low, with a kilo of recycled PET typically costing a few tens of cents. However there is lots of it, and demand is huge! Our platform must keep the unit cost per bottle/per trade as low as possible in order to be profitable.
• Efficient. IT infrastructure can be power-hungry — we want to ensure that the carbon footprint of our platform is as light as possible. We also need to take into account that the majority of our users are working with low-end, sometimes older, smartphones and have tight budgets on mobile data.
• Simple. We currently have three developers on our team. We need to be able to run a 24x7 digital service while investing most of our time in rapidly delivering new features and reacting to user feedback. We need a technology platform that is simple enough to allow a small team to do all this.

Cloud and Serverless

We knew straight away that cloud technology would be the best option for our IT infrastructure, providing a low-cost way of launching a digital service with plenty of ability to scale up. We selected Amazon Web Services (AWS) as the clear leader in terms of features and track record [3]. We initially considered hosting our cloud services in the AWS South Africa region, but as it currently lags behind other regions in terms of features, we ended up using the AWS Ireland region, and have found performance to be generally great for African users despite the higher intercontinental network latency.

A key pillar of our technical strategy is the use of serverless technology. Traditional IT infrastructure is based on servers which require a lot of work to set up and manage — load-balancing traffic, implementing measures to deal with hardware failure, hardening against security threats, keeping software up to date, housekeeping disk space, and much more besides. With all that complexity comes many risks that can lead to a service outage, security breach or data loss. Plus, when running servers you need to ensure that you have sufficient capacity to handle user demand, but not too much otherwise you’ll be paying extra money for unused server resources. It’s basically impossible to get this right for an online service with unpredictable traffic, so you end up with the twin problems of not having enough servers to deal with busy times, and having to pay for expensive servers which are not being used at all in quiet times.

Serverless technology offers a game-changing model that abstracts away the details of the underlying servers. For example, AWS Lambda provides a serverless compute platform that introduces itself as “Run code without thinking about servers”. With Lambda, you upload the code that you want to run when an event occurs, like receiving an HTTP request, specify a few details like the amount of memory to give the code, and Lambda makes sure that the code runs wherever the event is received, whether that’s once per year or tens of thousands of times per second. You don’t need to worry about any of the traditional low-level details — you’ve effectively outsourced that to AWS, who employ the best experts in the world to look after the underlying servers for you. Plus, you only ever pay for the service when the code actually runs; there is no such thing as a server sitting idle, costing you money. Cloud providers including AWS are able to densely pack lots of serverless components like Lambdas onto the underlying servers, resulting in more efficient energy use than traditional servers. Serverless technology is absolutely fundamental to our ability to be scalable, secure, efficient, simple and cost-effective.

Our applications

There are two user applications in Wastebase:

• The Wastebase mobile app helps individuals and teams scan lots of plastic bottles, collecting data including location, barcode, brand, size, bottle images and user identity.

• The Wastebase Data Portal at https://wastebase.org provides data visualisations and sophisticated data management features to help us build up a rich and accurate data set including details of the companies and brands associated with the bottles.

The Wastebase mobile app is an Android app. We plan to eventually release the app on iOS too, but since almost all phones in the Global South are Android devices, that’s our focus for now. The app uses Ionic which allows us to implement a native Android app using web development technology such as the Angular framework.

Single language

It’s worth noting now that we use a single programming language — Typescript — on every layer of our application stack, from web and mobile UI to back-end API code, plus our infrastructure and scripts. Having a single language everywhere allows us to reuse code to a huge degree, and Typescript’s powerful type system and modern features have been a massive benefit to the project.

Passwordless login

We implemented a ‘passwordless’ login system to avoid issues with users forgetting passwords, or choosing weak or easily guessable passwords. The Amazon Cognito identity service acts as the repository of registered users and the mechanism for managing login flow and security tokens. When users log in to the app, they enter their email address then our code interacts with Cognito which uses Amazon Simple Email Service to send the user an email containing a six-digit code. When the user enters this code we issue security tokens to their application, which are used to prove their identity for the rest of their session.

Service walk-through

Let’s take a look at the technology involved when a waste collector in Maputo, Mozambique picks up a bottle and presses the “Scan” button in the app:

• The app activates the phone camera and scans the barcode.
• The app issues a “look up product by barcode” request via HTTPS to our API layer, which travels across the internet to the AWS data centre in Dublin, Ireland.
• The request passes through Cloudfront and API Gateway, which provide scalable web plumbing, to Lambda, which runs the Wastebase API code. The API code is written in Typescript using the express web framework and the excellent tsoa REST API library.
• The API implements the business logic for the barcode lookup request, securely identifying the user from the token passed in the API request, validating the data including the barcode format, then looking up the product details via a SQL database query. Our database is built on Aurora Serverless, a novel AWS service which provides a serverless version of a PostgreSQL or MySQL database — we chose PostgreSQL for the advanced geographical data processing features in its PostGIS extension. True to the serverless model, Aurora Serverless database abstracts away the traditional worries of managing a database server, and automatically scales up or down to meet user demand.
• Lambda gets a response from the database containing the product details, which are passed back as an HTTP response to the Android app in Maputo and displayed on the screen.

Data validation in the portal

Later, another user working for an environmental NGO in Mozambique logs on to the Wastebase Web Portal to validate and enrich the data recently collected by the Android app users. When they load the web app, their browser issues HTTP requests to load the web assets including HTML, CSS and the Javascript bundles compiled from Typescript code.

These assets are hosted on Amazon Cloudfront, a globally distributed Content Delivery Network (CDN) that detects the user’s location and serves the content from the ‘edge location’ closest to the user — in this case in Johannesburg, South Africa. This strategy helps the web app load as quickly as possible. Thanks to the use of Ionic in the mobile app, we can reuse Angular components and Typescript code across the mobile app and the web app. Once again, we have achieved incredible levels of code reuse by using the same programming language across the entire service.

How we build Wastebase

Infrastructure as Code (IaC) is another technical foundation that Wastebase is built on. Traditionally, IT infrastructure is configured manually, by clicking buttons or running commands, or by scripts which move infrastructure from state A to state B. These approaches are brittle and error-prone, particularly as infrastructure grows in complexity.

Like Serverless, IaC is another technical leap made possible by cloud technology. Using IaC, the developer can simply express the ‘desired state’ of the infrastructure as source code. When a change is made to this code, for example adding a new Lambda or changing the configuration of CloudFront, the underlying IaC tools can figure out what changes need to be made to achieve this state. This model massively simplifies the task of managing infrastructure.

The Wastebase infrastructure is defined by Typescript code using Amazon’s Cloud Development Kit (CDK), so we have code that represents the configuration of Lambda, CloudFront, Aurora Serverless and so on — basically everything that makes up a Wastebase “environment”. Infrastructure as Code allows us to treat the infrastructure as a part of the overall application, and allows it to be subjected to the same testing and version control disciplines as the rest of the service.

Our entire codebase — Web UI, Android app, API, database and infrastructure — is defined in a single code repository which we version control with GitHub. We use a tool called Nx to control the overall project structure, giving us neat ways of sharing Typescript libraries between the layers of the application and orchestrating the overall build process.

Pipelines

AWS CodePipeline runs automated builds, tests and deployments of the application. Like all of our infrastructure, CodePipeline is defined by code using CDK, allowing us to evolve the pipeline and create copies of it for different purposes. Let’s have a look at how the pipeline works by stepping through what happens when we make a code change.

Let’s say that we have implemented a new feature in the application, which makes changes to the code for the Web app, Android app, API and infrastructure.

The developer starts off by making changes in their local source code using the Visual Studio Code editor. The developer writes automated tests as they go — unit tests that focus on small parts of code, integration tests that exercise the API and database, and end-to-end (e2e) tests that use the Cypress framework to test the UI running in a browser. The developer pushes their code changes to a “feature branch” in GitHub. We use CDK to set up “personal pipelines” for each developer which are configured to listen for pushes on the branch that the developer is working on. When the pipeline starts, it uses another AWS service called CodeBuild to spin up a build server. The branch code is downloaded from GitHub and then the build server starts running commands to install libraries and run unit tests. The build then deploys the application to the developer’s personal environment — an environment is a completely self-contained instance of the Wastebase service containing all of the required AWS resources and database structures. The deployment involves packaging up the web and API code and uploading to CloudFront/Lambda, using CDK to make any required changes to infrastructure, and running SQL ‘migration’ scripts against the environment’s database.

Once the application is deployed, the build process starts running the integration tests against the deployed API and database, then finally runs the e2e Cypress tests against the deployed web application (at this point, a test version of the mobile app is deployed as a website in the test environment to make it easy to test via Cypress). If all tests succeed, the pipeline reports success, otherwise it fails and the developer can fix the issue and push again. CodeBuild automatically shuts down and destroys the build server once the build is finished — another great example of serverless technology as CodeBuild deals with all the details of server management and we only pay for the service when it’s actually being used.

The developer can also run a command to build the native Android app, and deploy it wirelessly to a local device for testing against the API deployed to their personal environment.

When the developer has finished the change, they raise a Pull Request in GitHub, which gives the other developers an opportunity to review and comment on the code changes. Once the changes are approved, the feature branch is merged into the ‘master’ branch and the main pipeline (shown in the diagram below) builds and tests the change in the ‘dev’ environment. When we are ready to do a release to production, we first deploy the build to the ‘test’ environment for a final round of acceptance testing including testing the API with the previous version of the Android app to ensure that there are no breaking changes. Finally we deploy the change to our ‘production’ environment, make the new version of the Android app available in the Google Play store, and encourage our users to upgrade via WhatsApp groups. WhatsApp is the communication tool of choice in the countries we work in so we have created a WhatsApp group for each country where our NGO users can get support, learn about new features, and give us feedback.

Costs

Including everything — four test environments, the production environment and the pipelines — we pay around $5 per day to run Wastebase. These costs will go up as the service grows (for example, API Gateway charges about $1 per million API calls per month) but we expect them to remain manageable. Keeping costs low helps us maximise the amount of crowdfunding sponsorship that we can pass on to our Data Partner organisations to help them grow their data and plastic collection efforts.

Currently we handle over 10,000 scan operations plus over 1,000 data enrichment operations per month — each of which requires multiple database inserts and updates. Even using 2.5G Mobile data (still common in some countries) round trip time perceived by the users, for a scan operation, is less than 3 seconds — and in most cases less than 1 second .

Summary

We’ve taken a high level tour of the technology that we’re using to build the Wastebase platform and help tackle the global plastic waste crisis. We’re really pleased with the progress that we’ve made so far, and the efficiency that we’ve achieved by using approaches including serverless, infrastructure as code, Typescript everywhere, and high-quality automated testing. We still have a long way to go, but in our first year we feel that we’ve built a good service on some really solid foundations.

In future articles we’ll dive deeper into the technology, including front-end development, the database and our data model, the libraries that we use, security and user authentication, and our DevOps processes.

There are several ways that you can get involved:

• To help our efforts as a crowdfunding sponsor, please see https://www.unwaste.io/support-us
• The Wastebase app is available on Google Play: https://play.google.com/store/apps/details?id=io.unwaste.ops.wastebase
• If you’d like to explore the data we’ve collected so far, see https://www.kaggle.com/wastebase
• You can follow us on Twitter via @wastebase or get in touch via community@wastebase.org.

References

1. Center for International Environmental Law, 2019
2. https://theconversation.com/how-waste-pickers-in-the-global-south-are-being-sidelined-by-new-policies-132521
3. https://aws.amazon.com/blogs/aws/aws-named-as-a-leader-for-the-11th-consecutive-year-in-2021-gartner-magic-quadrant-for-cloud-infrastructure-platform-services-cips/