Appuyez sur Entrée pour voir vos résultats ou Echap pour annuler.

Rechargement webpack avec nginx

On sent que le web est en plein virage. Avec l’arrivée des applications monopages (single page application ou SPA), des architectures de plus en plus distribuées constituées de services et d’applications de plus en plus petites, nos environnements de développement sur nos machines peuvent devenir assez complexes à mettre en place. Aujourd’hui, on suppose que vous avez plusieurs applications frontend derrière une instance nginx, et vous constatez que le live reload de webpack ne fonctionne pas…

Pourquoi on voudrait nginx sur nos postes?

Comme je l’expliquais en intro, on voit de plus en plus des systèmes composés de plusieurs applications. L’exemple traditionnel serait d’avoir une application frontend + backend pour faire l’authentification style single sign on (SSO) qui donnerait accès à toutes les applications de l’entreprise. On peut immédiatement penser à Google. Que vous vouliez atteindre Drive, Gmail ou Play Music, vous allez passer par l’application d’authentification Google.

Si vous roulez localement une application (front + back) d’authentification avec l’application dans laquelle vous voulez faire des changements (front + back), ça vous fait beaucoup de serveurs sur plusieurs ports différents. Et c’est là que le problème sort. localhost:8080 et localhost:4200 sont deux domaines distincts, donc pas de cookies, pas de localStorage ni sessionStorage entre les deux frontend.

Un domaine unique local

En configurant nginx comme un proxy inverse devant tous les instances qui tournent sur votre poste, ça vous fait un point d’entrée unique sur le port 80. Toutes les applications deviennent donc sous le même domaine.

Un autre avantage d’avoir tout sous le même domaine, c’est que nous ne sommes plus obligés d’activer le partage de ressources entre origines multiples (Cross-Origin Resource Sharing ou CORS).

À titre d’exemple, voici à quoi ressemble la configuration nginx d’un système comme celui décrit ici :

Le proxy_pass ici fait office de configuration en mode proxy inverse. Notre serveur nginx transfert les requêtes de http://localhost/auth/ vers une instance (ici Angular) frontend et http://localhost/api/ vers une instance (ici nodejs) de services backend.

Et le live reload dans ça?

Évidemment, notre job ne serait pas aussi excitante si on ne se butait pas à 10 nouveaux problèmes dès qu’on en règle un 😂

Vous l’aurez deviné, dans cette configuration, le live reload de webpack ne fonctionne pas. Webpack utilise sockjs pour avoir une connexion en temps réel (3 parties, anglais) entre lui et le navigateur. Il crée un endpoint sur  /sockjs-node/ pour avoir cette connexion.

D’ailleurs, si vous avez déjà fait ce setup, vous devriez voir des erreurs dans la console du navigateur.

Configuration nginx pour websocket

Tout ce qu’il faut faire, c’est créer un nouveau proxy pass dans nginx afin qu’il puisse répondre aux requêtes sur l’url de sockjs. Puis, il faut dire à nginx que la requête en question doit être upgradée en connexion websocket.

Si on reprend notre exemple plus haut, la configuration devrait ressembler à :

Conclusion

Aujourd’hui, vous avez non seulement appris à configurer nginx pour qu’il fonctionne avec le live reload de webpack, mais vous avez par le fait même appris comment avoir une connexion entre un navigateur et un backend via un websocket pour faire du temps réel! J’imagine qu’il y a plusieurs autres solutions toutes aussi créatives que celle-ci, alors je veux la votre en commentaire! Sinon, partagez 🙂

Sur ce… cheers!

Suivez-nous par courriel!

Saisissez votre adresse courriel pour vous abonner au blog d'Ezo et recevoir une notification de chaque nouvel article par email.

Rejoignez 26 autres abonnés