Concettualmente, sarebbe ideale avere un'API centralizzata per ogni "sistema" (ma non lo stesso per tutti i sistemi).
Uso il termine sistema e cito, perché potresti avere molte app in un singolo sistema, così come un'app che funziona con più di un sistema. Un bell'esempio sarebbe una WebApp e un'applicazione mobile, essendo due "applicazioni" diverse che funzionano sugli stessi dati. Dall'altro lato potresti avere una dashboard che controlla il CRM della tua azienda e mostra le statistiche per il tuo sito web, che è fondamentalmente un'applicazione che interagisce con due diversi "sistemi".
Avere, ad esempio, i dati di siti web e vendite sullo stesso database potrebbe causare grossi problemi se si desidera modificare il sito Web, in quanto potrebbe causare problemi con i dati di vendita e sarebbe disapprovato da qualsiasi amministratore di sistema, nonché come la maggior parte se non tutti gli sviluppatori esperti. Avere due database sulla stessa applicazione porta con sé un'intera nuova serie di problemi. E questo è senza considerare possibili problemi di autorizzazione e / o il rischio di un exploit o hack che colpisce "dati più sensibili" di quanto dovrebbe.
Suggerirei quindi di creare un'API separata per ciascun sistema in modo che modelli, relazioni e comportamenti siano ben separati, ben documentati e funzionino a tuo vantaggio. Questo significa che ogni volta che c'è una domanda o un cambiamento nella logica aziendale, devi guardarlo in un unico posto.
Oltre a ciò, per ogni "app" avrei una base di codice separata, ma questa è più un'opinione personale.
L'idea ora è che devi estrarre i dati dall'API e, dopo aver consumato l'API, devi solo eseguire la formattazione per motivi di presentazione. es .: se hai un eCommerce e hai un cart total che è la somma di tutti i valori dei prodotti, questo valore proviene dall'API come FLOAT o DECIMAL , già assicurandoti di avere solo 2 cifre decimali, e consumare i formati delle parti (ad es. aggiungere valuta ecc.) il valore.
Serve a semplificare possibili versioni diverse delle app e garantisce coerenza (il cart total potrebbe non essere mai sbagliato in un'app ma non nell'altra, perché proviene dalla stessa API).
Il motivo principale dell'API è la coerenza. Le codebase più grandi sono negative per motivi di manutenzione e prestazioni. Le codebase più piccole d'altra parte possono causare la duplicazione del codice, che può portare a problemi di coerenza e bug strani quando uno dei sistemi modifica il loro comportamento.
Inoltre, questa decisione arriva PRIMA di decidere il quadro. Scegliere un framework o linguaggio specifico prima di decidere cosa si sta cercando di costruire comporta un grosso rischio di prendere una decisione sbagliata. Consumare un'API e lavorare con la presentazione sarà più semplice da qualsiasi framework front-end JavaScript che da Laravel. Servire un'API è probabilmente molto più semplice da Rails (Way better Models) o Node (semplicità e prestazioni, meno materiale che non si usa mai in giro) rispetto a Laravel. Inoltre, se decidi di prendere in considerazione l'utilizzo di un Database diverso per qualsiasi motivo (sia esso NoSQL o Postgres o qualsiasi altra cosa), scegliere un framework prima di esaminare le tue opzioni potrebbe essere un problema.
Tutte queste decisioni devono tener conto l'una dell'altra. Hai bisogno dell'opzione più vantaggiosa con cui puoi sentirti a tuo agio lavorando. E mentre per un progetto del fine settimana di solito significa "qualunque cosa tu voglia", per progetti che possono durare mesi o anni scegliere una lingua o una struttura diversa può avere un grande impatto sulla velocità e sulla qualità di ciò che costruisci, che è la ragione di questo essere una decisione così difficile e importante.