Clairtemps

01. Réflexion sur le front

Après plusieurs jours de travail sur le backend, nous avons envisagé d'abandonner Vue.js au profit de Twig, jugé plus simple. Cependant, l'accent du projet étant mis sur l'UI et l'UX, l'utilisation d'un framework réactif s'est imposée comme indispensable. Nous avons donc maintenu Vue.js malgré la complexité supplémentaire.

02. API externe

Pour l'accès aux données météo, j'ai créé un compte étudiant sur OpenWeatherMap, permettant pendant six mois l'accès à davantage de données qu'un compte gratuit. Malgré cela, certaines limitations de l'API (absence d'alertes météo et de détails avancés des prévisions) ont directement influencé nos choix d'interface et de fonctionnalités.

J'ai pris en charge la mise en place d'un service côté backend Symfony, permettant d'appeler les routes de l'API OpenWeatherMap et d'exposer nos propres routes au frontend. Côté frontend, j'ai intégré les requêtes API afin de récupérer et afficher les données météo.

03. Développement Frontend

Grâce à Vue.js, j'ai pu concevoir des composants réutilisables et mettre en place un store Pinia pour centraliser et partager les données météo entre les composants. Cette étape s'est révélée particulièrement exigeante, Pinia étant une technologie que j'utilisais pour la première fois dans un contexte réel, avec une volonté de rendre les méthodes génériques et réutilisables.

Par la suite, je me suis concentrée sur le frontend, afin d'éviter les conflits liés au travail simultané sur le backend. J'ai ainsi développé plusieurs composants permettant :
• l'affichage de la météo en direct pour une ville,
• la consultation des prévisions horaires,
• l'affichage des prévisions sur 15 jours via une interaction utilisateur.

04. Optimisation

Enfin, afin de limiter le nombre de requêtes vers l'API externe (un enjeu important dans ce type de projet), j'ai implémenté un système de mise en cache, permettant d'optimiser les appels externes et de réduire la charge sur l'API ainsi que sur le serveur backend.