Eau de France

Eau de France is a self-updating water quality visualization app, using data gathered from Hubeau, a public API enabling access to water quality data in France.

It features a main page with a commune search feature that uses another API provided by the French government directly. This search is incredibly fast and updates after a very small debounce, even from a single letter (there is indeed a single-letter commune in France: Y).

After selecting a commune, we can access its latest available results in a dedicated page. The commune pages are fully server-rendered leveraging Next.js ISR and revalidated every 24 hours.

On these pages, users can see a list of the existing water networks and the latest water quality results for that network. Two display types are available: sortable grid or cards. On mobile, users have access to the same information and features and can access the network selection from a drawer.

Typescript, Tailwind, Next.js, hosted by Vercel for simplicity and because I did not need more than what the free tier provides, many of the components came from shadcn.

My goal for this project was to create an updated version of a technical challenge I had to do as a then candidate for my previous job, using the same API and timeframe (a few days), but with a modern look, simpler interface and leveraging many of the skills I developed during my first professional experience.

This challenge was the first real-world test of my programming skills with stakes in play. It contributed to landing me my first dev job so it felt right to give it a quick revamp.

One particularly interesting part of this project was the use of a token bucket algorithm to manage concurrent API calls in order to stay under the API's rate-limit threshold. While relatively simple conceptually, it entirely solved the need for a heavier infrastructure that would have included tracking the calls of individual users and managing them.

With this architecture, even if a malicious user were to try and saturate the website with calls to many different communes, they would only end up generating around 35k pages (about the number of communes in France currently). After that, no calls would trigger again for these pages other than the automatic ones from time-based revalidation.

This is what would tend to happen anyway with normal use over the long term.

• How to create a simple ISR strategy for a use case where it is appropriate.
• Rate-limiting solutions can range from very easy to incredibly complex. I do not always need heavy solutions.
• Taking my time designing a general visual idea of what my final product should look like will save me hours or even days of trying/testing different looks directly with code.
• On the contrary, planning around technologies I do not yet master is secondary to dedicating the time to learn them, as I often find myself changing direction after understanding them better.