creazione di app nodejs in framework php / mysql con successiva migrazione completa passo dopo passo a nodejs in mente

2

Sto cercando il percorso più efficiente per convertire nel tempo il mio framework php per nodejs e credo che gli esperti di nodejs e gli sviluppatori specifici che hanno lavorato negli anni con apache / php / mysql saranno in grado di dare risposte obiettive basato su conoscenza ed esperienza che non saranno solo opinioni, ma soluzioni a un problema.

CONTESTO

Sto lavorando a un progetto che richiede funzionalità in tempo reale per cui node / socket.io sembra essere la soluzione più efficiente.

VINCITORI

  • Ho costruito il mio framework php / mysql OOP per gestire i progetti nel corso degli anni con alcune funzionalità molto carine per i gestori di contenuti web e funzionalità interessanti per me per semplificare radicalmente lo sviluppo specifico (basato sulla mia logica personale obv.) e gestire tutti i miei progetti in una sola istanza del mio framework.
  • Non è possibile riscrivere tutto questo per nodo proprio ora.
  • Devo continuare a sfruttare i vantaggi del mio framework & strumenti di back-office per lavorare velocemente durante lo sviluppo delle mie prime app di nodo.
  • Dopo che questo nuovo progetto è in produzione, inizierò a riscrivere per nodejs le funzionalità lato server & dalla parte del cliente; uno alla volta (mantenendo il mio ambiente di sviluppo locale e tutto il mio progetto in prod sempre in sincrono).

DOMANDA

Come faccio ad iniziare a introdurre nodejs nel mio framework ? in modo che

  • Non passerò troppo tempo su di esso ora (eccetto per le app dei nodi che ho bisogno ovviamente)

  • Non avrò troppi mal di testa quando comincio a sostituire php e il vecchio js per sfruttare il nodo

  • php / mysql & js / mongodb dovrebbe coabitare bene sui server fino a quando non ci sarà più php nel framework

la mia logica di framework - astratta senza tutti i dettagli:

Quello che segue è il punto in cui mi trovo, la possibile soluzione che ho identificato & sto considerando, non altre domande + ci possono essere altri modi di cui non sono ancora a conoscenza, quindi il post.

Dovrei essere meglio:

  • Per le mie prime app di nodo: usare un proxy come Nginx per avere node & apache, mysql & mongodb fianco a fianco? o vale la pena investire il tempo ora per far funzionare il mio motore php con il nodo, usando i moduli per php, sql? un altro percorso?

  • scrivere le app del nodo con mongodb come server db & quando necessario scambia i valori da sql all'app usando php? o vale la pena investire in questo momento il tempo di passare da mysql a mongodb alla struttura completa piuttosto che dopo uno strumento / funzionalità alla volta? un altro percorso?

  • conversione

    • Dall'alto verso il basso (vale a dire iniziando con la sostituzione del gestore di richieste http & js passa la palla a php per il resto e così via, sarei in grado di farlo?)
    • Dal basso verso l'alto (vale a dire i plugin, gli strumenti di backoffice, quindi i template, quindi il motore di rendering ...)?
posta mikakun 11.12.2017 - 17:10
fonte

2 risposte

2

Potresti prendere in considerazione l'aggiunta di un livello proxy durante la migrazione. Fornisce un URL per l'applicazione mentre parti specifiche si trovano su server separati. Questo è l'approccio generale usato da chi usa i microservizi. Esistono diverse istanze dei servizi dietro uno spazio URL. Qualcosa come Zuul o nginx funzionano bene lì. Ciò ti consente di nascondere il fatto che stai utilizzando server diversi con dettagli di implementazione molto diversi dai tuoi utenti.

Successivamente inizierei ad implementare le prime app del nodo nuovo . A volte alcune app più piccole funzionano meglio di una grande. Dipende davvero da alcuni fattori. La nuova architettura può vivere accanto alla vecchia architettura.

Fai quanto basta per muoverti nella giusta direzione, quindi valuta quello che hai. Più la tua app legacy migra verso il solo rendering di JSON, meno dipende dal fatto che tu abbia lo stile giusto.

    
risposta data 11.12.2017 - 18:00
fonte
2

Mentre la maggior parte delle persone che fanno domande di architettura lo fanno prematuramente (dovrebbero davvero scrivere un codice prima di acquisire una comprensione fondamentale), ti suggerisco di prendere prima alcune decisioni architettoniche di base Queste decisioni sono indipendenti dalla tecnologia; se li segui, avrà meno importanza rispetto alle tecnologie effettive che scegli.

L'architettura è fondamentalmente un modo per organizzare la tua applicazione. Fornisce uno scheletro con il quale è possibile organizzare i pensieri, suddividere i pezzi di grandi dimensioni in quelli più piccoli e fornire una migliore manutenibilità scrivendo la propria applicazione come una raccolta di moduli liberamente accoppiati. Quando lo fai, scoprirai che puoi concentrarti sulla scrittura di ogni modulo in modo indipendente, senza preoccuparti di ciò che fanno gli altri o di quali tecnologie utilizzeranno.

Ci sono molte architetture tra cui scegliere, ma sostanzialmente funzionano allo stesso modo: assegnano a ciascun modulo un ruolo e quindi stabiliscono interfacce tra i tuoi moduli. Quindi, per creare la tua architettura, tutto ciò la necessità di fare è capire che cosa farà ogni modulo e quindi dare loro dei modi per comunicare tra loro.

Ogni architettura applicativa che fornisce risorse condivise (come un database) ai suoi utenti coinvolge un client e un server in qualche modo. Poiché è necessario generare pagine Web per creare un'applicazione Web, questa può assumere due forme: rendering lato client e rendering lato server. Poiché la tua attuale applicazione utilizza PHP, presumo che tu stia utilizzando principalmente rendering lato server. L'architettura è simile a questa:

Database <-- SQL --> PHP Web Server <-- HTML --> Web Browser

In uno scenario di rendering lato client, la tua architettura sarebbe più simile a questa:

Database <-- SQL --> Service Layer <-- JSON --> Browser App <-- HTML --> Web Browser

Il tuo livello di servizio potrebbe essere suddiviso in questo modo:

<-- SQL --> DAL <-- CRUD --> BLL <-- Business Methods --> Gateway <-- JSON --> 

Dove DAL è il tuo Data Access Layer (cioè un Data Mapper) che fornisce funzionalità CRUD (Crea, leggi, aggiorna e cancella) e BLL è il tuo livello di logica aziendale che contiene metodi che comprendono le operazioni aziendali.

Quindi, dove si inserisce Node? In uno scenario di rendering lato client, il nodo vivrebbe nel livello di business logic. In uno scenario di rendering lato server come quello che hai, le cose diventano un po 'più complicate; dovrai capire come ottenere il nodo per produrre le tue pagine web per te.

In ogni caso, il punto di tutto questo è di dare spazio alle vostre caselle di applicazione. Ogni scatola può essere progettata, scritta e testata individualmente, separata dalle altre caselle. Le tue decisioni sulla tecnologia possono anche essere fatte per ogni scatola individualmente. Quando hai finito, puoi connettere tutte le scatole insieme, eseguire alcuni test di integrazione e avere un'applicazione completamente manutenibile, liberamente accoppiata, manutenibile.

Ulteriori letture
Gateway
Service Layer
Data Mapper
Dominio logico e SQL
Rendering lato server con nodo

    
risposta data 11.12.2017 - 18:24
fonte

Leggi altre domande sui tag