DEV Community: Amine Affif

Migrating a critical module without pausing delivery: how I did it

Amine Affif — Fri, 09 Oct 2026 06:00:00 +0000

A critical scheduling module ran on Vue. It had to move to React, and the product couldn't stop for three months.

The obvious approach is to rebuild everything and switch over in one go. It's also the riskiest: if something breaks on the day, there's no way back.

We did something else. Both versions stayed usable in parallel for three months. We could move a user to the new one, then bring them back to the old one, without losing their context.

The real technical problem was state. Filters, period, position on the screen: all of it had to follow the user in both directions, from the old version to the new one and back. If the state doesn't carry over, the user sees the seam, and stops trusting the new version.

That means keeping the transfer alive for the whole migration. In exchange, there's no single risky switch-over, and no freeze on delivery.

The project also included bulk actions and nine languages. There were eight of us, and the project ran for three months.

A user who switches versions without losing their filters has nothing to wonder about. That was the goal.

Amine Affif, full-stack developer in Paris. amineaffif.com

Migrer un module critique sans interrompre la production : comment j'ai fait

Amine Affif — Thu, 08 Oct 2026 06:00:00 +0000

Un module de planification critique tournait sur Vue. Il fallait le migrer vers React, et le produit ne pouvait pas s'arrêter trois mois.

La solution évidente, c'est de tout reconstruire puis de basculer d'un coup. C'est aussi la plus risquée : si quelque chose casse le jour J, il n'y a pas de retour en arrière.

On a fait autre chose. Les deux versions sont restées utilisables en parallèle pendant trois mois. On pouvait passer un utilisateur sur la nouvelle, puis le ramener sur l'ancienne, sans qu'il perde son contexte.

Le vrai sujet technique, c'était l'état. Filtres, période, position dans l'écran : tout ça devait suivre l'utilisateur dans les deux sens, de l'ancienne version vers la nouvelle et inversement. Si l'état ne passe pas, l'utilisateur voit la couture, et il ne fait plus confiance à la nouvelle version.

Ça demande de faire vivre ce transfert pendant toute la migration. En échange, il n'y a pas de bascule unique à risque, et aucune livraison n'est gelée.

Le chantier incluait aussi les actions de masse et neuf langues. On était huit sur le chantier, qui a duré trois mois.

Un utilisateur qui change de version sans perdre ses filtres n'a rien à se demander. C'était l'objectif.

Amine Affif, développeur full-stack à Paris. amineaffif.com

Lancer une boutique en ligne : le code n'était que la moitié du travail

Amine Affif — Tue, 06 Oct 2026 06:00:00 +0000

Une marque D2C m'a demandé de lancer sa boutique en ligne. Sur le papier, c'est un travail de dev : un WooCommerce, Stripe pour les paiements, quelques fonctionnalités sur mesure comme un zoom produit.

Mais une boutique qui existe ne vend pas pour autant. Le vrai sujet, c'est que les commandes arrivent.

J'ai donc pris les deux côtés. La technique : la boutique, les paiements, la connexion au CRM du fournisseur. Et l'acquisition : les campagnes Meta et Google Ads, plus le contenu qui va avec.

Pourquoi les deux ? Quand le dev livre et passe la main, personne ne suit vraiment ce qui se passe entre le clic sur une pub et la commande. Quand c'est la même personne, on voit vite si une page fait perdre des commandes, et si le problème vient du code ou de la pub.

Pour un dev, ça change la question de départ. On ne demande plus « la fonctionnalité est-elle livrée ? » mais « qu'est-ce qui bloque la commande ? ». Un chargement lent, un paiement qui échoue, une photo qui ne rassure pas : tout devient un sujet de code.

Résultat : une boutique rentabilisée.

Amine Affif, développeur full-stack à Paris. amineaffif.com

A 44-second export: measure before you look

Amine Affif — Sun, 04 Oct 2026 18:26:20 +0000

When I hit a slowdown, I write three things down first: what I instrument, what I compare, and what would make me drop my hypothesis. Ten minutes. Without it, I follow the first lead that looks logical, and that doesn't make it the right one.

Three examples.

The 44-second export

An export took 44 seconds. I measured before assuming: more than 42 seconds were spent in the application, before the call to the service even started. The service itself answered in a little over a second.

The culprit: cascading queries. A generic example, not the original code:

# 1 query for the accounts, then 1 per account
accounts.each { |a| puts a.employees.count }

# 2 queries, whatever the number of accounts
accounts.includes(:employees).each { |a| puts a.employees.size }

The biggest accounts

Another slowdown, only on the very large accounts. I started over: I instrumented the front end and the back end, then compared three account sizes. What grows with the account is the bottleneck.

I fixed the cascading queries instead of adding a cache, because a cache hides the problem without solving it. The backend fix is in production, and I went through the other places with the same flaw.

The display bug

It looked like a UI bug. Digging back, it was a business rule being bypassed. What settled it: no screen in the app lets you create that state by hand, so it came from somewhere else. The subject was no longer the display, it was a decision for someone a level up.

And if an analysis I posted turns out to be wrong, I correct it in the same place.

The rest of how I work is at amineaffif.com/en/methode.

Amine Affif, full-stack developer in Paris.

Version française : Un export de 44 secondes : mesurer avant de chercher

Un export de 44 secondes : mesurer avant de chercher

Amine Affif — Sun, 04 Oct 2026 18:24:47 +0000

Quand je tombe sur une lenteur, j'écris d'abord trois choses : ce que j'instrumente, ce que je compare, et ce qui me ferait abandonner mon hypothèse. Dix minutes. Sans ça, je pars sur la première piste qui a l'air logique, et ça ne veut pas dire que c'est la bonne.

Trois exemples.

L'export de 44 secondes

Un export mettait 44 secondes. J'ai mesuré avant de supposer : plus de 42 secondes se passaient côté application, avant même l'appel au service. Le service, lui, répondait en un peu plus d'une seconde.

Le coupable : des requêtes en cascade. Un exemple générique, ce n'est pas le code d'origine :

# 1 requête pour les comptes, puis 1 par compte
accounts.each { |a| puts a.employees.count }

# 2 requêtes, quel que soit le nombre de comptes
accounts.includes(:employees).each { |a| puts a.employees.size }

Les plus gros comptes

Une autre lenteur, uniquement sur les très gros comptes. Je suis reparti de zéro : j'ai instrumenté le front et le back, puis comparé trois tailles de compte. Ce qui grossit avec le compte, c'est le goulot.

J'ai corrigé les requêtes en cascade plutôt que d'ajouter du cache, parce qu'un cache masque le problème sans le régler. Le correctif backend est en production, et j'ai recensé les autres endroits qui avaient le même défaut.

Le bug d'affichage

Ça ressemblait à un bug d'interface. En remontant, c'était un contournement d'une règle métier. Ce qui a tranché : aucune vue de l'application ne permet de créer cet état à la main, donc il venait d'ailleurs. Le sujet n'était plus l'affichage, c'était une décision à prendre un niveau au-dessus.

Et si une analyse que j'ai postée se révèle fausse, je la corrige au même endroit.

Le reste de ma façon de travailler est sur amineaffif.com/methode.

Amine Affif, développeur full-stack à Paris.

English version: A 44-second export: measure before you look