DIMITRI BOURREAU

Next.js overhaul in 6 months: hexagonal architecture, React Query, and above all the human side!

Pages taking over ten seconds to load, countless puzzling rerenders, absurd bugs... Many of us know this picture all too well! 6 months after joining my client, we had brought load times under one second on the screens that were causing problems, the application was smooth, and the clients had their smiles back! But for me, the real lesson from this engagement wasn't technical — it was human.

The state of things

The application had grown without any clear structure. Redux was managing a global state that had become sprawling and unwieldy. No tests. No Storybook. Every change was a gamble. The developers spent more time dreading regressions than actually building.

Load times ranged between 4 and 12 seconds depending on the page, with spikes beyond 10 seconds on the heaviest screens — especially those embedding PowerBI reports in iframes.

The technical overhaul

Rethinking state management

I removed Redux. Completely. And replaced it with React Query.

This choice drastically simplified the code. No more reducers, no more actions, no more global state to synchronize manually. React Query handles caching, refetching, and loading states. The code became declarative and predictable.

Tracking down performance issues

The performance work was methodical: identifying unnecessary rerenders, optimizing API calls to our backend, and above all dealing with the PowerBI iframes that were dragging down the experience.

On the most critical pages, we went from over 10 seconds to under one second. Across the entire application, load times dropped from 4-12 seconds to 1-3 seconds. Less flashy than a marketing "x10" claim, but a real and noticeable improvement for users.

Hexagonal architecture

I restructured the code by separating the business domain from the infrastructure. React components no longer know about API implementation details. The code became testable, changes were isolated, and the team could work in parallel without stepping on each other's toes.

Building a real testing strategy

There was nothing. I set up three levels of testing:

Unit tests for pure business logic — business rules, data transformations, everything that doesn't depend on React.

Storybook to visualize and document components in isolation.

End-to-end tests with one important twist: I made it possible to test the frontend without any backend server. This was essential. Testing front and back together, yes, to validate the integration. But being able to test the frontend independently allowed for fast feedback cycles and real confidence in our deployments.

The people who left a mark on me

Thomas — the friend

Thomas was a junior developer when I arrived. Extremely motivated, ready to invest himself. We spent hours talking about software craftsmanship, reading together, debating conference talks. I mentored him as he grew his skills, and he has since gone freelance.

But above all, we became close friends. This engagement reminded me that work can create bonds that go beyond the professional sphere.

Aurelien — the diplomat

Aurelien was a freelance backend developer. Excellent developer, but it was his attitude that taught me the most.

He naturally sought middle ground. Sometimes, his lack of a clear stance on straightforward issues would quietly frustrate me. Why not just make a call? Why stay in the gray area?

In hindsight, I drew a lot of inspiration from him. His eloquence, his charisma, his ability to navigate tense situations. He taught me that accommodation isn't necessarily manipulation. That this approach can be reassuring, even stabilizing for a team. Not everyone needs you to cut through every decision with a sharp blade.

Yvon — the protector

Yvon was the CTO. He frustrated me sometimes too — his apparent lack of decisiveness got to me.

But he was deeply human. And I later understood that he carried an enormous amount of pressure on his shoulders to protect the team. He absorbed the tensions coming from above so we could work in peace. It's not visible leadership, but it's real leadership.

Olivier — the leader

Olivier was the Product Owner. Excellent speaker, natural charisma, always attentive to technical concerns — but always ready to challenge them to find the right balance between technical ideals and product reality.

He was tireless. I admired him for that. He embodied what I would like to become in terms of soft skills: someone who brings people along without overwhelming them.

What I learned about myself

My code reviews were too rigid

At first, I wanted every PR to meet my standards. Every deviation frustrated me. I realized I was creating unnecessary friction.

Today, I distinguish the essential from the preferential. A potential bug? Non-negotiable. A naming choice I would have done differently? I let it go, or I suggest without insisting.

Perfect code doesn't exist. Code that works and that the team understands does.

I was getting too attached to the project

I put a lot of myself into this overhaul. Too much, perhaps. When you invest that much, you end up identifying with the code you write.

I learned to let go. The project continues without me. Others will make different choices. That's normal, that's healthy.

Delivering a maintainable system and an autonomous team is worth more than being indispensable.

What I take away from it

Technical excellence isn't enough. Knowing how to refactor an app is good. Knowing how to bring a team along, accept imperfection, learn from others, and build for those who will come after — that's better.

At Artelia, I significantly improved the performance of an application. But most importantly, I met people who helped me grow. Thomas reminded me why I love passing on knowledge. Aurelien taught me diplomacy. Yvon showed me what it means to protect a team. Olivier gave me a model for leadership.

14 months. A transformed app. And a transformed me.