Ramon Lage

Building a full stack IoT dashboard: a climate monitoring project

15 de diciembre de 2025

Building a full stack IoT dashboard: a climate monitoring project

This project was conceived as a way to bring together different layers of development into a single, coherent system.
Rather than working on isolated frontend or backend exercises, I wanted to build something closer to a real-world scenario, where data flows from a physical source to a web application.

That goal led to this IoT climate monitoring dashboard, a project focused on collecting temperature and humidity data from sensors and presenting it through a web interface.

What the project does

The system monitors environmental data and displays it in a web dashboard.

At a high level, it consists of:

  • sensors that collect temperature and humidity data
  • a backend API responsible for receiving, storing, and serving that data
  • a frontend dashboard to visualize both current and historical values

The emphasis was on reliability and data flow rather than visual polish, ensuring that each layer had a clear responsibility.

Technical stack and decisions

The project uses the following stack:

  • React for the frontend dashboard
  • FastAPI for the backend API
  • PostgreSQL for data persistence

FastAPI was a good fit for this project due to its clarity, built-in validation, and automatic Swagger documentation. It allowed me to focus on API design and data modeling while keeping the implementation explicit and predictable.

On the frontend side, React provided the flexibility to build reusable components and to update the interface as new data arrived.

A deliberate design decision was to keep the API focused on frontend needs, defining endpoints that were explicit and easy to consume rather than overly generic.

Challenges and system-level considerations

One of the main challenges was ensuring reliable communication between the data source and the backend.

This required decisions around:

  • data sampling frequency
  • validation of incoming values
  • handling missing, delayed, or incorrect readings

Deployment introduced additional constraints. Running both the frontend and backend in production environments highlighted aspects such as cold starts, response delays, and the importance of proper error handling.

These constraints encouraged a more defensive approach and reinforced the need to think about the system as a whole rather than individual components.

Key takeaways

Working on this project reinforced several important principles:

  • Full stack development is primarily about integration, not isolated features
  • Backend design should always account for frontend consumption patterns
  • Real-world data exposes edge cases that rarely appear in purely theoretical projects
  • Clear API contracts significantly simplify frontend development

It also strengthened my experience working with deployed applications instead of local-only setups.

What I would approach differently today

With the perspective I have now, there are several areas I would improve:

  • a more structured backend architecture
  • clearer separation of concerns within the API
  • authentication and user-specific data handling
  • more robust error handling and monitoring

If I were to rebuild this project today, I would likely choose NestJS to benefit from a more opinionated and scalable backend structure.

Final thoughts

This project represents a concrete example of integrating frontend, backend, and hardware into a single system.
It reflects a stage where the focus shifted from individual components to system design and data flow.

That experience has had a lasting impact on how I approach backend and full stack development, especially when designing systems meant to operate beyond local environments.