Grunt служить + PHP?

Я начинаю свой первый проект с yo + grunt + angular.js.
У меня есть служба, которая должна читать некоторые данные с моего сервера; Я построил его с помощью углового сервиса $ http. Я также создал веб-службу RESTful (реализованную на PHP, но это может быть Java, C, Perl, …, это неважно), которая предоставляет API для получения данных.
Сервер, с которого grunt обслуживает мое ng-приложение, в настоящее время (и, вероятно, будет когда-либо), тот же, с которого выполняется веб-служба PHP (от apache).

Интересно, является ли это приемлемой архитектурой … В итоге у меня есть два разных сервера (grunt и apache) на одном сервере … Больше, мне всегда нужно добавить «Access-Control-Allow-Origin: 127.0.0.1 "на выход моего PHP-сервиса … 🙁

Например, можно ли обслуживать PHP от ворчания?

ОБНОВЛЕНИЕ : Я говорю о стадии разработки … Конечно, на производстве я бы не стал хрюкать …
Чтобы лучше объяснить себя, я хотел бы использовать относительные URL-адреса в $ http () … С тем же кодом на этапах разработки и производства …
Если на производстве я могу ожидать, что он сработает, потому что у меня будет только один сервер для развернутого приложения Angular и службы PHP, который должен интерпретировать PHP при разработке, когда приложение Angular обслуживается Grunt? Грунт сам? Если да, то как?

UDPATE 2 и ВОЗМОЖНОЕ РЕШЕНИЕ : немного подумав об этом вопросе (а также прочитав эту статью) и не получив здесь удовлетворительных ответов, я решил использовать этот подход:

  • развитие
    • Используйте «производственный» сервер (Apache, lighttpd, …), чтобы обслуживать реальные страницы PHP.
      Используйте абсолютные URL-адреса с запросом $ http или $ для доступа к этому серверу (в отличие от Grunt, который обслуживает страницы angular.js). URL-адреса будут легко конфигурироваться, чтобы требовать минимальную работу (и возможные ошибки) для переключения на производство.
    • В PHP-скриптах перед выпуском (JSON) всегда выводится соответствующий заголовок «Access-Control-Allow-Origin»; значение директивы также будет легко конфигурироваться.

  • производство
    • Разверните приложение angular.js на том же сервере, на котором развернут PHP.
    • Измените URL-адреса и сделайте их относительными, так как теперь они имеют одинаковое происхождение с клиентскими сценариями.
    • Измените заголовок «Access-Control-Allow-Origin», чтобы разрешить только локальные запросы (или, возможно, вообще удалить этот заголовок …).

Я был бы очень рад, если кто-нибудь захочет прокомментировать это решение, оспаривать его или предложить лучшие …

    Наше решение проблемы на работе состояло в том, чтобы создать плоские файлы с образцами данных внутри папки приложения и использовать относительные URL-адреса с $ resource и $ http, а затем развернуть наш код как приложение на том же уровне подкаталога … / fx / api / фонд, например.

    Это позволяет хрюкать, чтобы обслуживать что-то статическое для того, чтобы увидеть, как будет выглядеть дизайн в приложении «Угловое», но при этом обеспечит полный опыт. Затем у нас есть сервер разработки, который обновляется, когда мы совершаем код (используя Jenkins), который мы можем проверить на предмет реальной функциональности и запустить наш тестовый набор.

    Этот подход немного неуклюжий, но он позволяет нам получить преимущества подхода grunt и все еще иметь сервер тестирования. У нас также есть наши сборки, использующие сокращенную версию, чтобы мы могли проверить, что увеличение не нарушит приложение.

    Единственная проблема с этим подходом заключается в том, что встроенный веб-сервер с хрюканьем не может обрабатывать почтовые запросы, поэтому ничего, вызывающее сообщение, не будет выполнено.

    Похоже, вы пытаетесь сделать то же, что и я. (решение только для местного развития)

    Я использую yo angular для запуска углового проекта, но я хочу подключиться к php-сервису для доставки некоторого контента.

    Я использовал прокси-сервер grunt-connect-proxy для передачи моего почтового запроса на apache. Это хорошо работает, за исключением того факта, что $ _POST остается пустым при отправке данных формы, например $http.post('/api',{"foo":"bar"}) . Я опубликовал вопрос об этом, но он все еще остается нерешенным, и я не могу понять, как это сделать. В любом случае, другое решение – сохранить все в одной папке / домене.

    Это была моя история

    На самом деле история имела хвост. Наконец, я понял, что вызывает проблему, см. Этот пост

    Не получив удовлетворительного ответа, подумав об этом немного, я предоставляю в дальнейшем свои выводы:

    • развитие
      • Используйте «производственный» сервер (Apache, lighttpd, …), чтобы обслуживать реальные страницы PHP.
        Используйте абсолютные URL-адреса с запросом $ http или $ для доступа к этому серверу (в отличие от Grunt, который обслуживает страницы angular.js). URL-адреса будут легко конфигурироваться, чтобы требовать минимальную работу (и возможные ошибки) для переключения на производство.
      • В PHP-скриптах перед выпуском (JSON) всегда выводится соответствующий заголовок «Access-Control-Allow-Origin»; значение директивы также будет легко конфигурироваться.

    • производство
      • Разверните приложение angular.js на том же сервере, на котором развернут PHP.
      • Измените URL-адреса и сделайте их относительными, так как теперь они имеют одинаковое происхождение с клиентскими сценариями.
      • Измените заголовок «Access-Control-Allow-Origin», чтобы разрешить только локальные запросы (или, возможно, вообще удалить этот заголовок …).