|
1 | | -# 🌦️ Weather.IO |
| 1 | +# 🌦️ Weather.IO — Performance-Optimized Weather System |
2 | 2 |
|
3 | | -A high-performance, full-stack weather dashboard built with the 2026 MERN-adjacent stack. This project demonstrates a production-grade workflow featuring **Next.js 16**, **Prisma 7**, **Docker** containerization, and a robust **CI/CD** pipeline. |
| 3 | +A full-stack weather application built with Next.js, TypeScript, and PostgreSQL, focused on **real-world system performance, caching, and efficiency optimization** rather than just UI. |
4 | 4 |
|
5 | | -## 🚀 Features |
6 | | -- **Real-time Data**: Fetches live weather conditions via OpenWeather API. |
7 | | -- **Dynamic Theming**: Instant Light/Dark mode toggle with local storage persistence. |
8 | | -- **Persistent Storage**: CRUD operations with PostgreSQL & Prisma 7. |
9 | | -- **Modern UI**: High-end aesthetic using Tailwind CSS v4 and Lucide React. |
10 | | -- **Type Safety**: End-to-end TypeScript integration. |
| 5 | +--- |
| 6 | + |
| 7 | +## 🚀 Live Demo |
| 8 | + |
| 9 | + https://weather-ey07179ip-shadows5-projects.vercel.app/ |
| 10 | + |
| 11 | +--- |
| 12 | + |
| 13 | +## 🧠 Why This Project Exists |
| 14 | + |
| 15 | +Most weather apps are simple API wrappers. |
| 16 | + |
| 17 | +This project focuses on: |
| 18 | + |
| 19 | +* reducing latency |
| 20 | +* optimizing backend efficiency |
| 21 | +* designing real-world caching strategies |
| 22 | +* understanding system bottlenecks |
| 23 | + |
| 24 | +--- |
| 25 | + |
| 26 | +## ⚡ Performance Improvements |
| 27 | + |
| 28 | +| Optimization | Impact | |
| 29 | +| ------------------------------------- | --------------------------------------------------- | |
| 30 | +| API Caching (in-memory) | Eliminated redundant external API calls | |
| 31 | +| DB Write Optimization | Prevented unnecessary writes using change detection | |
| 32 | +| ISR (Incremental Static Regeneration) | Reduced page load latency from ~2.5s → ~400ms | |
| 33 | +| Selective Queries (Prisma) | Reduced payload size and improved response time | |
| 34 | +| Conditional Cache Invalidation | Avoided unnecessary re-renders | |
| 35 | + |
| 36 | +--- |
| 37 | + |
| 38 | +## 📊 Before vs After |
| 39 | + |
| 40 | +| Metric | Before | After | |
| 41 | +| --------------- | ------------- | -------------------- | |
| 42 | +| Page Load Time | ~2.5s | ~400–500ms | |
| 43 | +| API Calls | Every request | Cached (30s) | |
| 44 | +| DB Writes | Always | Only on change | |
| 45 | +| System Behavior | Inconsistent | Stable + predictable | |
| 46 | + |
| 47 | +--- |
| 48 | + |
| 49 | +## 🏗️ Architecture Overview |
| 50 | + |
| 51 | +User Request |
| 52 | +↓ |
| 53 | +Next.js Server Action |
| 54 | +↓ |
| 55 | +🔹 Cache Layer (Check) |
| 56 | + ↳ Hit → Return cached data |
| 57 | + ↳ Miss → Fetch from API |
| 58 | +↓ |
| 59 | +🔹 External Weather API |
| 60 | +↓ |
| 61 | +🔹 Change Detection Logic |
| 62 | + ↳ No Change → Skip DB |
| 63 | + ↳ Change → Update DB |
| 64 | +↓ |
| 65 | +🔹 PostgreSQL (Prisma) |
| 66 | +↓ |
| 67 | +🔹 ISR Cache (Next.js) |
| 68 | +↓ |
| 69 | +UI Render |
| 70 | + |
| 71 | +--- |
11 | 72 |
|
12 | 73 | ## 🛠️ Tech Stack |
13 | | -- **Framework**: [Next.js 16](https://nextjs.org/) (Turbopack) |
14 | | -- **Database**: [PostgreSQL](https://www.postgresql.org/) + [Prisma ORM 7](https://www.prisma.io/) |
15 | | -- **DevOps**: [Docker](https://www.docker.com/), GitHub Actions |
16 | | -- **Styling**: [Tailwind CSS v4](https://tailwindcss.com/) |
17 | | -- **Testing**: [Vitest](https://vitest.dev/) |
| 74 | + |
| 75 | +* **Frontend:** Next.js, React, Tailwind CSS |
| 76 | +* **Backend:** Node.js, Server Actions |
| 77 | +* **Database:** PostgreSQL (Prisma ORM) |
| 78 | +* **Deployment:** Vercel / Render |
| 79 | +* **Tools:** GitHub Actions, Docker (optional) |
18 | 80 |
|
19 | 81 | --- |
20 | 82 |
|
21 | | -## 📦 Installation & Setup |
| 83 | +## 🧩 Key Engineering Decisions |
| 84 | + |
| 85 | +### 1. Why caching? |
22 | 86 |
|
23 | | -### 1. Clone the Repository |
24 | | -```bash |
25 | | -git clone [https://github.com/prathiusharun/Weather-app.git](https://github.com/prathiusharun/Weather-app.git) |
26 | | -cd Weather-app |
| 87 | +To reduce latency and external API dependency. |
| 88 | + |
| 89 | +### 2. Why conditional DB writes? |
| 90 | + |
| 91 | +Database operations are expensive — unnecessary writes degrade performance. |
| 92 | + |
| 93 | +### 3. Why ISR instead of full SSR? |
| 94 | + |
| 95 | +To balance freshness and speed using controlled revalidation. |
| 96 | + |
| 97 | +### 4. Why selective queries? |
| 98 | + |
| 99 | +To minimize payload and improve response time. |
| 100 | + |
| 101 | +--- |
| 102 | + |
| 103 | +## ⚠️ Trade-offs |
| 104 | + |
| 105 | +* In-memory cache resets on server restart |
| 106 | +* Weather data may be slightly stale (≤30s) |
| 107 | +* No distributed caching (future improvement) |
| 108 | + |
| 109 | +--- |
| 110 | + |
| 111 | +## 🚀 Future Improvements |
| 112 | + |
| 113 | +* Redis-based distributed caching |
| 114 | +* Background jobs for periodic weather updates |
| 115 | +* Rate limiting per user |
| 116 | +* Real-time updates with WebSockets |
| 117 | + |
| 118 | +--- |
| 119 | + |
| 120 | +## 📌 What I Learned |
| 121 | + |
| 122 | +* Performance is about identifying bottlenecks layer by layer |
| 123 | +* Caching is easy — cache invalidation is hard |
| 124 | +* Backend efficiency matters more than adding features |
| 125 | +* Real-world systems require trade-offs |
| 126 | + |
| 127 | +--- |
| 128 | + |
| 129 | +## 👨💻 Author |
| 130 | + |
| 131 | +**Prathiush Arun** |
| 132 | +Backend-Focused Full-Stack Developer |
| 133 | + |
| 134 | +--- |
0 commit comments