Sto lavorando per riscrivere un'applicazione esistente con Meteor che ha due casi d'uso abbastanza distinti (un account amministratore e un account utente). Entrambe potrebbero essere considerate app separate in termini di funzionalità, ma condividono lo stesso database di back-end.Multiple (separato/namespace) codebase del client Meteor per singola applicazione Meteor
C'è un modo per "spazio dei nomi" o altrimenti definire client separati in modo che Meteor solo pacchetti e manda le risorse per il client a cui si accede. Per esempio. il meteor-router potrebbe trasferire diversi client per lo spazio /admin* e lo spazio /user*, in questo modo non è necessario scaricare overhead non necessari per entrambi i client.
Mi aspetto che questo non rientri nel campo di applicazione di un pacchetto Meteor Smart come meteor-router.
Sembra correlato a questa domanda senza risposta http://stackoverflow.com/questions/17357394/where-to-put-a-separate-admin-interface-for-a-meteor-app?rq=1 –
I'm anche interessato a questo e trovato nessuna soluzione finora. Quella domanda incollata sopra ora ha una risposta basata su Iron-Router ma penso che non risolva il problema dei pacchetti di spedizione solo per applicazioni specifiche. Continuerà a cercare, sperando che l'approccio "più app di meteor con database condiviso" non sia l'unico modo per andare: -/ –
L'unica soluzione che ho trovato finora è una specie di hacker, ma aiuta a ridurre il sovraccarico di "tutto il packaging". Se c'è una parte della mia app che usa uno script o un modello che non ha bisogno di essere condivisa con il resto dell'app, lo includo in fase di esecuzione con [external-file-loader] (https: //atmosphere.meteor .com/pacchetto/external-file-loader) pacchetto. Getta queste risorse in una cartella statica come 'public' e questo gestisce le chiamate AJAX e il caricamento. Accoppiato con [session-extras] (https://atmosphere.meteor.com/package/session-extras) è possibile attivare le cose quando caricate. –