La mia azienda gestisce 2 siti Web, un sito Web pubblico per i clienti e un'intranet dei dipendenti. La rete intranet è utilizzata come back-end per i dipendenti per modificare e gestire varie parti del sito Web pubblico. Entrambi sono scritti in PHP. La rete intranet è vecchia di anni ed è stata progettata utilizzando un framework interno. Abbiamo recentemente creato un nuovo sito Web pubblico e, grazie all'opportunità di "ripartire da zero" con esso, lo abbiamo progettato utilizzando un framework PHP (Kohana). Sapevamo fin dall'inizio che ci sarebbero stati problemi di implementazione nel far interagire la intranet con il sito pubblico e viceversa. Ora siamo a quel punto.
Ci sono diversi modi in cui siamo stati in grado di far funzionare le cose: per la manipolazione diretta dei dati, entrambi usano mysql, quindi il generatore di query in Kohana può manipolare gli stessi dati delle query mysqli diritte della intranet. Ma oltre a questo, quando il sito pubblico deve utilizzare determinati metodi di auditing scritti sul framework intranet, o quando la intranet deve inviare una email automatica scritta in Kohana, o utilizzare un numero qualsiasi di altri metodi e funzioni, abbiamo
1- Incluso un framework nell'altro, per avere accesso ad entrambi. I problemi con questo sono:
a. Entrambi si basano sul buffering degli oggetti per preparare l'output e sono costantemente in grado di avviare e terminare i buffer in momenti dispari.
b. I nomi delle classi in conflitto vengono caricati automaticamente
c. caricatori automatici che si sovrascrivono l'un l'altro
d. gli errori progettati per essere gestiti in un modo vengono gestiti in modo improprio dal gestore degli errori dell'altra struttura.
e. qualsiasi numero di altri problemi di incompatibilità
Ci siamo circondati di questi caso per caso, ma è stato un incubo
2- Utilizzo di un'API remota. Abbiamo scritto i metodi di webservice su ciascun server e l'altro framework fa una richiesta CURL dell'altro server. I problemi con questo sono:
a. Il lavoro aggiunto di proteggere l'API e autenticare le richieste
b. la necessità di scrivere metodi di servizio
c. Il sovraccarico di dover effettuare richieste HTTP invece di caricare file localmente
3- Utilizzo di una API locale. Simile a quanto sopra, eccetto che il framework è incluso nello stesso server, e i metodi api sono scritti in script di shell che emettono dati da leggere dallo script chiamante tramite shell_exec .
Questo allevia la necessità di autenticazione, ma sembra un modo brutto e hacky di fare le cose
Non vogliamo riscrivere la intranet usando un framework adeguato. Ci vorrebbe una quantità incredibile di tempo che non abbiamo. C'è un modo migliore per farlo, o almeno un modo più "standard" o "convenzionale" per affrontare questo problema? O siamo bloccati a hackerarlo come lo siamo stati al momento?