5139 sujets

Le Bar du forum

Développement d'un framework en Node.js

Pages :
Salut à tous,

En ce moment je m'intéresse à Node.js et je serais ravis de partager sur le sujet avec d'autres alsanautes de temps à autre.

Alors je sais : les hébergements ne sont pas pléthore (ou en tout cas plus ou moins abordables), il n'y a pas non plus de framework vraiment complet (il parait que ce n'est pas dans la philosophie d'un bon "javascipteur" ; hé oui : les modules...), donc pour une utilisation en prod' rapide ce n'est pas vraiment le but... c'est surtout pour s'approprier une nouvelle techno.

Des amateurs ?

Édit : topic rebaptisé.
Modifié par Olivier C (18 Sep 2017 - 09:24)
Hello,

Tu n'es pas seul ! Je m'intéresse aussi a cette technologie, car je pense que comme beaucoup d'intégrateurs web aujourd'hui, j'ai intégré node package module dans mon workflow.

Je ne l'utilise qu'en surface, mais j'ai suivi une excellente formation sur node / npm et react et même si aujourd'hui, je travaille principalement dans des environnements PHP/ MySQL, j'aimerais m'orienter par la suite vers des environnements full js.

Perso je rassemble des informations à ce sujet pour monter une petite application de gestion administrative (je suis indépendant) avec node et react.

A + Smiley cligne
MeMeN a écrit :
Je ne l'utilise qu'en surface, mais j'ai suivi une excellente formation sur node / npm et react et même si aujourd'hui, je travaille principalement dans des environnements PHP/ MySQL, j'aimerais m'orienter par la suite vers des environnements full js.

Bien ! De mon côté j'avais un peu poussé le bouchon en front - génération d'un thème WordPress avec Pug (ex Jade), création de polices de caractères partir d'un dossier composé de SVG, etc - mais pour ce faire j'utilisais essentiellement des modules empaquetés pour Gulp (et auparavant Grunt) à l'exception de lodash et vinyl-ftp. Quitte a passer côté back j'aimerais taper directement dans npm sans passer par une surcouche inutile.

MeMeN a écrit :
Perso je rassemble des informations à ce sujet pour monter une petite application de gestion administrative (je suis indépendant) avec node et react.

Je cherche de mon côté à me faire un mini framework perso sous Node.js. Mais commencer par react, là tout de suite, je pense que je vais attendre un peu et me cantonner à expressjs pour l'instant, peut-être un peu plus tard un peu de Vue.js (dont la version 2 a été annoncée). Tu utiliserais quoi comme module pour gérer une base de donnée MySQL ? Ce module : mysql ? Mais la question en soit est déjà peut-être une hérésie : qu'utiliserais-tu comme DDB ? Et même : pour de petits projet te contenterais-tu d'une alternative (fichier JSON, etc) ?
Modifié par Olivier C (17 Jan 2017 - 03:22)
Salut à tous,

Olivier C a écrit :
Mais la question en soit est déjà peut-être une hérésie : qu'utiliserais-tu comme DDB ? Et même : pour de petits projet te contenterait-tu d'une alternative (fichier JSON, etc) ?

De mon point de vue, la technologie utilisée (Node.js, PHP, Java et j'en passe...) ne t'oblige pas à utiliser une base de données plutôt qu'une autre. C'est un choix complètement à part. Je crois que la plupart des "anciens" développeurs backend on pris l'habitude de bosser sur des base de données SQL, alors que le NoSQL peut très bien servir sur petits comme des gros projets.

D'un point de vue général, je pense que Node.js c'est bien plus qu'un autre moyen de créer le backend d'une application quelconque. Le nombre d'utilitaires qui tournent avec cette plateforme est impressionnant et ça ne fait que d'augmenter. Rien que pour cela, il faut franchir le cap et se pencher dessus.
Oui... avant de penser a telle ou telle DDB il faudrait que je commence par en maîtriser une : j'avais lu un bouquin assez poussé sur MySQL mais je n'ai jamais réellement pratiqué, du coup je suis largué en ce qui concerne les relations entre les tables. Pour le NoSQL je ne connais pas assez. J'avais cru comprendre que le fait de ne pas avoir de relations entre les différentes tables flinguait les performances et que seul les très grandes quantités d'infos justifiaient de les utiliser, appuyées par de puissants serveurs pour en tirer partit.

Sinon, pour relancer automatiquement le serveur en cas de crash, vous utilisez nodemon ou supervisor (ou peut-être encore un autre truc) ?
Modifié par Olivier C (17 Jan 2017 - 04:02)
Olivier C a écrit :
Pour le NoSQL je ne connais pas assez. J'avais cru comprendre que le fait de ne pas avoir de relations entre les différentes tables flinguait les performances et que seul les très grandes quantités d'infos justifiaient de les utiliser, appuyées par de puissants serveurs pour en tirer partit.

Les performances pour faire quoi en fait? C'est surtout ça la question. Et la réponse te renvoie en principe au choix d'un système plutôt qu'un autre. La différence entre du SQL et NoSQL c'est pas seulement la structure des données. On peut avoir besoin (ou non) d'indexage, de procédures stockées, des transactions... et autres.
Olivier C a écrit :
Sinon, pour relancer automatiquement le serveur en cas de crash, vous utilisez nodemon ou supervisor (ou peut-être encore un autre truc) ?

J'utilise nodemon oui (au passage les deux font exactement le même job). Et c'est surtout utile pendant le développement car ça relance le serveur quand un fichier source change, pas seulement quand ça crash.
Anymah a écrit :
J'utilise nodemon oui (au passage les deux font exactement le même job). Et c'est surtout utile pendant le développement car ça relance le serveur quand un fichier source change, pas seulement quand ça crash.

J'utilise moi aussi nodemon pour la surveillance des fichiers... Et comme j'ai un peu la flemme j'ai mis une extension pour m'ouvrir un onglet navigateur après avoir lancé le serveur :
const host = '127.0.0.1'
const port = 9000
const opn = require('opn')
const express = require('express')
const app = express()

app.listen(port, host, logSuccess) // démarrage d'un serveur
opn('http://' + host + ':' + port) // ouverture d'un onglet dans le navigateur par défaut

Seulement voilà : à chaque modif' un nouvel onglet s'ouvre. Bien sûr il ne sert à rien d'encapsuler la fonction opn() dans une condition puisque la variable testée serait rechargée avec la relance du serveur. J'ai aussi pensé utiliser une sessionStorage(), mais je ne sais pas comment faire un .setItem() côté serveur (là c'est clair, je n'ai encore pas pris le pli)...
Modifié par Olivier C (17 Jan 2017 - 19:32)
Une solution très rapide : plutôt que d'ajouter l'ouverture de l'onglet dans le code de ton serveur crée un nouveau fichier à cet effet (opentab.js par exemple) et modifie ton package.json en ajoutant la ligne suivante : 

"scripts": {
    "start" : "nodemon server.js | node opentab.js"
}


En tapant "npm start" dans la console ça va te lancer le serveur et le script d'ouverture d'onglet par la suite. Nodemon relancera uniquement le serveur. En revanche, ça t'oblige juste à dupliquer tes deux constantes pour construire l'url (qui ne changeront théoriquement pas).
Anymah a écrit :

"scripts": {
    "start" : "nodemon server.js | node opentab.js"
}

Ah ben génial ! Car c'est EXACTEMENT l'idée que j'avais eu au départ...

... Sauf je n'arrivais pas à comprendre comment faire pour lier une instruction "node dev.js" à la commande start et je cherchais donc d'autres solutions. Donc c'est vraiment supper car grâce à toi je peux revenir à cette première intuition qui fait nettement moins bricolage.

Merci beaucoup !
Modérateur
Olivier C a écrit :
Pour le NoSQL je ne connais pas assez. J'avais cru comprendre que le fait de ne pas avoir de relations entre les différentes tables flinguait les performances et que seul les très grandes quantités d'infos justifiaient de les utiliser, appuyées par de puissants serveurs pour en tirer partit.

Pas tout à fait. Tout d'abord il y a plusieurs types très différents de bases de données NoSQL. Elles sont généralement pensées pour répondre à un problème particulier, et pour ce problème, elle sont donc bien plus performantes.
En effet on y a souvent recours pour des cas spécifiques de montée en charge, non pas au travers de puissant serveur (ce qui se fait majoritairement avec le SQL) mais par des clusters de petits serveur bon marché (la plupart des système NoSQL sont pensé pour faire cela). Mais la montée en charge peut comprendre autant la taille de la DB que le nombre de connexions…

Si certains modèles sont très intéressants sur des projets de petite taille (les bases clé/valeur notamment ou les bases document) le SQL reste une valeur sûre s'adaptant à presque toutes les situations, et bénificiant de décennies de savoirs et d'améliorations. Le SQL reste à mon avis une priorité à prendre en main avant les spécialités.
kustolovic a écrit :
Le SQL reste à mon avis une priorité à prendre en main avant les spécialités.

Oui, je me range derrière ton avis, dans une perspective didactique je pense qu'il me faut en passer par là.
Bonjour,

Après un petit break et quelques outils de front mis en place - comme Stylus et BrowserSync - je me rattaque au back :

1/ Vous utilisez quoi pour interagir avec MySQL ?
2/ Pour des raisons d'apprentissage je pensais éviter d'utiliser un ORM (tel que Sequelize, même s'il a l'air très bien), qu'en pensez-vous ?
a écrit :
1/ Vous utilisez quoi pour interagir avec MySQL ?


Le module du même nom. IL est simple et fonctionne.


a écrit :
2/ Pour des raisons d'apprentissage je pensais éviter d'utiliser un ORM (tel que Sequelize, même s'il a l'air très bien), qu'en pensez-vous ?


J'ai l'impression que les ORM c'est très bien pour les langages fortement typés comme Java. Mais pour les langages plus libéraux comme JavaScript ou PHP je trouve que ça relève plus de l'usine à gaz qu'autre chose quand ça va au-delà des simple méthodes simplificatrices genre findByXXX.

Je suis aussi entrain de faire mumuse avec Node.js dans mon coin ces temps-ci... je ferai signe si j'arrive à un truc intéressant.
QuentinC a écrit :
Je suis aussi entrain de faire mumuse avec Node.js dans mon coin ces temps-ci... je ferai signe si j'arrive à un truc intéressant.

Tant mieux ! Plus on est de fou...

Entretemps j'ai réussi à me connecter à une base de donnée MySQL avec le module npm mysql et j'arrive à afficher mes résultats dans une page. Pour l'instant c'est vraiment à l'arrache, c'est juste pour essayer :
const mysql = require('mysql')
    , connection = mysql.createConnection({
        host: config.host
        , user: config.user
        , password: config.password
        , database: config.database
        , socketPath: '/Applications/MAMP/tmp/mysql/mysql.sock' // ça c'est un truc optionnel si on utilise une BDD via MAMP, j'ai bien galéré pour trouver cette option indispensable sous mon environnement...
    })

app.get('/', (req, res) => { // route page d'accueil
  connection.query('SELECT * FROM _number_options WHERE id = \'1\'', (error, results, fields) => {
    if (error) throw error
    res.render('patternLayouts',
      {
        dev: config.dev
        , demo: true
        , siteUri: config.uri
        , title: 'Scriptura.js'
        , description: 'Interface for web apps'
        , name: results[0].name
        , content: 'Interface for web apps'
      }
    )
  })
})

EDIT : j'ai supprimé `connection.connect()` et `connection.end()` qui étaient en trop et faisaient bugger la page à la deuxième connexion à la BDD.

Voilà voilà, affaire à suivre...
Modifié par Olivier C (07 Feb 2017 - 18:21)
Je viens de découvrir une différence entre nodemon et supervisor : tous les deux suivent les modifications de fichiers mais seul supervisor relance le serveur en cas de crash. Bon à savoir...

Edit : en fait, après avoir parcouru quelques sites et forums, il semble qu'il faut éviter une relance après une erreur mal gérée (sinon risque de reboot à l'infini). Donc, contrairement à ce que j'imaginais il vaux mieux tabler sur nodemon, bien mieux suivit que son concurrent d'ailleurs.
Modifié par Olivier C (08 Feb 2017 - 19:57)
En fait d'après ce que j'ai pu observer, ça dépend du type de crash.

Si c'est une erreur de syntaxe, il faut relancer manuellement avec rs.
Sinon, si c'est une autre erreur, souvent il repart à la prochaine modif. Mais en cas de doute on tape rs et c'est réglé.

J'ai avancé un peu. Pour l'instant j'ai choisi nunjucks comme moteur de template.
L'intérêt de celui-ci est que les habitués de twig, smarty et autres classiques provenant de PHP ne sont pas trop dépaysés.
J'aime pas trop pug qui est proposé dans le tutorial de base en tout cas.

ET pour la connexion/déconnexion des utilisateurs, je recommande vivement passport. Son gros avantage est qu'il offre plus de 300 moyens d'identification différents (appelés stratégies), en passant par un formulaire classique, un kerberos ou LDAP d'entreprise, jusqu'à facebook ou une tonne d'autres réseaux et plate-formes.

On devrait peut-être songer à mettre du code sur github pour partager nos trouvailles.
Moi j'utilise Pug (ex Jade) depuis un bon moment déjà, c'était donc au contraire un facteur attirant en ce qui me concerne (et puis rien à voir avec le bidouillage que j'avais inventé pour l'utiliser avec php et WordPress). J'utilise aussi Stylus pour appuyer cette logique jusqu'au bout (que j'utilise désormais directement sous npm et non plus avec Gulp).

Merci pour le retour sur passport, je suis allé voir des forums et effectivement tout le monde le conseille, sa légitimité communautaire est écrasante face à d'autres concurrents tels que everyauth ou grant. Il figure d'ailleurs parmi les packages les plus téléchargés sur npm.

Sinon mon problème ça va être l'organisation de mon code : j'ai placé mes vues dans un fichier du même nom, mais où placer mes routes (qui sont pour l'instant dans app.js, mon point d'entrée) ? Dans un dossier `config` ? Voici la hiérarchie (MCV, même si j'ai du mal à à comprendre ce que je dois mettre dans modèle et contrôleur) que j'imagine pour l'instant :
./
    app.js
    models/
        post.js
        user.js
    views/
        partial/
            author.pug
            footer.pug
            head.pug
        patternLayouts.pug
    controllers/
    config/
        dev.js
        routes.js         <-- ici ?
        locales/
            fr.js
            en.js
    public/
        fonts/
        medias/
            images/
            videos/
        scripts/
        styles/
    resources/
    node_modules/
    package.json
    .gitignore
    readme.md

(Pour l'instant, en l'état actuel de mon développement, on voit tout de suite que je viens du front...)
Modifié par Olivier C (11 Feb 2017 - 06:37)
Olivier C a écrit :
Sinon mon problème ça va être l'organisation de mon code : j'ai placé mes vues dans un fichier du même nom, mais où placer mes routes (qui sont pour l'instant dans app.js, mon point d'entrée) ? Dans un dossier `config` ? Voici la hiérarchie (MCV, même si j'ai du mal à à comprendre ce que je dois mettre dans modèle et contrôleur) que j'imagine pour l'instant :
./
    app.js
    models/
        post.js
        user.js
    views/
        partial/
            author.pug
            footer.pug
            head.pug
        patternLayouts.pug
    controllers/
    config/
        dev.js
        routes.js         &lt;-- ici ?
        locales/
            fr.js
            en.js
    public/
        fonts/
        medias/
            images/
            videos/
        scripts/
        styles/
    resources/
    node_modules/
    package.json
    .gitignore
    readme.md

Placer le fichier dans un répertoire "config" semble cohérent et conforme à ce que l'on peut trouver par ailleurs sur d'autres solutions (ex : répertoire "conf" du serveur Tomcat stockant le fichier de routage web.xml).
Certains logiciels utilisent parfois un répertoire dénommé "settings" pour stocker leurs fichiers de paramétrage.
Il n'y a pas de règle ou de norme universelle, mais ces principes sont ceux généralement constatés.
@Sepecat : Merci pour ton intervention Sepecat.

QuentinC a écrit :
On devrait peut-être songer à mettre du code sur github pour partager nos trouvailles.

@QuentinC : C'est une très bonne idée, voici pour moi : ScripturaJS
Pages :
Sujet clos
Aller à