Building AquaSmart: A Water Consumption Monitoring App with Next.js and PostgreSQL

KickDown — Wed, 21 Oct 2026 19:13:50 +0000

How I built a web application to track shower water and energy consumption, explore usage history, and encourage more sustainable habits.

Introduction

Water and energy consumption are part of our daily lives, but it is not always easy to understand how much we use during a simple activity like taking a shower.

That is the idea behind AquaSmart, an academic project focused on sustainability and technology. The goal is to build a platform that helps users understand their shower consumption through measurements, historical data, and visual indicators.

I'm currently studying Computer Engineering, and this project has been a great opportunity to apply what I'm learning about web development, backend architecture, databases, and deployment.

The application is already deployed, with its main pages and backend functionality working. The physical integration with an ESP32 and sensors is still a future step.

What is AquaSmart?

AquaSmart is a web application designed to organize and analyze shower consumption data.

The current application includes:

Dashboard: an overview of consumption data and shower sessions.
Session management: start, track, and finish shower sessions.
Consumption history: access previously recorded sessions.
Charts: visualize consumption information over time.
Customizable settings: configure water and electricity costs, as well as a target shower duration.
REST API: endpoints for sessions, measurements, history, and settings.
Persistent storage: save application data in a PostgreSQL database.
Progressive Web App support: foundational PWA features for compatible devices.

The idea is to build the software foundation first and then connect it to physical sensors for real-world measurements.

Technology Stack

Here are the main technologies I used:

Next.js 16 — application framework and backend API routes.
React 19 — user interface.
TypeScript — type safety and maintainable code.
CSS Modules — component-specific styling.
Recharts — charts and data visualization.
Prisma ORM 7 — database access and schema management.
PostgreSQL — relational data storage.
Neon — managed PostgreSQL database.
Vercel — application deployment.

I chose this stack to keep the frontend and backend in one project while maintaining a clear separation between the different responsibilities.

Structuring the Backend

One of the most interesting parts of this project has been organizing the backend.

Instead of putting all the business logic directly inside API route handlers, I separated the code into modules.

The main modules are:

sessions: creates, retrieves, and finishes shower sessions.
measurements: validates and stores consumption measurements.
history: retrieves historical session data.
dashboard: provides aggregated information for the dashboard.
settings: manages user-configurable consumption parameters.

Each module follows a structure that separates route handling, business logic, database access, and validation.

For example:

src/
├── app/
│   └── api/
│       ├── dashboard/
│       ├── health/
│       ├── history/
│       ├── sessions/
│       └── settings/
├── lib/
│   └── prisma.ts
└── modules/
    ├── dashboard/
    ├── history/
    ├── measurements/
    ├── sessions/
    └── settings/

This organization makes the code easier to navigate and gives each part of the application a clear responsibility.

It also makes future changes easier. For example, the way measurements are received can evolve without requiring all the business logic to be rewritten inside the API handlers.

Designing the Database

AquaSmart uses PostgreSQL with Prisma to store sessions, measurements, and settings.

The database currently has three main models.

Session

A session represents a shower and stores information such as:

Start and finish timestamps.
Duration in seconds.
Total water consumption.
Total energy consumption.
Current status.

Sessions can be IN_PROGRESS or COMPLETED.

Measurement

Measurements belong to a session and contain:

Measurement timestamp.
Water flow rate in liters per minute.
Accumulated water volume in liters.
Electrical power in watts.

Each measurement is associated with its session through a database relationship.

Settings

The settings model stores parameters used by the application, including water cost per cubic meter, electricity cost per kilowatt-hour, and the target shower duration.

I also use Prisma migrations to track database schema changes, which helps keep the development and deployment environments consistent.

Handling Shower Sessions

Session management involves more than simply creating a database record.

The backend prevents multiple active sessions from being created concurrently. It uses a PostgreSQL transaction and an advisory lock when starting a session.

Finishing a session also needs to account for concurrent requests. The repository locks the corresponding session row before checking its status and updating it.

The finish timestamp is generated by the backend, and the duration is calculated from the difference between the start and finish timestamps.

This keeps the session lifecycle controlled by the server rather than relying entirely on values provided by the client.

These details were useful learning experiences because they showed me how database transactions and locking mechanisms can help protect data consistency.

Building the REST API

The API is implemented with Next.js Route Handlers.

Some of the available endpoints include:

Method	Endpoint	Purpose
`GET`	`/api/dashboard`	Retrieve dashboard data
`GET`	`/api/sessions`	List sessions
`POST`	`/api/sessions`	Start a session
`GET`	`/api/sessions/active`	Retrieve the active session
`GET`	`/api/sessions/[id]`	Retrieve a specific session
`PATCH`	`/api/sessions/[id]/finish`	Finish an active session
`POST`	`/api/sessions/[id]/measurements`	Record measurements
`GET`	`/api/history`	Retrieve session history
`GET`	`/api/settings`	Retrieve settings
`PATCH`	`/api/settings`	Update settings
`GET`	`/api/health`	Check database connectivity

The measurements endpoint accepts batches containing between 1 and 100 measurements. The backend validates the payload, including numeric values and timestamps, before processing it.

I also added a health endpoint that checks whether the application can connect to the database. This is useful when diagnosing deployment and connectivity issues.

Deployment and Database Connectivity

Deploying the application was another important part of the process.

AquaSmart is hosted on Vercel, with PostgreSQL provided by Neon.

During deployment, I encountered an issue related to Prisma Client generation. The solution was to run Prisma generation as part of the build process:

{
  "build": "prisma generate && next build"
}

I also had to configure DATABASE_URL in the appropriate Vercel environments so the application could connect to the database.

These issues helped me understand that a project can work locally and still fail during deployment because of differences in environment variables, generated files, or build configuration.

Getting the application deployed and verifying that the database-backed features worked was an important milestone.

What I Learned

Building AquaSmart has given me practical experience with several areas of software development.

Backend architecture: Separating routes, services, repositories, and validation helped me understand how to organize application logic as a project grows.

Database consistency: Working with Prisma, migrations, transactions, and row locking introduced me to important considerations when multiple requests interact with the same data.

API design: Implementing endpoints for sessions, measurements, history, and settings helped me practice request validation and HTTP response handling.

Deployment: Configuring the production database and resolving build issues taught me that deployment is part of development, not just the final step.

Sustainability and technology: The project gave me a way to connect software engineering with a practical problem involving water and energy consumption.

There is still a lot to improve, but having a working application deployed online gives me a solid foundation to build on.

What's Next?

The next major milestone is integrating the application with physical hardware.

The planned setup involves an ESP32 and sensors that can provide measurements related to water flow and electrical consumption. Those measurements could then be sent to the backend and used to update the dashboard and session history.

This integration has not been completed yet. For now, AquaSmart provides the software foundation, database models, and API endpoints needed to support that future work.

Other potential improvements include automated tests, stronger authentication, and additional consumption analytics.

Try AquaSmart

The project is available here:

GitHub repository: AquaSmart source code
Live demo: Try AquaSmart

AquaSmart is an ongoing academic project, and I'm looking forward to improving it as I continue learning about backend development, databases, and embedded systems.

If you have suggestions about the architecture, API design, or future hardware integration, I'd be happy to hear your feedback!

Thanks for reading!

DEV Community: KickDown