Mettre son app VueJS + Express en production
Salut !
J'ai découvert VueJS grâce à Grafikart et je travaille avec NodeJS depuis un moment et j'aimerais beaucoup travaillaient avec les deux, après avoir fait quelque test, pages, etc.. en utilisant Express en API et VueJS avec Webpack il m'est venu une question dont je cherche la solution mais ne trouve pas la réponse :/
Voilà, quand on lance la commande npm run dev pour dev sur VueJS en local, d'ailleurs, en local je lance mon api sur un autre port car Webpack prend déjà le 8080 et je n'arrive pas à faire fonctionner les deux sur le même port.
Bref, je me disais, quand on a fini de dev, finalement on lance la commande npm run build mais après ? et là je bloque. On inclut le build js dans un fichier index ?
Ou peut-être qu'avec Vue Js + Express il faut mieux développer en incluant directement Vue avec le script tag ?
Personnellement, j'utilise beaucoup Vue Resource et Vue Router et quand je build et inclus juste le js, j'ai en général quelques problèmes (surtout Vue Router).
Voilà, si l'un d'entre vous a des conseils ou des manières de faire à partager ça serait sympas ! Merci d'avance :)
6 réponses
il suffit de créer une route express qui sert un fichier static html avec tous ce qu'il faut dedans pour ton application.
Selon-vous, est-ce que on peut structurer une application suivant ce modèle :
- Express n'est là que pour répondre au requêtes get, put, delete, etc.. nécessaire au fonctionnement du site (système d'utilisateurs, articles, etc)
- VueJS s'occupe du client, il design notre application, il la route, etc..
Et je comprend pas trop le système de servir un fichier statique simplement, perso, j'utilise webpack, donc des fichiers .vue, on peut pas servir un fichier .vue comme un fichier html, à mon avis.
C'est au moment du build que je comprend plus le fonctionnement VueJS, car on se retrouve juste avec un fichier build.js et un index.html, à moins que j'ai mal compris la mise en production de l'application, car je pense pas qu'on upload nos fichiers .vue sur notre serveur..
"il suffit de créer une route express qui sert un fichier static html avec tous ce qu'il faut dedans pour ton application."
Je déconseille fortement de servir les fichiers static avec nodejs/expressjs -> très grosse perte de performance.
Tu peux utiliser nginx (ou apache) pour servir les fichiers statics, pourquoi pas même ne pas mettre HTTP2 en protocole?
@Nealll déconseillé également : 100% composants = 0 en SEO ^^
Le fichier build.js contient le chargement des composants ect, tu le charges sur la page pour qu'il rende le DOM.
@Nealll:
La structure dont tu parle, c'est simplement une REST API avec du js en front.
En somme, tu as deux "partie", le front end, et le back end qui sont deux entitées différentes, avec l'une ne servant qu'a distribuer des données.
Au niveau de VueJS, si tu utilise le template de webpack, tu as une commande npm run build qui va te compiler le tout et le minifié dans un dossier dist. Il te suffit de prendre le contenu de ce dossier et de le mettre en prod.
Dans ce dossier tu trouveras un fichier html (ton index.html), et un dossier assets avec le css, le js, et tes assets (fonts, images, ...). Lors du build, webpack va extraire le contenu de ta balise <script> de tes fichiers vue pour la mettre dans ton js, et idem pour les css.
C'est aussi ce qui se passe avec npm run dev, il suffit de regarder tes sources depuis ta console dévellopeur pour t'en rendre compte.
Comme l'a dit Emix, c'est une mauvaise idée d'utiliser Node pour servir les vues, car, dans le cas de forte charge, NodeJS prendra toute la charge dans la tronche. Alors que si tu utilise nginx/apache avec un vhost pour tes vues, c'est le service web qui va prendre la charge, et c'est beaucoupl plus simple de scaler apache/nginx que node.
Il faut aussi prendre en compte que, si tu utilise ton api pour rendre tes pages, tu ne pourra pas l'utiliser pour faire une app mobile plus tard par exemple. Une REST API te permet de faire plusieurs vues différentes avec une seule api.
Par contre, je vais à l'encontre de Emix, du 100% components n'est pas déconseillé.
Tout dépend de tes besoins. Si tu n'a pas besoin que le contenu de ton site soit référencé, alors, tu n'a pas de soucis à te faire à ce niveau là. Ton site sera référencé, mais comme les crawlers sont synchrone, ils n'attendront pas que ton js soit chargé (donc pas de component chargé).
Et, même si tu voulais que ton contenu soit référencé, tu pourrais simplement utiliser du Server Side Rendering pour que ton serveur s'occupe du rendu de tes components, du coup, quand un crawler (ou un client) arrive sur ta page, tout est déjà chargé, et pas besoin d'attendre que le js charge le contenu.
Effectivement, mais ceci étant dit c'est plutôt rare qu'un site n'ai pas besoin d'être bon en référencement.
Et au niveau du serveur side rendering (attention ce n'est que mon avis) je trouve ça overkill pour le moment :/
Merci @elhebert pour ta réponse, j'utilise déjà nginx pour servir mes fichiers statiques et c'est vrai que c'est mieux.
Par contre concernant le build de webpack, il ne build que un fichier index.html tu me dit, le problème, si je veux servir les routes avec mon app express, par exemple quand j'arrive sur ma page /articles il me sert un fichier .html qui correspond à ma page, pareil pour /user par exemple, mais, vu qu'il génère un seul fichier .html, comment gérer plusieurs vue ?
En faite, pour résumer, en tant normal, j'utilise EJS, j'ai des routes, /articles, /users, etc.. et à l'appel de ces routes je fais un res.render('article.ejs) par exemple, mais avec vue comment gérer ça ?
Désolé si je suis pas assez clair, mais j'ai du mal à me faire à la logique du build de webpack qui me sert un index.html, je peux pas servir le même fichier .html à toutes mes pages :/
Au final pour ça, je me demande si inclure vuejs en script tag à la fin de mon body ne serait pas plus simple ^^