Every Drop Tells a Story: The Journey Behind Jal Dharani
Water sustains life, yet scarcity, pollution, and rising temperatures threaten our environment. Jal Dharani brings together interactive maps, citizen reporting, geospatial data, and AI assisted insights to help communities understand local environmental challenges. My goal is to turn awareness into action and inspire collective responsibility for protecting our water, our land, and the future we share.
I'm a computer science and engineering student
Where the idea began
Water is something we depend on every day, yet water scarcity, groundwater depletion, and pollution continue to affect communities. Rising temperatures add another challenge, making water resources and environmental resilience even more important.
I started wondering how technology could help people better understand these problems, especially when they affect their own neighbourhoods. Environmental information can be difficult to navigate, and people who want to help may not always know where to start.
That thought led me to build Jal Dharani, a community driven environmental resilience platform designed to bring water resource awareness, environmental reporting, urban heat information, and conservation activities together.
Imagine someone noticing a polluted pond near their home. They might want to document the issue, understand its possible causes, or find others interested in improving the situation. Jal Dharani aims to provide a starting point for exploring such concerns and connecting information with community action.
I know that technology alone cannot solve environmental problems. Reliable data, scientific research, public participation, and sustained efforts are essential. But I believe accessible information can help people make better informed decisions and participate more meaningfully in protecting their surroundings.
That is the idea I wanted to explore with this project.
Building it on my own
I'm developing Jal Dharani as a solo developer, which means working across the frontend, backend, database, and infrastructure rather than concentrating on just one part of the application.
The frontend uses React and TypeScript, while the backend is built with FastAPI. PostgreSQL with PostGIS supports geospatial data, and I've integrated Google Gemini to explore AI assisted environmental explanations.
Each technology has a specific role. Interactive maps provide geographical context, citizen reporting offers a way to document observations, and geospatial data helps organize information by location. AI assisted explanations provide another way to explore environmental concepts in more accessible language.
As I worked on these components, I began thinking about how the application could eventually operate beyond my local development environment. That led me to explore AWS and serverless architecture.
Taking my first steps into AWS
I wanted to understand how Jal Dharani could eventually run in the cloud and how its different components could communicate reliably.
I began exploring the AWS Serverless Application Model (AWS SAM), an open source framework that allows developers to define serverless infrastructure using code.
I created a SAM template describing the intended use of AWS Lambda for the backend, Amazon API Gateway for HTTP requests, and Amazon S3 for media storage. I also included Mangum to adapt FastAPI for a Lambda execution environment.
One aspect I appreciated was being able to describe the infrastructure in a YAML file. It gave me a clearer view of the resources I was working toward and how they related to one another.
I successfully validated the template using:
Bash
sam validate --template-file infrastructure/template.yaml
This confirmed that the template passed SAM's validation checks. It did not, however, confirm that the application was deployed or that the cloud services were communicating successfully.
Understanding the planned architecture
The architecture I am working toward connects the frontend to API Gateway, which would route requests to Lambda. Mangum would adapt those requests for FastAPI, allowing the backend to process them and communicate with the database and other services.
This represents the planned architecture, not a completed AWS deployment. The application still needs a suitable cloud database configuration, secure environment variables, appropriate permissions, and end to end testing.
Thinking through these requirements helped me understand that deploying an application involves more than moving code to a server. Every connection between the components needs to be configured and verified.
Exploring S3 and local development
Environmental reports could eventually include photographs or other supporting media. I explored Amazon S3 as a potential storage solution and configured the project around a bucket named
jal-dharani-media .I also set up LocalStack to emulate S3 during local development. This gave me an opportunity to explore how storage could fit into the application without immediately relying on a live AWS bucket.
The complete upload workflow still needs verification, but the process helped me understand how cloud storage can be incorporated into an application's architecture and development environment.
The challenges that taught me the most
Not everything worked as expected, and some of the most useful lessons came from troubleshooting.
One challenge occurred when I attempted to build the SAM application. My template specified Python 3.10, while my local environment had Python 3.13 installed. The runtime mismatch prevented the build from completing successfully.
I also encountered AWS authentication and session expiration issues, which interrupted my attempts to progress through the cloud workflow.
Database connectivity presented another important consideration. My backend initially used a local PostgreSQL database, but a Lambda function running in AWS cannot automatically access a database on my computer. A deployed version would require an appropriate hosting arrangement, network connectivity, and secure configuration.
These experiences helped me distinguish between defining infrastructure, validating a template, building an application, and deploying a working system. Each stage has its own requirements, and success at one stage does not guarantee success at the next.
I haven't completed a live AWS deployment yet. However, I now have a clearer understanding of the issues I need to resolve and the work required to move forward.
What I learned from AWS SAM
Working with AWS SAM introduced me to infrastructure as code in a practical setting. I could describe the intended cloud resources in a single template, validate the configuration, and inspect how the components fit together.
Exploring Lambda, API Gateway, and S3 also helped me understand the different responsibilities involved in a serverless application. LocalStack provided an additional way to experiment with selected AWS services during development.
The experience reinforced an important lesson: choosing cloud services is only the beginning. Runtime compatibility, dependency packaging, database access, credentials, and permissions all need attention before an application can operate reliably in production.
As a solo developer, learning to identify these dependencies has been just as valuable as writing the application itself.
What I hope Jal Dharani can become
The part of this project I care about most is the possibility of making environmental information more useful at a local level.
I would like Jal Dharani to help people explore environmental concerns in their surroundings, document observations, and discover opportunities to participate in conservation efforts. Over time, reliable data and community contributions could help provide a clearer picture of local challenges and the work being done to address them.
I'm particularly interested in connecting water resource awareness with urban heat resilience. These issues can influence one another, yet they are often discussed separately. Bringing them into the same platform could help users explore their relationships and better understand the challenges their communities face.
For this to be genuinely useful, the information must be trustworthy, data sources must be transparent, and AI generated explanations must be treated as guidance rather than verified scientific conclusions.
I see Jal Dharani as a starting point, not a complete solution. Its value will ultimately depend on how reliably it works, the quality of the information it provides, and whether it helps people take informed action.
What comes next
My next steps are to resolve the runtime compatibility issue, determine a suitable hosted database setup, secure the application's configuration, and test the AWS integrations in a complete deployment.
I also want to continue improving automated testing and ensuring that environmental information is clearly attributed to its source.
Building Jal Dharani has allowed me to bring software development, geospatial technology, AI, and cloud infrastructure together around a problem that matters. It has also taught me to approach technical challenges patiently, verify what works, and be honest about what remains unfinished.
I'm still learning, and the project is still evolving. But I now have a clearer understanding of both the application I want to build and the technical work needed to support it.
For me, Jal Dharani is an opportunity to turn a concern about environmental challenges into something practical: a platform that can help people understand their surroundings and find ways to contribute to protecting them.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article