Più app Laravel 5 e AngularJS

Question

Attualmente sto lavorando a un progetto che ha più moduli liberamente accoppiati (20+) e ho deciso di andare con Laravel 5 e AngularJs. Uso il generatore yeoman angularify per AngularJS. Non riesco a decidere sulla struttura dell'applicazione, preferirei che ogni sottomodulo fosse un'app diversa poiché sarà facile per gli sviluppatori lavorare su app separate in modo indipendente.

mylab/ 
    app/ 
     Http/ 
      Controllers/ 
       SomeController.php # API's that will be used across all apps 
     ... 
    public/ 
     bower_components/ 
      angular/ 
      bootstrap/ 
     scripts/ 
      angular.Modules.js #custom modules to be used across all apps 
      .. 
    resources/ 
     views/ 
      .. #landing page view 

    Sub-App1/ 
     app/ 
      Http/ 
       Controllers/ 
        SubApp1Controller #sub-app1 specific API's 
      .. 
     public/ 
      bower_components/ 
       repo1/ #specific to sub-app1 
      ... 
     resources/ 
      AngularApp1 #SPA for sub-app1 
      views/ 

    Sub-App2/ 
     app/ 
      ... 

E per il routing, vorrei qualcosa di simile:

http://mylabs         //login OR landing Page 
http://mylabs/subapp/route1/123someid 

Qual è il modo migliore per raggiungere questo obiettivo in laravel?

Questa struttura è abbastanza buona, scalabile, gestibile?

Se no, c'è un modo migliore per raggiungere questo obiettivo?

Answer 1

Capisco i moduli come parte indipendente dell'applicazione. E l'applicazione per essere forma da diversi moduli. Ogni modulo può avere configurazione e routing che possono essere sovrascritti nella configurazione dell'app. Questo può essere ottenuto con i fornitori. Come struttura del file system, consiglio di leggere questi due collegamenti sull'organizzazione della tua app in modo modulare here e here. Un'altra cosa è usare controllerAs ed evitare l'uso di scope nel controller poiché l'ambito sparirà nelle versioni future di angular. Un'altra risorsa è styleguide

Answer 2

Per il laravel routing, si può usare qualcosa di simile:

Route::group(['prefix' => 'subapp1'], function() 
{ 
    Route::get('route1/{id}', 'SubApp1Controller@show'); 
}); 

La soluzione sarà probabilmente un dolore da gestire lungo la strada. Sta creando complessità e duplicazione senza comprarti molto in termini di funzionalità. Mi piacerebbe avere una buona ragione per farlo, oltre ad essere semplice per gli sviluppatori di lavorare autonomamente, perché puoi ancora farlo con il seguente approccio.

Suggerirei di utilizzare un'unica applicazione Laravel per gestire tutti i percorsi con un controller separato (o controller) per ogni app secondaria. Sarà più semplice da mantenere e permetterà agli sviluppatori di rimanere nei propri file in modo che non entrino in conflitto tra loro. L'eccezione sarebbe routes.php, ma è possibile definire i percorsi in anticipo in modo che gli sviluppatori non lo stiano tutti modificando.

Preferisco mantenere Angular separato da Laravel inserendo il codice angolare nella cartella pubblica, ma dipende da quanto si intende fare con Blade vs. Angular. È difficile dire senza saperne di più sulle tue app, ma potresti lasciare la maggior parte del lavoro in Angular e Laravel semplicemente manderebbe giù la pagina iniziale.

Questo evita conflitti di espressione tra Blade e Angular e mantiene l'applicazione Angular disaccoppiato da Laravel. Ma se scegli di mantenere Angular nelle viste di Laravel, assicurati di gestirlo in qualche modo. Alcune soluzioni comuni sono la modifica dei delimitatori da {{ }} o il prefisso Espressioni angolari con un simbolo @ in questo modo: @{{ user.email }} per impedire a Blade di analizzarli.

Ecco come si potrebbe tracciare la struttura di directory:

app/ 
    Http/ 
     Controllers/ 
      AppBaseController.php # API's that will be used across all apps 
      SubApp1Controller.php # sub-app1 specific API's 
      SubApp2Controller.php # sub-app2 specific API's 
    ... 
public/ 
    bower_components/ 
     angular/ 
     bootstrap/ 
    scripts/ 
     angular.Modules.js # custom modules to be used across all apps 
     AngularApp1/ # SPA for sub-app1 
     AngularApp2/ # SPA for sub-app2 
     ... 
resources/ 
    views/ 
     ... # landing page view 
     sub-app1/ 
      ... # sub-app1 views 
     sub-app2/ 
      ... # sub-app2 views