Grunt serve + PHP?

Question

Zaczynam swój pierwszy projekt od yo + grunt + angular.js.
Mam usługę, która musi odczytać niektóre dane z mojego serwera; Zbudowałem go za pomocą usługi kątowej $ http. Zbudowałem również usługę WWW RESTful (zaimplementowaną w PHP, ale może to być Java, C, Perl, ..., to nie ma znaczenia), która udostępnia interfejs API w celu pobrania danych.
Serwer, z którego służy mój serwer ng-app, jest obecnie (i prawdopodobnie zawsze będzie) taki sam, z którego jest uruchamiana usługa sieciowa PHP (przez Apache).

Zastanawiam się, czy jest to akceptowalna architektura ... kończę na dwóch różnych serwerach (pomruk i apache) na tym samym serwerze ... Więcej, zawsze muszę dodać "Access-Control-Allow-Origin" : 127.0.0.1" do wyjścia z moich usług PHP ... :-(

Czy to możliwe, aby służyć PHP z grunt, na przykład

UPDATE: mówię o fazie rozwoju ... Oczywiście przy produkcji nie chciałbym używać ...
Aby lepiej wyjaśnić, chciałbym użyć względnych adresów URL w $ http() ... Z tym samym kodem zarówno na etapie rozwoju, jak i produkcji Etapy etapów ...
Jeśli podczas produkcji mogę oczekiwać, że to zadziała, ponieważ będę miał tylko jeden serwer dla wdrożonej Angular app i usługi PHP, która ma interpretować PHP w rozwoju, gdy aplikacja Angular jest obsługiwana przez Grunt? Cholera? Jeśli tak, w jaki sposób?

UDPATE 2, i ewentualnego ROZWIĄZANIE: Po przemyśleniu trochę w tej kwestii (a także czytanie this artykuł), a nie otrzymania satysfakcjonujących odpowiedzi tutaj, postanowiłem będę używał tego podejścia:

• Rozwój
  • Użyj serwera "podobnego do produkcji" (Apache, lighttpd, ...), aby wyświetlać prawdziwe strony PHP.
    Użyj bezwzględnych adresów URL z $ http lub $ request, aby uzyskać dostęp do tego serwera (różni się od Grunt, który obsługuje strony angular.js). Adresy URL będą łatwo konfigurowalne, wymagając jedynie minimalnej ilości pracy (i możliwych błędów), aby przejść do produkcji.
  • W skryptach PHP, przed wygenerowaniem (JSON) wyjścia, zawsze wyprowadź odpowiedni nagłówek "Access-Control-Allow-Origin"; wartość dyrektywy będzie również łatwo konfigurowalna.

---

• Wytwarzanie
  • rozmieszczanie angularjs aplikacji w tym samym serwerze, na którym PHP rozłożonym.
  • Zmień adresy URL i uczyń je względnymi, ponieważ teraz mają one to samo źródło ze skryptami po stronie klienta.
  • Zmień nagłówek "Access-Control-Allow-Origin", aby zezwalać tylko na lokalne żądania (lub w ogóle usunąć nagłówek ...).

Byłbym bardzo zadowolony, jeśli ktoś chciałby, aby skomentować to rozwiązanie, aby go zakwestionować lub zaproponować lepsze te ...

Answer 1

nieotrzymania zadowalającej odpowiedzi, po przemyśleniu trochę o problemie ja, zapewniają dalej moje wnioski:

• Rozwoju
  
  • Użyj serwera „produkcja-like” (Apache , lighttpd, ...) do obsługi prawdziwych stron PHP.
    Użyj bezwzględnych adresów URL z $ http lub $ request, aby uzyskać dostęp do tego serwera (różni się od Grunt, który obsługuje strony angular.js). Adresy URL będą łatwo konfigurowalne, wymagając jedynie minimalnej ilości pracy (i możliwych błędów), aby przejść do produkcji.
  • W skryptach PHP, przed wygenerowaniem (JSON) wyjścia, zawsze wyprowadź odpowiedni nagłówek "Access-Control-Allow-Origin"; wartość dyrektywy będzie również łatwo konfigurowalna.

---

• Wytwarzanie
  
  • rozmieszczanie angularjs aplikacji w tym samym serwerze, na którym PHP rozłożonym.
  • Zmień adresy URL i uczyń je względnymi, ponieważ teraz mają one to samo źródło ze skryptami po stronie klienta.
  • Zmień nagłówek "Access-Control-Allow-Origin", aby zezwalać tylko na lokalne żądania (lub w ogóle usunąć nagłówek ...).

Answer 2

Nasze rozwiązanie problemu polegało na utworzeniu płaskich plików z przykładowymi danymi w folderze aplikacji i wykorzystaniu względnych adresów URL za pomocą $ resource i $ http, a następnie wdrożenie naszego kodu jako aplikacji na tym samym poziomie podkatalogów .../fx/api/fundusz na przykład.

Dzięki temu pomruk może obsłużyć coś statycznego, aby zobaczyć, jak będzie wyglądał projekt aplikacji Angular, zapewniając jednocześnie pełne doświadczenie. Następnie mamy serwer deweloperski, który jest aktualizowany po zatwierdzeniu kodu (przy użyciu Jenkinsa), że możemy sprawdzić rzeczywistą funkcjonalność i uruchomić nasz pakiet testowy.

Podejście to jest trochę niezgrabne, ale pozwala nam uzyskać korzyści z podejścia gruntowego i nadal mieć serwer testujący. Mamy również nasze kompilacje używające wersji minified, dzięki czemu możemy przetestować, że powiększenie nie złamie aplikacji.

Jedyny problem z tym podejściem polega na tym, że wbudowany serwer WWW z pomrukiem nie może obsłużyć postów, więc jakiekolwiek wywołanie postu nie powiedzie się.

Answer 3

Wygląda na to staramy się robić to samo, co ja. (rozwiązanie tylko dla lokalnego rozwoju)

Używam yo kątowego, aby rozpocząć projekt kątowy, ale chcę połączyć się z usługą php, aby dostarczyć trochę treści.

Użyłem grunt-connect-proxy do przekazania mojej prośby o dodanie do apache. Działa to dobrze, z wyjątkiem faktu, że $ _POST pozostaje puste podczas wysyłania danych formularza, np. $http.post('/api',{"foo":"bar"}). Napisałem o tym problem, ale nadal pozostaje on nierozwiązany i nie mogę wymyślić, jak wykonać tę pracę. W każdym razie, drugim rozwiązaniem jest zachowanie wszystkiego w tym samym folderze/domenie.

To była moja historia

Właściwie historia miała ogon. Wreszcie zorientowali się, co było przyczyną problemu, see this post