Développeurs front : vous n’utilisez pas de proxy ?

Vous pourriez travailler directement sur la prod : pourquoi ? comment ?

Non, je ne vous parle pas de modifier directement le code en production, mais d’allier la consistance d’un serveur distant (recette, preprod, prod…) à la flexibilité de vos fichiez locaux.

Nombreux sont ceux qui ont passé des jours sur ce fameux bug qui n’est reproductible que sur le site de production avec IE8… Si vous ne le connaissez pas déjà, voici un outil qui pourrait vous intéresser : le proxy.

Utiliser un proxy

Un proxy n’est pas seulement un outil permettant de vous bloquer l’accès à Facebook lorsque vous passez par le réseau de votre entreprise. Un proxy est un intermédiaire ajouté au sein du chemin parcouru par vos requêtes HTTP. Un filtre supplémentaire qui peut assumer plein de fonctions, comme choisir, en fonction de la requête, de ne pas interroger les serveurs de destination, d’en interroger d’autres, de servir un fichier local, ou encore de modifier la réponse. Il peut également simuler des latences réseaux, bloquer des contenus, enregistrer toutes les requêtes, etc.

Il y a mille et une raison d’utiliser un proxy. Ici, je vais vous montrer comment servir vos fichiers statiques locaux sur un site distant, et les avantages que cela procure.

Donc, vous naviguez sur votre site (distant), sauf que les fichiers CSS ou JS chargés par votre navigateur sont en fait vos fichiers locaux (non minifiés, versionnés, éditables…).

On a donc ainsi :

• le jeu de données du serveur distant (le DOM, les images, les webservices, tout !) ;
• aucun serveur en local ;
• et vos fichiers CSS ou JS locaux (donc modifiables à la volée, dans votre éditeur préféré !).

Cela permet notamment de bénéficier de la rapidité des serveurs distants (souvent plus véloces qu’une VM locale), et d’épargner la charge de son ordinateur en vous affranchissant d’un environnement de développement local (base de données, serveur web, serveur d’application, éventuelle compilation des sources et autres tâches chronophages qui, au final, ne vous concernent que peu si vous êtes développeur front).

Notez cependant que pour les débuts de projets, ou pour la création de nouvelles pages, ou pour tout changement de DOM important, cela n’est probablement pas une solution adaptée. En effet, soit vous utilisez une maquette statique, soit vous mettez directement à jour les templates de la solution choisie, mais dans tous les cas, votre page n’existe pas encore sur le serveur distant.

Quels sont donc les possibilités pour mettre en place un tel proxy ? Il existe 2 types de solutions distincts : interfaces graphiques, ou ligne de commande. Je vais vous présenter rapidement l’implémentation de chaque type de solution via des choix de solutions personnels. Je vous invite à en tester d’autres et choisir celui qui vous convient.

Charles proxy

Si vous n’êtes pas familiers avec npm, gulp ou grunt, que cela ne vous intéresse pas, ou tout simplement si vous préférez les interfaces graphiques, vous pouvez utiliser Charles proxy (son grand concurrent est Fiddler, que je connais moins).

A noter que Charles n’est pas gratuit, c’est un shareware, mais il est possible de le tester gratuitement pendant 30 jours.

Charles utilise par défault le port 8888 sur lequel vous pouvez rediriger vos requêtes (voir plus bas).

Si vous êtes en HTTPS, assurez-vous d’activer le proxy SSL pour votre domaine : visitez votre page, puis faites un clic droit sur votre domaine, et choisissez Enable SSL Proxying, comme ci-dessous :

Pour mapper un fichier distant afin qu’il soit remplacé par un fichier local, faites un clic droit sur le fichier distant en question, et utilisez l’option Map Local.

Puis choisissez votre fichier local.

Pour vous simplifier la tâche, vous pouvez tout aussi bien mapper directement des dossiers.

Vous avez également la possibilité d’enregistrer les réponses sur le disque, ce qui vous permet par exemple d’enregistrer une page HTML du site distant, d’en modifier le DOM et de la mapper pour servir le DOM modifié.

Charles est donc une solution efficace et rapide à prendre en main, et qui ne nécessite aucune ligne de code, mais elle reste à l’initiative de chaque développeur qui ne pourra pas aisément partager toute sa configuration avec ses confrères : certes, il est possible d’exporter la configuration en xml via le menu “Tools → Import/Export settings”, mais le mapping local est alors sauvegardé avec un chemin absolu, ce qui risque de ne pas fonctionner (le partage des autres configurations reste possible).

Proxy nodejs

Nodejs est à mon sens le meilleur choix d’environnement pour un proxy en ligne de commande, car c’est aujourd’hui la technologie sur laquelle s’appuient les outils de build préférés des frontistes tels que grunt, gulp, et autres. Cependant, je n’exclue pas que d’autres solutions soient envisageables.

Cette solution, bien qu’elle nécessite quelques lignes de code (assez simples), comporte de nombreux avantages :

• installation du proxy via npm (multi-support) ;
• configuration versionnée et partagée par tous les membres du projet ;
• intégration avec les outils de build existants.

NProxy

J’utilise pour ma part le module NProxy de goddyZhao, qui correspond à mes attentes grâce à sa bonne gestion des expressions régulières, mais il est surtout capable de concaténer plusieurs fichiers à la volée (ce qui peut également être effectué via un watcher, mais c’est souvent moins rapide).

Cependant, NProxy ne permet pas de configuration dynamique : il faut spécifier le chemin du fichier de configuration, qui est alors lu sans options d’entrée.

Comme j’avais besoin d’une configuration plus flexible (qui dépende de paramètres entrés en ligne de commande), j’ai donc réalisé un fork de ce module afin de pouvoir renseigner directement une map en paramètre au lieu du chemin du fichier.

Je l’utilise dorénavant sur tous mes projets, avec grunt ou gulp. Voici un exemple de configuration contenant le fichier de mapping (nproxy-conf.js) et le fichier de configuration gulp ou grunt (selon vos préférences) : exemples. Avec un fichier de documentation type pour le projet, cela permet une installation et configuration du proxy très rapide (car vous ne voulez pas concentrer vos efforts là-dessus).

On peut voir par exemple dans le fichier de configuration que je l’utilise parfois pour remplacer les scripts tiers (e.g. les scripts de recueil de données analytiques) par des fichiers vides (donc désactivés), ce qui peut permettre de diagnostiquer rapidement la responsabilité d’une éventuelle erreur de script :

if(options.external === false) {
  console.log('NO EXTERNAL (scripts are served empty)') ;
  mapping.push({
    pattern   : /(some-analytics-provider|some-other-service-provider).*\.js/,
    responder : js_folder + 'empty.js'
  }) ;
}

Tout utilisateur du projet ayant récupéré les fichiers versionnés peut alors lancer un proxy déjà configuré sur sa machine via deux lignes de commande (l’installation de npm est cependant un prérequis) :

> npm install
> gulp/grunt nproxy

Utiliser le proxy

Configurer son navigateur ou sa VM pour utiliser le proxy

Nous avons donc un proxy actif sur notre machine (Charles, NProxy ou autre), et il nous faut donc maintenant indiquer au navigateur que les requêtes (certaines ou toutes) doivent transiter par ce proxy.

Vous pouvez configurer le proxy au niveau du système ou dans les options du navigateur avec le paramètre suivant : localhost:8888 si Charles, localhost:8989 si NProxy. Dans certains cas, Charles est capable de faire la configuration automatiquement : http://www.charlesproxy.com/documentation/configuration/browser-and-system-configuration

Toutes les URLs non reliées à des fichiers locaux vont être récupérées auprès du serveur distant : le rôle du proxy est alors transparent pour ces requêtes (à quelques problèmes de certificats près pour les connexions sécurisées).

Mais vous l’aurez compris, faire passer tout votre trafic par votre proxy, ce n’est pas vraiment nécessaire ni souhaitable. Dans le cas d’une machine virtuelle, par exemple dédiée à Internet Explorer, la configuration au niveau du système n’est pas un problème car vous n’affichez probablement que votre site (pensez à remplacer localhost par votre adresse IP).

Exemple de plugins navigateurs

De nombreux plugins (sous forme d’extensions de navigateurs) permettent de facilement activer/désactiver le proxy au niveau du navigateur, ainsi que de paramétrer quelles URLs passent par le proxy, et lesquelles restent en connexion directe (on peut également diriger différentes requetes vers différents proxys).

J’utilise les extensions suivantes, mais bien d’autres possibilités sont envisageables :

SwitchyOmega sur chrome

FoxyProxy sur Firefox

Si ce n’était pas déjà le cas, j’espère vous avoir convaincu de l’utilité d’un proxy pour vos développements front et de tous les avantages que cela procure. Pour ma part, j’ai eu l’impression de grandement gagner en productivité et je ne peux plus m’en passer !