Je pense que cela s'applique à tout framework Web utilisant un pack web qui construit des actifs / morceaux, dans mon cas, c'est Vue.
Mon flux de travail est:
Le bâtiment supprime tous les morceaux précédents au fur et à mesure que de nouveaux sont ajoutés, c'est-à-dire
mon-module.1X3DF23.js
mon-autre-module.9DFdw232.js
Si un utilisateur était sur le front-end en même temps sans actualiser la page (SPA, donc peu probable) et accède à une nouvelle vue qui dépend d'un morceau qui a été effacé, il obtient un 404 pour ces anciens éléments manquants.
Jusqu'à ce point, j'ai incrémenté un numéro de version avec toutes les requêtes XHR du serveur. Si l'application remarque un changement, elle se rechargera d'elle-même. Mais si des erreurs 404 proviennent de blocs, aucune requête XHR ne sera de toute façon appelée.
Premières réflexions:
Des alternatives?
3 Réponses :
Je préférerais ne pas supprimer du tout les blocs précédents. Je ne sais pas comment fonctionne Elasticbeanstalk donc je vais vous montrer ma stratégie avec un bon vieux serveur ubuntu.
En gros, vous avez ces dossiers dans votre application Vue:
cp -R dist/* deploy/
Ce que je fais, c'est que je crée un nouveau dossier nommé deploy car l'un des problèmes du dossier dist est que npm run build supprime le contenu de le dossier dist au début de la construction.
Ayant le dossier deploy , vous pouvez conserver toutes les données nécessaires dans le temps.
Ainsi, lorsque je construis mon projet, je copie le contenu du dossier dist dans le dossier deploy sans supprimer les morceaux précédents.
Afin d'éviter que le dossier deploy n'interfère avec git, je l'ajoute au registre .gitignore .
Vous peut le faire avec un simple collage récursif en utilisant bash:
dist -> Contains the content of the built application with npm run build node_modules public src ...
Cela remplacera votre page index.html dans le dossier de déploiement mais n'écrasera pas votre blocs précédents.
Problème avec cette solution: Votre dossier deploy peut devenir énorme car les blocs précédents ne seront jamais supprimés.
Solution à ce problème: écrivez un script robuste qui supprime les morceaux datant de plus d'un jour (ou plus) lors du déploiement de l'application. Vous pouvez baser votre script sur la date de création du fichier. Si vous maîtrisez bash, allez-y. Personnellement, je préfère écrire ce genre de script avec node directement dans un script deploy.js à la racine de mon projet ..
Solution viable. Je pourrais configurer un script .ebextensions qui pourrait conserver les 5 derniers ensembles de morceaux. Attendrons quelques jours de plus au cas où quelqu'un d'autre interviendrait, mais vous êtes un concurrent sérieux pour les 50 pièces d'or.
Je vous suggère de faire ce qui suit
Pensez à une ressource URL statique que vous diffusez comme suit
abc.com/v1/module.123.js
Je vous suggère de conserver le
v1
Partie identique entre vos mises à jour de build.
Webpack générera un nouveau nom de fichier comme suit
build1: module.123.js
build2: module.234.js
chaque fois que le contenu de module.js change entre vos builds.
Pendant les mises à jour de votre build, assurez-vous de ne pas supprimer votre
v1
dossier de votre serveur. Au lieu de faire un remplacement complet, vous pouvez fusionner l'ancien dossier et le nouveau dossier. En faisant cela, vous aurez les deux
module.123.js
module.234.js
dans votre dossier v1 sur le serveur. En faisant cela, vous éviterez l'erreur http 404 dans le SPA.
Vous pouvez informer l'utilisateur d'une mise à jour de build via un autre processus et lui demander d'actualiser le navigateur pour obtenir les modifications. Cette notification des modifications à l'utilisateur peut être effectuée à l'aide d'un Événement envoyé par le serveur
Vous pouvez changer le dossier V1 tous les 6 mois environ en V2 ou quelque chose d'autre qui répond à vos besoins pour nettoyer les fichiers inutilisés.
Si votre application est une application 100% statique, vous pouvez utiliser le compartiment AWS S3. Pour mettre à jour votre application, il vous suffit de mettre à jour votre dépôt.
aws s3 sync --delete / source / destin
Nous avons fait cela et la mise à jour est transparente comme vous vous y attendez.
Vous n'êtes pas sûr de comprendre l'exigence. Il s'agit de gérer une vue qu'un utilisateur a pu charger et quels blocs de référence sont écrasés lors du déploiement. S'ils n'ont pas rechargé leur page, les anciennes routes vers les morceaux seront interrogées et 404 seront renvoyées.
Pas tout à fait ... Si vous avez configuré vos morceaux pour avoir le hachage dans leurs noms, le navigateur ne tirera pas les nouveaux fichiers à moins que ce code de hachage n'ait été modifié / mis à jour. Si vous utilisez cloudFront, ils ont également leur cache interne que vous pouvez utiliser en votre faveur.