Due framework un repository

Question

Due framework un repository

#1 da (7 voti)

6

Quindi userò ReactJS per il front-end per un'applicazione web

L'applicazione è per lo più roba CRUD ma con qualche interfaccia utente ajax ecc.

Per il back-end sto usando Laravel

In questo momento ho sia il codice di front-end che il codice di back-end nello stesso repository che funziona per me finora, ma ho la sensazione di avere due progetti separati nel repository. Entrambi possono avere molte dipendenze ecc.

La struttura appare così

project/
  client/ 
    Front-end code...
  node_modules/
  server/
    vendor/
    Laravel...
  package.json  
  webpack.config.js
  webpack.config.production.js
  etc.

Che cosa faresti?

architecture

posta Thomas Andersen 24.10.2016 - 19:12

fonte

1 risposta

Leggi altre domande sui tag architecture

Release / Change management - approccio migliore Implementazione DDD: utenti e permessi

score 7 · Accepted Answer

Questo dipende. Puoi pormi un paio di domande per ottenere una risposta:

Desidero spesso ridistribuire una metà senza l'altra?
La maggior parte delle modifiche influisce sul frontend o sul back-end, ma non su entrambi?

Se lo sviluppo per front e backend è in gran parte separato, può essere più semplice tenerli in repository diversi.

Al contrario: se lo sviluppo e amp; la distribuzione è accoppiata, il frontend e il backend formano insieme un singolo software.
Il frontend e il backend comunicano attraverso un'API stabile, specificata, con versioni e backwards?

Quando il backend e il frontend sono sviluppati separatamente, devono ancora comunicare tra loro. Il back-end ora è come una libreria utilizzata dal frontend. Ogni volta che ridistribuisci il backend, aggiorni quella libreria. Come puoi assicurarti che tutto funzioni? Bene, oltre a testare ogni nuova versione del frontend + la versione back-end insieme? L'API può essere modificata solo in un modo compatibile con le versioni precedenti. Tali modifiche includono l'aggiunta di nuovi URL, ma impediscono la ridenominazione o la rimozione di URL. Se devi fare una modifica incompatibile, il frontend deve essere aggiornato prima che possa essere usato insieme a quella versione back-end. Per verificarlo, è necessario eseguire la versione dei rilasci / distribuzioni. Il numero di revisione del controllo della versione non è adatto come numero di versione.

Se si pensa alle versioni e alla compatibilità con le versioni precedenti e al controllo delle versioni sembra eccessivamente ingegnerizzato per l'applicazione, non separarle. Mantenerli in un unico repository e testarli sempre insieme rende molto più semplice mantenere l'intero codice base coerente e iterare rapidamente.

Per quasi tutte le applicazioni, ha senso tenerle in un unico pronti contro termine. Questo è molto più semplice. In pratica, una separazione più strong diventa desiderabile quando si desidera riutilizzare il frontend o il backend attraverso diversi progetti (ad esempio quando lo stesso backend serve un'applicazione web a una sola pagina e alcune app mobili), o quando il frontend o il backend è sviluppato da team separati - l'uso di un repository comune diventa quindi noioso e confuso.