AirSense

Inspiration

The Invisible Crisis: The inspiration for AirSense was born from a convergence of catastrophic environmental events in 2024 and 2025. We were deeply moved by the "toxic fortnight" in New Delhi, where the Air Quality Index (AQI) surged to hazardous levels, yet official responses often obfuscated the severity of the crisis. Simultaneously, the 2025 Canadian wildfire season brought smoke and dangerous particulate matter to millions across North America, proving that air pollution is a transboundary threat. We learned that air pollution is now responsible for 7.9 million deaths annually, a mortality risk comparable to tobacco use. Most alarmingly, recent research links pollutants like \(PM_{2.5}\) not just to respiratory failure, but to 626,000 deaths from dementia. We realized that existing weather apps treat air quality as a footnote, a static number without context. We wanted to build a tool that treats bad air as what it effectively is: a public health emergency.

What it does

AirSense is a production-ready web application that empowers users to make data-driven health decisions. It aggregates real-time data on critical pollutants—specifically Particulate Matter (\(PM_{2.5}\), \(PM_{10}\)), Ozone (\(O_3\)), and Nitrogen Dioxide (\(NO_2\)), and contextualizes this data against World Health Organization (WHO) safety guidelines.

Instead of just showing a number, AirSense provides specific, age-based recommendations. If the concentration of \(PM_{2.5}\) exceeds \(35 \mu g/m^3\), the app doesn't just turn orange; it advises caregivers to keep children with asthma indoors and suggests N95 masking for commuters.

How we built it

We architected AirSense as a decoupled application to ensure performance and scalability:

Frontend: We used React 18 with TypeScript for a robust, type-safe user interface. The UI is styled with Tailwind CSS and Radix UI for accessibility, while Recharts renders the historical data trends.
State Management: We moved away from standard useEffect hooks to TanStack Query, which manages server state, caching, and background polling to keep data fresh without overloading the browser.
Backend: We built a custom Node.js and Express proxy server to handle all data orchestration.

Challenges we ran into

Surviving the API Integration

The most significant technical hurdle we faced was integrating the AccuWeather API under the constraints of a hackathon environment.

The "429 Too Many Requests" Nightmare

We quickly discovered that high-fidelity weather APIs have strict rate limits. The free tier limited us to just 50 calls per day. In our initial React prototype, every time a component re-rendered or a user refreshed the page, we fired a new request. Within 10 minutes of development, we exhausted our daily quota and hit 429 Too Many Requests errors. We realized we were effectively DDoS-ing our own application.

The Solution: A "Leaky Bucket" Proxy

To solve this, we couldn't just fetch data from the client. We engineered a Backend-for-Frontend (BFF) architecture.

We implemented a server-side caching strategy. When a user requests data for a city, our Node.js server first checks its internal cache. If the data is less than 20 minutes old, we serve it from memory (\(Cost = 0\) API calls).
We built a rate-limiter using the Leaky Bucket algorithm logic to queue and throttle requests, ensuring we never exceed our provider's limits regardless of traffic spikes.

Security Realizations

We also learned that storing API keys in a React .env file is a security flaw, as keys are embedded in the production build. By moving the API interaction to our Express backend, we secured our credentials, ensuring that no malicious actor could scrape our keys and steal our data quota.

Accomplishments that we're proud of

We managed to build a system that is resilient, secure, and genuinely useful. We turned a technical constraint (API limits) into an architectural strength (caching and proxying), resulting in an app that is faster and more reliable than our initial prototypes. AirSense doesn't just display data; it protects health.

What we learned

Data Utility vs. Availability: We learned that "available" data isn't always "useful." A raw AQI number means nothing to a user until it is translated into a specific action (e.g., "Wear a mask").
The Backend-for-Frontend (BFF) Necessity: We learned that for any serious production app, the frontend cannot be trusted with secrets. Implementing the BFF pattern was essential for both security and rate-limiting.
Health Nuances: We learned that different pollutants have different peak times. Ozone (\(O_3\)) often peaks in the afternoon, while \(PM_{2.5}\) can linger overnight. This drove our decision to include hourly breakdowns rather than just daily averages.

What's next for AirSense

AI-Driven Forecasting: We plan to integrate a Python microservice to predict AQI trends 24 hours in advance using historical data.
Hyper-local Crowdsourcing: We want to add a feature allowing users to report local pollution sources (like crop burning or fires) to fill the gaps between satellite sensors.
IoT Integration: Future updates will allow AirSense to trigger smart home devices, automatically turning on air purifiers when outdoor air quality deteriorates.