Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ajouter un système de retéléchargement périodique #2

Open
laem opened this issue Dec 29, 2023 · 1 comment
Open

Ajouter un système de retéléchargement périodique #2

laem opened this issue Dec 29, 2023 · 1 comment

Comments

@laem
Copy link
Collaborator

laem commented Dec 29, 2023

Les GTFS fournis par les régions et collectivités ont une durée de vie très courte. Quelques jours ou semaines pour la Bretagne.

J'ai une route /fetch qui permet de retélécharger le dernier fichier. Il faudrait le faire automatiquement en écoutant les changements de transport.data.gouv.fr.

Une sorte de CRON.

À voir si passer à Deno Deploy ne pourrait pas être intéressant. J'ai testé sur un autre projet, c'est bluffant. Notamment, les 2 minutes de compilation de Scalingo à chaque commit m'embête. On itère pas rapidement. Sans compter les 10 € / mois du serveur immobilisé toute la journée pour pas grand chose.

Mais sur Deno Deploy, voir comment stocker les données. Là, elles sont sur le disque / en mémoire.

@laem
Copy link
Collaborator Author

laem commented Mar 5, 2024

Voilà mon plan.

Un script update.ts déployé sur Deno deploy pour sa fonctionnalité CRON.

Tous les jours, d'abord le jour pour controller, puis la nuit pour moins déranger, il va taper motis.cartes.app/update.

Qui déclenche yarn build-config, qui va télécharger les GTFS qu'on a listé dans input.yaml. C'est peu optimal, car beaucoup ne changent pas toutes les nuits, donc si quick win (hash ?) pour éviter ça tant mieux, sinon pas grave pour une première version.

C'est chiant qu'on puisse pas lancer yarn start avec Deno, ça nous permettrait d'avoir un seul serveur qui fait à la fois node-GTFS et son /fetch, et le build-config.

Mais c'est pas très grave : un serveur Deno tout con se charger de lancer buildConfig.ts. Si on arrive dans le futur à faire la fonctionnalité de Deno deploy cron mais en local, avec dashboard d'état et tout, tant mieux.

Donc : deno deploy cron -> /update -> deno buildConfig.ts -> fichiers GTFS téléchargés sur le disque ; /fetch sur l'express node-gtfs ; restart motis service.

Dans le futur il faudra bosser la fiabilité de ce process : pouvoir afficher sur cartes app la date de MAJ des différents GTFS à la fois dans motis et node-gtfs, et aller récupérer en direct en mode contradictoire côté client la date de dernière MAJ sur transport.data pour confronter.

Cet écran est essentiel pour pouvoir lister les zones supportées. Il est à implémenter sur la vue actuelle des réseaux de transport.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant