Giter Site home page Giter Site logo

nicolasdaudin / pulpito Goto Github PK

View Code? Open in Web Editor NEW
3.0 2.0 0.0 5.91 MB

Home Page: https://pulpito-app.herokuapp.com/

JavaScript 5.82% Pug 7.21% CSS 29.69% TypeScript 57.28%
flight flights axios express flight-search flight-search-backend flight-search-engine kiwi mongoose nodejs

pulpito's People

Contributors

nicolasdaudin avatar

Stargazers

avatar avatar avatar

Watchers

avatar avatar

pulpito's Issues

Améliorer temps de chargement sur le front

Améliorer le temps de chargement.
Une requête de /common depuis le front prend mini 500ms, meme avec le cache (la partie /common) puis 500-700ms de plus pour l'affichage.

Nettoyer le code

Vérifier et améliorer le test coverage

  • chercher un indicateur "automatisé" de test coverage
  • vérifier les tests importants qui pourraient manquer (voir npm run cover)
  • rajouter des tests pour validatorService
  • améliorer les tests si des tests importants manquent
  • voir si les tests de Controller font vraiment sens ou ne faire que des tests d'intégration "à part" ou direcement des functional qui n'ont plus besoin de tout mocker .... car certains controllers ne font pas grand chose d'autres que d'appeler des fonctions sous-jacentes
  • cleaner tests de destinationsController pour qu'ils ne testent que destinationsController et ne teste plus l'appel API via FlightService
  • destinationsService: tester buildCommonItineraries ? ou bien les tests sont déjà deux dans destinationsController?!?
  • Les tests qui appellent effectivement l'API Kiwi et ne sont pas desu nit tests => à supprimer et/ou à migrer de forme équivalente dans les tests fonctionnels (ou d'intégrations?)
  • avoir un fichier integration.test.js?
  • rajouter https://github.com/pamepeixinho/jest-coverage-badges
  • nettoyer les logs (y a bcp de logs encore dans les tests, qqn qui rentre dessus ne comprendrait pas... même si l'important c'est le tests case, non, qu'il soit OK?)
  • enlever les skipped tests: soit les supprimer, soit en TODO

Par ex dans DestinationsController.test.js pas sûr qu'il faut plus ou moins de tests. Dans les error case on fait appel à l'API, on ne la mocke pas. Est-ce nécessaire? On est plus vraiment en isolation si on fait ça ....

EPIC En tant que user de Pulpito, je veux trouver les dates les moins chères pour une destination donnée, pendant certaines périodes (i.e. vacances scolaires)

Par ex les vacances scolaires ES c'est Semana Santa et Noel et Verano, les vacances scolaires FR par Zone c'est Toussaint, Noel, Hiver, Pâques puis éte.
On pourrait :

  • encoder les vacances dans un JSON, en "dur"
  • inclure ou non les weekends, aussi
  • inclure ou non toutes les vacances scolaires

Le user devrait dire le minimum et maximum de jours qu'il veut partir ... (et si c'est supérieur à 2, du coup, mécaniquement on regarde plus les weekends.....)

Techniquement il faudra faire une query pour chaque période de vacances, pour cette origine et destination...

Rejoint un peu #33

Déployer sur Heroku

  • Déployer
  • Vérifier que les routes AUTH fonctionnent toujours
  • Vérifier que les routes DESTINATIONS fonctionnent toujours

EPIC - En tant que user de l'interface, je veux que mon app soit multi-langue et multi-monnaie

Ce que j'aimerais

Anglais-Français-Espagnol
USD et EUR

A faire

Général

Il faut adapter le front:

  • sélecteur de langue et de monnaie
  • textes
  • dates
  • prix

Il faut adapter le back:

  • requête à KIWI avec la langue et la monnie
  • conserver la langue et monnaie entre chaque requete
  • choisir une langue et monnaie par défaut

Ça fait sens de faire sans changement de monnaie?

Si je publie sur Product Hunt, le public potentiel majoritaire c'est les USA, donc dollars $ USD ....

Est-ce que c'est une vanity feature?

Oui, c'est une vanity feature. Le but de ce portfolio project c'est d'avoir un moteur de recherche "pour moi" de vols, voir si je peux l'utiliser ... l'API est suffisamment "robuste" pour me permettre de chercher des vols sur un weekend, ou la destination la moins chère prochainement ...
Et puis c'est tout. Pas besoin de plus.
Plutôt que de passer du temps là-dessus, sur une NOUVELLE feature qui va compliquer un peu tout (et qui apporte très très peu niveau back-end), je vais fermer le projet, pour avoir une "version propre" et s'il me reste du temps, j'améliore l'API, je la documente ....

Feature history

J'avais déjà commencé mais j'ai rollbacké car peu d'intérêt pour un portfolio project
Si je publie sur Product Hunt, pourquoi pas.

Utiliser la librairie i18n-node

voir https://github.com/mashpie/i18n-node

Code dans app.js:

const i18n = require('i18n');
i18n.configure({
  locales: ['en-us', 'en-gb', 'fr', 'es'],
  directory: `${__dirname}/locales`,
  queryParameter: 'lang',
  cookie: 'lang',
});
app.use(cookieParser()); // add cookie parser middleware
app.use(i18n.init);

Mais si je sépare currency et locale, alors je peux avoir que 'en' comme locale.
Faut rajouter cookieParser sinon on peut pas récupérer le cookie.

Et dans viewController:js on rajoute la langue comme cookie.

exports.getHome = (req, res) => {
  if (req.query.lang) {
    const lang = req.query.lang;
    res.cookie('lang', lang, { maxAge: 900000 });
  }
  res.status(200).render('home');
};

Et les liens du menus des langues sont comme ça

a.dropdown-item(href='/?lang=en-us')=English

Et dans les templates pug, pour utiliser les lnagues on fait comme ça :

 h2=`${__('Welcome to Pulpito')}`

i18n-node injecte dans l'objet response la propriété locale

h3=`locale is ${locale}`

et dans viewRoutes.js

router.get('/', viewController.getHome);

Clean Code / Nettoyer le code en profondeur

  • lancer le run+test tous les jours https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#schedule
  • rajouter des commentaires dans validatorService
  • passer itineraries à une classe - voir #35
  • migrer à userModel les mongoose queries de userController, ou créer un userService pour gérer ça et l'abstraire de userController qui n'a pas à connaitre les détails d'implémentations.
  • dans apiHelper y a deux manières différentes de transformer les API Params: une depuis la View et une depuis API... il faudrait unifier les params et que ce soient tous les mêmes (quitte à compliquer ceux de l'API)
  • les routes API respectent les best practices? ce sont de vraies ressources? séparer weekend et destinations?
  • revoir notions de SOLID dans emails de Pierre Criulanscy
  • pure fonctions

Améliorer les tests (en profondeur)

  • utiliser moins de FIXTURES et plus de fichiers json (peut-être utiliser MOXIOS pou mocker les request ? comme dans https://codewithhugo.com/testing-an-express-app-with-supertest-moxios-and-jest/)
  • avoir une mocked DB pour créer les données de test sur cette DB? peut-être via testcontainer library ? (on peut faire un testcontainer par test file, ça permettrait d'éviter les bug des user create and update...)
  • utiliser des mock au lieu de créer des fake object express request et response?
  • remettre à plat les tests et la stratégie de tests. Il y a dans tous les controllers des tests qui ressemblent plus à des tests d'intégration que à des unit tests, dans flightService il y a des unit-tests qui manquent peut-être, ... et pas sûr qu'il faut "retester" dans flightService qui est "déjà" testé dans destinationsController (par ex tester avec un aéroport qui n'existe pas)
    • y a des tests répétitifs ? (par ex les tests d'Authcontroller sont plus ou moins répétés dans functional.test.js)...
    • les tests de controller (sauf destinationController) ne mockent pas les fonctions sous-jacentes donc ce sont plutôt des integrations tests que des unit tests. DestinationController est partiellement ok car pour certaines méthodes on mocke getFlights donc on unit-test vraiment les différentes méthodes du controller... même si, a priori, s'il y a des mocks, c'est un integration test...
    • y a trop de tests de paramètres qui manquent, ou autre, dans destinationsController... ça ressemble plus à des tests d'intégration? en plus, ces cas-là ne sont pas gérés dans les tests de getFlights, ou en tout cas pas parfaitement.
    • parfois les tests se téléscopent: si un test faile, le fake user n'est pas correctement supprimé ensuite et ça peut entraîner un nouveau fail à l'execution suivante (duplicate key) .... solution: toujours rajouter et supprimer le même dummy user?
  • Les tests dépendent de l'implémentation, même les tests d'intégration, exemple dans validatorService.integration.test.ts on teste si le message d'erreur correspnd à une certaine string. Si on change le message d'erreur, le test cassera. il doit y avoir une meilleure manière de tester ....
  • les tests dans endtoend ne testent pas que la réponse est bien formée... quand j'ai changé route.oneway en onewayRoute, j'avais aucun moyen de vérifier au compile ou via les tests que ça continuait, ou pas, de fonctionner. bon je peux aussi définir le type de réponse de la route API en fonction des templates pugs? par ex si PUG utilise itinerary.onewayRoute.connections alors ça doit être dans le type de réponse attendu de la route API :Response<{itinerary: {onewayRoute .... > quelque chose comme ça

EPIC En tant que user de l'interface, je veux pouvoir créer et gérer un profil utilisateur

Créer et gérer un profil utilisateur depuis l'interface (en d'autres termes, répliquer ce que l'API permet déjà de faire)

  • en tant que user de Pulpito, je veux créer un compte avec email et password
  • en tant que user de Pulpito, je veux me connecter à mon compte
  • en tant que user de Pulpito, je veux recevoir un lien pour créer un nouveau password si j'ai perdu mon password
  • en tant que user connecté, je veux pouvoir modifier mes propres infos (email, nom...) et éviter que d'autres puissent le faire
  • en tant que user connecté, je veux pouvoir lire, ajouter et modifier la configuration de mon profil (destinations ou origines favorites, langue des résultats, nombre max de résultats, ....)

En tant que user je veux recevoir périodiquement le résultat d'une recherche par email

Skyscanner le fait avec le bouton 🖤 mais je pense que c'est pour des dates précises. Pas sûr que Kiwi le fasse.

Je pourrai faire ça avant d'voir la gestion des users, et dans chaque email envoyé un lien vers une route API pour stopper l'envoi.
Et moi en BDD, je peux garder un email associé à la recherche à effectuer

Niveau front, ce serait juste un formulaire avec un email pour envoyer les infos (et c'est tout, donc pas forcément besoin de la gestion des users dans le front, ou pas besoin d'être connecté...)

Pas besoin d'analyser si y a baisse ou hausse, on renvoit juste par email le résultat de la recherche, par ex cheapest weekend à Berlin ces 12 prochains mois.

Améliorer cleanItineraryData

cleanItineraryData est utilisé pour préparer les données pour le front mais est utilisé pour toutes les données, à chaque fois, au lieu des données qu'on va effectivement envoyer au front (par défault, 20 destinations/vols).
Pour améliorer la performance, on pourrait revoir cela.

Modéliser notre propre système de données (au lieu d'utiliser la structure de données de Kiwi)

Utiliser TDD

Ne pas être dépendant de l'API et modéliser notre propre système de données/objets pour les infos sur les flights (et peut-être mettre des vrais objets et pas des Object literals)

dans apiHelper.cleanItineraryData, retourner un nouvel objet au lieu de supprimer des champs de l'objet existant... comme ça on peut choisir les champs que l'on veut renvoyer, et non ce que l'on ne veut PAS renvoyer. Et pourrait ainsi avoir une méthode qui filtre les champs.

Permet aussi d'avoir un truc plus clean pour applyFilters, pour totalResults, .... au lieu d'avoir des mñethodes qui mutatent l'objet ...

En tant que user de l'interface, je veux pouvoir utiliser des aires métropolitaines (Londres, Paris, ...)

L'API de Kiwi permet d'utiliser LON pour tous les aéroports de Londres, PAR pour ceux de Paris...
Ce sont des aires métropolitaines (https://en.wikivoyage.org/wiki/Metropolitan_area_airport_codes).
Mais comme sur le front on utilise une liste d'aéroports qui proviennent d'un data source JSON, ces aires métro n'apparaissent pas.

Idée:

Vérifier UX et UI

Juste vérifier que l'UX et l'UI sont clairs, et que un user saura quoi faire lorsqu'il atterrit sur Pulpito, et à quoi ça sert.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.