Impostazione degli ambienti dei nodi per un'API REST - I miei capelli stanno diventando grigi

Question

Sono molto umile che vengo qui alla comunità. Non conosco ancora Jack sugli ambienti dei nodi, e sono l'unico sviluppatore di Nodi qui. Un team one man in questo momento per costruire la mia prima API Node REST. (sì, davvero quello di cui abbiamo bisogno sono più persone che conoscono già un po 'più di Node di me per aiutare questo processo di apprendimento lungo).

Ho cercato senza sosta per ore sul web per cercare di fare il mio grazie diligence..but francamente sto solo non trovare tanto là fuori su come impostare Node.js ambienticosì come istituiscono build locali e altri ambienti. Per prima cosa, ho iniziato con la creazione di una build locale: piccoli passi sono tutto ciò che sto cercando ... in uno scenario reale. La maggior parte dei post del blog mostra lo più semplicesviluppoambiente solo nella migliore delle ipotesi. E quindi, per rendere le cose ancora peggiori, la maggior parte dei post sul blog parla della configurazione del sito web (browsify sh__ e cose del genere). Sto facendo un'API REST, non un sito qui.

Ho bisogno di alcune risorse per iniziare con cui o non sto cercando giusto per loro per il nodo o sono così difficili da trovare. Voglio davvero fare una panoramica su come impostare le variabili di ambiente, su come utilizzare gulp con tali variabili per eseguire diverse situazioni ambientali e su come le persone gestiscono il loro livello persistente come stringhe di connessione al database, ecc ... che Presumo che sia anche automatizzato in parte dalle attività di Gulp che leggono i file di configurazione che contengono le stringhe di connessione? Non sono davvero sicuro, non ci sono molti buoni esempi là fuori.

Ecco perché sono qui per cercare di trovare questo percorso, pubblicandolo qui. (e, si spera, commenti sul mio attuale gulpfile ... è fdd o addirittura vicino alla traccia giusta o dove diavolo dovrei iniziare per le convenzioni e le attività di costruzione e ambiente?)

Cosa sarebbe è bello trovare un buon post che ti guidi attraverso un giorno nella vita di uno sviluppatore di nodi.

Dove sono attualmente?

mio API: Beh, ho costruire fuori un paio di punti finali Koa.js, ho alcuni controller che prendono nella richiesta, elaborarla utilizzando un modulo nodo gateway ho sensi di colpa che hanno qualche Metodi di persistenza CRUD in quello che io chiamo un livello gateway che chiama il set sottostante di classi Model che significano le chiamate CRUD reali a un DB reale e alcuni mock per i miei test, ecc. Molto basilari a questo punto ... tutti i test guidati tramite Mocha. js (stile BDD).

My Day: Così adesso, vengo al lavoro, ho già installato il mio ambiente di test mocha.js e sono in grado di almeno lo sviluppo test drive del mio codice e hanno test eseguiti bene su salva. Posso guardare i miei file e i miei test eseguiti con i rapporti di moka nel terminale. La mia app funziona, tutto qui.

Il mio problema: Ma in realtà non l'ho automatizzato molto oltre a quello via Gulp. Voglio sapere di più sulla configurazione delle variabili d'ambiente, cosa farebbe uno sviluppatore quando è pronto a costruire e spingere a git, yada yada e infine come passare da un ambiente all'altro, i movimenti di farlo quando si spinge ad altri server, e tutto che via qualunque configurazione o attività di gulp faciliterebbero questo. Ho solo bisogno di un buon esempio di questo tipo di ecosistema. Qualsiasi tipo di esempio, ma qualcosa di realistico sarebbe così dannatamente utile.

Quindi ...Ecco uno squillo del mio attuale gulpfile. Ora ci sono cose da costruire lì per il transpiler babel (sì, sto usando ES6 al codice ES5 nel mio js), ma l'ho preso da qualche altro codice, ma in realtà non ho ancora capito come funzionerà tutto questo. In realtà, le cose che ho configurato sono il mio test run e l'automazione a questo punto. Le cose da costruire mi sono disabilitato perché a) non so davvero quali file dovrebbero essere parte della build per un'API REST al di fuori di app.js, server.js eb) il codice di build che ho preso da un codice che ho trovato transpiles js file tramite babel in una cartella di build ma poi ho problemi con collisione di codice/conflitti con il mio codice normale. Ad esempio la compilazione di roba qui sotto stava spingendo server.js in una cartella di build e quando ho provato a eseguire il normale server.js nella root, era in collisione con il codice in build/server.js quindi questo è tutto fatto e ovviamente non so cosa diavolo dovrei fare ancora con le build.

'use strict'; 

require('babel/register'); 
require("harmonize")(); 

var gulp = require('gulp'), 
    mocha = require('gulp-mocha'), 
    gutil = require('gulp-util'), 
    babel = require("gulp-babel"), 
    server = require('gulp-develop-server'), 
    del = require('del'); 


var config = { 
    core: { 
     src: '*.js', 
     build: { 
      src: 'build' 
     } 
    }, 
    server: { 
     path: ['app.js'] 
    }, 
    bs: { 
     proxy: 'http://localhost:3000' 
    }, 
    test:{ 
     root: 'test/**', 
     src: { 
      bdd: { 
       features:'test/bdd/features/**/*-spec.js', 
       unit:'test/bdd/unit/**/*-test.js', 
       integration: 'test/bdd/integration/**/*-integration.js' 
      } 
     }, 
     mocha: { 
      reporter: 'spec' 
     } 
    } 
}; 

gulp.task('default', ['babel','development'], function(){ 
    gulp.task("watch", function(){ 
     gulp.watch('**/*.js', ['babel']) 
    }); 
}); 

gulp.task('development',['mocha-bdd-features', 'mocha-bdd-unit'], function() { 
    gulp.watch('**/*.js', ['mocha-bdd-features', 'mocha-bdd-unit']); 
}); 

gulp.task('babel', function() { 
    return gulp.src('./*.js') 
     .pipe(babel()); 
     //.pipe(gulp.dest('build')); 
}); 

gulp.task('build', ['clean'], function() { 
}); 

gulp.task('clean', del.bind(
    null, ['build/*'], {dot: true} 
)); 

gulp.task('server:start', function() { 
    server.listen({ path: config.server.path}); 
}); 

gulp.task('server:restart', function() { 
    server.restart(); 
}); 

gulp.task('mocha-bdd-features', function() { 
    process.env.PORT = 8001; 
    return gulp.src([config.test.src.bdd.features], { read: false }) 
     .pipe(mocha({ 
      compilers: { 
       js: babel 
      }, 
      reporter: config.test.mocha.reporter, 
      ui: 'bdd' 
     })) 
     .on('error', gutil.log); 
}); 

gulp.task('mocha-bdd-unit', function() { 
    process.env.PORT = 8002; 
    return gulp.src([config.test.src.bdd.unit], { read: false }) 
     .pipe(mocha({ 
      compilers: { 
       js: babel 
      }, 
      reporter: config.test.mocha.reporter, 
      ui: 'bdd' 
     })) 
     .on('error', gutil.log); 
}); 

gulp.task('mocha-bdd-integration', function() { 
    process.env.PORT = 8003; 
    return gulp.src([config.test.src.bdd.integration], { read: false }) 
     .pipe(mocha({ 
      compilers: { 
       js: babel 
      }, 
      reporter: config.test.mocha.reporter, 
      ui: 'bdd' 
     })) 
     .on('error', gutil.log); 
}); 

gulp.on('err', function(e) { 
    console.log(e.err.stack); 
}); 

miei package.json script così lontane:

"scripts": { 
    "start": "gulp", 
    "build": "gulp build", // I was running this for a while 
    "release": "gulp build --release", //I haven't used this yet or know if I even will yet 
// I definitely use these, I set these up myself 
    "test-bdd-features": "gulp mocha-bdd-features", 
    "test-bdd-unit": "gulp mocha-bdd-unit", 
    "test-bdd-integration": "gulp mocha-bdd-integration" 
    }, 

Fondamentalmente come sviluppatore il modo in cui ho la mia gulpfile in questo momento è di tipo I 'gulp' al prompt bash (terminale da all'interno di Webstorm nel mio caso) che esegue l'attività di gulp predefinita, e quindi prima alcune altre attività a questo punto in cui alcune cose accadono finora:

1. Si corre tutti i miei test moka sulla prima esecuzione di gulp
2. orologi tutti js file per la moka in modo che i test eseguiti su moka salvataggio di qualsiasi codice js cambia

Davvero questo è tutto quello che sta succedendo. Posso eseguire il server dei nodi ok e tutto il resto. Ma è molto semplice a questo punto. Ho la stupida porta app.listen() codificata nel mio stupido file app.js che ovviamente è ... ben codificato! E onestamente ho diverse porte per le mie diverse suite di test perché ho scoperto che dovevo a causa di conflitti tra porte, ma forse è solo a causa di qualcosa di strano che ho fatto, non sono sicuro se questa è la norma per avere porte di confronto per far funzionare il tuo test di accettazione vs unità, ma presumo di sì.

Ahhh !! Advil per favore!

Quindi a questo punto io sono come tirare fuori i miei capelli su come superare questo:

1. come impostare una vera e propria costruzione di un'API REST (ok transpile codice js tramite babel a dove, e che cosa eh?)
2. l'ecosistema per l'impostazione di attività, configurazioni, ecc. per l'automazione di build e l'esecuzione di codice in ambienti diff ... come è!
3. L'estrazione del codice in diversi ambienti e l'esecuzione di quelli e ciò che non su diversi scenari server (dev, QA, stage, prod).

E perché so che qualcuno risponderà con sicurezza. Sì, ho capito "ci sono un milione di modi per farlo". Stai predicando al coro. Ricevo quello ma non è questo il punto qui. Sto chiedendo molte informazioni qui, quindi sentitevi liberi di scegliere e con cosa rispondere, sperando di aiutarmi a ottenere la giusta direzione su build o ambientazioni. Sto solo chiedendo degli esempi di modi periodici, o analisi del mio file gulp, o solo un punto di partenza! ...quindi posso capire in generale il processo che le persone attraversano e che cosa sono i tipi tipici di attività che eseguono ciò che ingerito, ecc. e come vengono gestite le variabili d'ambiente e quali non tipicamente nelle app Node.

Answer 1

Nella mia esperienza limitata, penso che la cosa più vantaggiosa che ho imparato finora con questa build e le cose di configurazione ("sysadmin è il motivo per cui bevo") è mantenerlo il più semplice e componibile possibile.

Config informazioni

Tanto per cominciare, se questo aiuta a tutti, io sono un grande fan di mantenere le informazioni di configurazione è un .json e riferimento che tutto il progetto. Per esempio:

// config.json 
{ 
    "STAGING": "http://staging.yourdomain.com/api/", 
    "PRODUCTION": "http://yourdomain.com/api/", 
    "THE_BEST_PORT_EVER": 1337, 
    "MY_DOGS_NAME": "Ginger" 
} 

Ciò è che tutta la "magia stringa" evitamento cosa, in modo da avere solo un posto per fare riferimento a tutte le informazioni pertinenti ambiente.

Nella tua gulpfile, quando è necessario fare riferimento alcuni URL, o qualche porta, o solo qualsiasi altra cosa, basta lo richiedono:

var config = require('config.json'); 

roba test

C'è un 1.000 modi per farlo. .. Non ho familiarità con la configurazione corrente che hai, ma se funziona funziona. Tuttavia, cercherò di mantenere le cose il più modulari possibile (come in, anche se le funzioni sembrano schifo, almeno sono tutte indipendenti l'una dall'altra ... leggi: composizione delle funzioni.)

Edificio per diversi ambienti

Io odio a lungo, offuscato gulpfile s. Attualmente, il mio team sta lavorando su varie applicazioni Web e mobili distinte e varie iterazioni di siti statici, tutto per un solo prodotto. Tutto ciò deve essere monitorato nel controllo della versione per vari ambienti, e costruito e distribuito in vari ambienti. Tuttavia, i nostri processi di compilazione sono relativamente semplici, spero (anche se potrebbero essere sicuramente migliorati).

mi piace gulpfile s che assomigliano a questo:

// all your require'd stuff 

// this is helpful, 'cause you can do stuff like "gulp --production" 
var argv = require('yargs').argv; 

var paths = { 
    sass: ['some/path/to/sass'], 
    // various other paths 
}; 

gulp.task('sass', compileSass); 
gulp.task('html', html); 
gulp.task('default', watch); 
// etc. 

// then, in pretty alphabetical order 
function compileSass() { 
    return gulp.src(paths.sass) 
     .pipe(doSomeCoolStuff()); 
} 

function html() { 
    // etc. 
} 

function watch() { 
    compileSass(); 
    html(); 

    if(argv.production) { 
    someSpecificProductionFunction(); 
    } 

    gulp.watch(paths.someAwesomePaths, ['someTask']); 
} 

mi piacciono gulpfile s che assomigliano a quello, perché sono compositiva.

Per quanto riguarda la costruzione va, non mi preoccupo nemmeno di definire gli script package.json. Potresti? Sicuro. Immagino che dipenda dal progetto e dalle questioni di stile personale/di squadra, ma per i progetti che stiamo facendo, al momento non c'è alcun vantaggio nell'aggiungere un ulteriore livello di astrazione. Perché eseguire qualcosa come npm doSomething, che è solo un alias per ./some-script, che è solo un alias per, diciamo, gulp --production?

Ecco un estratto da un file README che abbiamo per un app:

Caso 1

Voglio correre l'applicazione nel mio browser colpire il mio server locale

Assicurati che il tuo config-local.json corrisponde a config-example.json, ma con il server locale (qualcosa come http://your.ip.here:1337/api/). Rendi sicuro di avere la versione più recente del server installato e in esecuzione. La corsa ionic serve.

Caso 2

voglio eseguire l'applicazione nel mio browser colpire un server diverso.

Cambiare l'indirizzo del server nel vostro config-local.json e seguire Caso 1.

Caso 3

voglio eseguire l'applicazione su un dispositivo in un ambiente completo staging.

Corsa gulp --staging. Quindi eseguire ionic run --device.

Caso 4

voglio eseguire l'applicazione su un dispositivo in un completo di produzione ambiente.

Corsa gulp --production. Quindi eseguire ionic run --device.

Un sacco di tempo è trascorso lavorando su "come faccio a rendere più facile per l'utente?" Ma per quanto riguarda la domanda, "come posso renderlo più semplice per lo sviluppatore?"

Il minor numero di passaggi coinvolti in un processo di build significa che sono meno punti di errore durante il tentativo di creare.

Ciò significa anche che il codice deve essere il più possibile . 10 soluzioni potrebbero avere lo stesso risultato, ma 9 di quelle soluzioni potrebbero essere schifose.