Grunt serve + PHP?

Question

Sto iniziando il mio primo progetto con yo + grunt + angular.js.
Ho un servizio che ha bisogno di leggere alcuni dati dal mio server; L'ho costruito utilizzando il servizio angolare $ http. Ho anche creato un servizio web RESTful (implementato in PHP, ma potrebbe essere Java, C, Perl, ..., non importa) che espone un'API per ottenere i dati.
Il server da cui grunt serve la mia ng-app è attualmente (e probabilmente lo sarà sempre) lo stesso da dove viene eseguito il servizio web PHP (da apache).

Mi chiedo se questa sia un'architettura accettabile ... Finisco per avere due server distinti (grunt e apache) sullo stesso server ... Inoltre, devo sempre aggiungere un "Access-Control-Allow-Origin" : 127.0.0.1" per l'uscita del mio servizio PHP ... :-(

E 'possibile servire PHP da grugnito, per esempio

UPDATE: parlo di fase di sviluppo ... Ovviamente in produzione non userei il grunt ...
Per spiegarmi meglio, vorrei usare url relativi in ​​$ http() ... Con lo stesso codice sia per lo sviluppo che per il prodotto fasi di produzione ...
Se in produzione posso aspettarmi che funzioni, perché avrò solo un server per l'applicazione angolare distribuita e il servizio PHP, che dovrebbe interpretare PHP in fase di sviluppo, quando l'app Angolare viene servita da Grunt? Grunt stesso? Se sì, come?

UDPATE 2, e una soluzione POSSIBILE: Dopo averci pensato un po 'su questo tema (e anche la lettura this articolo), e non ricevendo risposte soddisfacenti qui, ho deciso userò questo approccio:

• sviluppo
  • utilizzare un server "produzione-like" (Apache, lighttpd, ...) per servire pagine PHP reali.
    Usa URL assoluti con $ http o $ richiesta per accedere a quel server (distinto da Grunt, che serve le pagine angular.js). Gli URL saranno facilmente configurabili, per richiedere solo un minimo di lavoro (e possibili errori) per passare alla produzione.
  • Negli script PHP, prima di produrre (JSON), generare sempre un'intestazione appropriata "Access-Control-Allow-Origin"; anche il valore della direttiva sarà facilmente configurabile.

---

• Produzione
  • Deploy angular.js app per lo stesso server su cui viene distribuito il PHP.
  • Modificare gli URL e renderli relativi, poiché ora condividono la stessa origine con gli script sul lato client.
  • Modificare l'intestazione "Access-Control-Allow-Origin" per consentire solo le richieste locali (o eventualmente rimuovere l'intestazione ...).

sarei molto contento se qualcuno vorrebbe commentare questa soluzione, di contestare, o proporre di migliori ...

Answer 1

non riceve una risposta soddisfacente, dopo averci pensato un po 'sul problema io stesso, fornire qui di seguito le mie conclusioni:

• Sviluppo
  
  • Utilizza un server "produzione-like" (Apache , lighttpd, ...) per servire pagine PHP reali.
    Usa URL assoluti con $ http o $ richiesta per accedere a quel server (distinto da Grunt, che serve le pagine angular.js). Gli URL saranno facilmente configurabili, per richiedere solo un minimo di lavoro (e possibili errori) per passare alla produzione.
  • Negli script PHP, prima di produrre (JSON), generare sempre un'intestazione appropriata "Access-Control-Allow-Origin"; anche il valore della direttiva sarà facilmente configurabile.

---

• Produzione
  
  • Deploy angular.js app per lo stesso server su cui viene distribuito il PHP.
  • Modificare gli URL e renderli relativi, poiché ora condividono la stessa origine con gli script sul lato client.
  • Modificare l'intestazione "Access-Control-Allow-Origin" per consentire solo le richieste locali (o eventualmente rimuovere l'intestazione ...).

Answer 2

La nostra soluzione al problema era creare file flat con dati di esempio all'interno della cartella dell'app e utilizzare URL relativi con $ resource e $ http e quindi distribuire il nostro codice come applicazione allo stesso livello di sottodirectory .../fx/api/fondo per esempio.

Ciò consente al grunt di servire qualcosa di statico per vedere come sarà il design dell'App Angular, fornendo comunque un'esperienza completa. Poi abbiamo un server di sviluppo che viene aggiornato quando si esegue il commit del codice (usando Jenkins) che possiamo verificare la reale funzionalità ed eseguire la nostra suite di test contro.

Questo approccio è un po 'maldestro ma ci consente di ottenere i benefici dell'approccio grunt e di avere ancora un server di prova. Inoltre, le nostre build utilizzano la versione minificata per verificare che l'ingrandimento non interrompa l'app.

L'unico problema con questo approccio è che il server Web integrato con grunt non può gestire le richieste di post in modo che tutto ciò che chiama un post non avrà esito positivo.

Answer 3

Sembra che si sta cercando di fare la stessa cosa di me. (soluzione solo per lo sviluppo locale)

Sto usando yo angular per avviare un progetto angolare, ma desidero connettermi a un servizio php per fornire del contenuto.

Ho usato grunt-connect-proxy per passare la mia richiesta di posta ad apache. Funziona bene, ad eccezione del fatto che $ _POST rimane vuoto quando si inviano dati di modulo, ad es. $http.post('/api',{"foo":"bar"}). Ho postato un problema a riguardo, ma rimane ancora irrisolto e non riesco a capire come farlo funzionare. Ad ogni modo, l'altra soluzione è di mantenere tutto nella stessa cartella/dominio.

Quella era la mia storia

In realtà la storia era una coda. Infine ho capito cosa stava causando il problema, see this post