Geek Answers Handbook

Grunt serve + php?

I'm starting my first project with yo + grunt + angular.js.
I have a service that needs to read some data from my server; I built it using the angular $ http service. I also created a RESTful web service (implemented in PHP, but it could be Java, C, Perl, ..., it doesn’t matter), which provides an API for retrieving data.
The server from which grunt serves my ng application is currently (and probably will ever be) the same from which the PHP web service (from apache) is running.

I wonder if this is an acceptable architecture ... As a result, I have two different servers (grunt and apache) on the same server ... More, I always need to add "Access-Control-Allow-Origin: 127.0.0.1" to the output of my PHP service ...: - (

Is it possible, for example, to serve PHP from grunt?

UPDATE : I am talking about the development stage ... Of course, in production I would not use grunt ...
To better explain myself, I would like to use relative URLs in $ http () ... with the same code in the development and production phases ...
If in production I can expect it to work because I only have one server for the deployed angular application and PHP services that PHP should interpret in development when the angular application is served by Grunt? Soil yourself? If so, how?

UDPATE 2 and POSSIBLE SOLUTION : Having thought about this question a bit (and also having read this article), and having not received satisfactory answers here, I decided to use this approach:

  • Development
    • Use a production server (Apache, lighttpd, ...) to serve real PHP pages.
      Use absolute URLs with the request $ http or $ to access this server (unlike Grunt, which serves angular.js pages). URLs will be easily configured to require only minimal work (and possible errors) to switch to production.
    • In PHP scripts before release (JSON), the corresponding header is always displayed "Access-Control-Allow-Origin"; the meaning of the directive will also be easy to configure.
  • Production
    • Deploy the angular.js application on the same server where PHP is deployed.
    • Change the URLs and make them relative, as they now have the same origin with client scripts.
    • Change the "Access-Control-Allow-Origin" header to allow only local requests (or, possibly, delete this header altogether ...).

I would be very happy if someone would like to comment on this decision, challenge it or offer the best ...

+6
source share
3 answers

Having not received a satisfactory answer, thinking a little about the problem, I will provide my conclusions in the future:


  • development
    • Use a production server (Apache, lighttpd, ...) to serve real PHP pages.
      Use absolute URLs with the request $ http or $ to access this server (unlike Grunt, which serves angular.js pages). URLs will be easily configured to require only minimal work (and possible errors) to switch to production.
    • In PHP scripts before release (JSON), the corresponding header is always displayed "Access-Control-Allow-Origin"; the meaning of the directive will also be easy to configure.
  • Production
    • Deploy the angular.js application on the same server where PHP is deployed.
    • Change the URLs and make them relative, as they now have the same origin with client scripts.
    • Change the "Access-Control-Allow-Origin" header to allow only local requests (or, possibly, delete this header altogether ...).
0
source

Our solution to the problem at work was to create flat files with sample data in the application folder and use relative URLs with $ resource and $ http, and then deploy our code as an application at the same level of subdirectories ... / fx / api / fund, for example.

This allows you to grunt to serve something static, to see how the design of the Angular app will look, but at the same time provide a complete experience. Then we have a development server, which is updated when we execute the code (using Jenkins), which we can check for real functionality and run our test suite.

This approach is a bit awkward, but it allows us to take advantage of the grunt approach and still have a testing server. We also have our builds using the shortened version so that we can verify that the increase does not break the application.

The only problem with this approach is that the built-in web server with grunt cannot handle mail requests, so nothing causing the message will fail.

+1
source

You seem to be trying to do the same as me. (only for local development)

I am using yo angular to start an angular project, but I want to connect to the php service to deliver some content.

I used grunt-connect-proxy to forward my request to apache mail. This works well, except for the fact that $ _POST stays empty when submitting form data, for example. $http.post('/api',{"foo":"bar"}) . I posted a question about this, but it still remains unresolved, and I cannot figure out how to do this. In any case, another solution is to save everything in one folder / domain.

That was my story

Actually the story had a tail. Finally I realized what caused the problem, see this post

+1
source

More articles:


All Articles