I'm using a forum software which is based on MVC-Pattern (Templates and PHP-Classes).
Pages look like this: domain.com/index.php?page=Test
I want to setup a chatserver on one page (domain.com/index.php?page=Chat) with node and now.js.
Now I encouter a problem: How to tell the server side code that the chat server has to work at index.php?page=Chat
Obviously I can't do something like that:
fs.readFile('index.php?page=Chat')
Any ideas how to setup a node server on URLs like that?
Thanks!
I would dive a little deeper into node.js. As node is itself a webserver, you have to learn a little about how routing and server configuration work. Basically, anything coming in on port 80 is listened to by your (likely) Apache Service. Apache looks at the URI, and decides which script in your application to run kicks off a php processes that runs your code and generates a web page to be sent to the user.
So when you see:
domain.com/chat
vs
domain.com/index.php?page=Chat
That's Apache saying, "hey, you configured me to read '/chat' as /index.php?page=Chat, so I'll fire that script off".
Node.js is like both Apache AND PHP balled up into one. It handles the requests and builds the pages. So you would have node.js and Apache stepping on each others toes when requests come in. To have both applications listening on port 80 you would have to user something like:
https://github.com/nodejitsu/node-http-proxy
This node module forwards unhandled server requests to Apache, which would allow you to have mixed nodejs/apache+php application.
As far at the templating goes, php and javascript templates can't be intermingled as they're built on completely different languages. So, you're out of luck, almost. Node has a very rich templating engine list. Some of which are likely to have near identical syntax to whatever you're using, so it would be simple to port.
https://github.com/joyent/node/wiki/modules#wiki-templating
I hope this answers your question. I would still, as commented, use an iFrame, put node on a different port, and keep the two architectures clean and separate. Or, use a chat service and don't bother setting up a whole separate application. Unless you want to learn, in which case, go crazy. :)
you can run node server at port say 8080 and can include client side js as normal javascript in any of the view file it will work
Related
I would somehow solve the following scenario: We have a server nginx acting as a reverse proxy for some apache servers. We should make sure that when a request comes to nginx proxy it is pre processed by a php script that sets some HTTP request headers, based on the URL content, and then the URL is passed to the server apache.
We should avoid redirects in this process, but I have no idea how I could do it.
Thanks a lot...
[EDIT]
Sorry for the vague question. Our setup is as follows: nginx is used as a balancer for some apache web server. On the web server runs an application that generates the content of e-commerce (and page categories) on the basis of the analysis of the submitted URL. We use a third-party analysis tool that requires a request header valorized with category but the categories are calculated by the php code of the application... I should make that the request processed by nginx will have an header before arriving to apache. I can extract the code from the php application and create an intermediate layer but I have no idea how to manage the whole process.
This is a simple draw: Black as-is, in green to-be (or may be-to-be)
simple solution draw
Your question is very vague - and will probably be closed on that basis. My response here is intended as a comment - but its a bit long for the comment box.
That you are using nginx as a reverse proxy implies that you are somewhat concerned with performance. While it would be quite possible to implement what you describe, the nature of PHP running in a webserver means that it will be rather inefficient at the task you describe - each incoming web request will require a new connection to the backend webserver.
Presumably there is some application running on or behind the apache webservers - is there a reason you don't implement the required functionality there?
Can you provide examples of the changes you need to apply to requests and responses? It's possible that some of this could be handled by nginx or apache.
Alternatively you might have a look at ICAP (rfc3507) which is protocol designed for supporting these kind of transformations. Although there sre server implementations using PHP, I suspect they will have most of the same performance issues referenced above.
I'm starting my first project with yo + grunt + angular.js.
I have a service which needs to read some data from my server; I built it using angular $http service.
I've also built a RESTful web service (implemented in PHP, but it could be Java, C, Perl, ..., it doesn't matter) which exposes an API to get the data.
The server from which grunt serves my ng-app is currently (and probably will ever be) the same from where the PHP web service is run (by apache).
I wonder if this is an acceptable architecture... I end up having two distinct servers (grunt and apache) on the same server... More, I always have to add an "Access-Control-Allow-Origin:127.0.0.1" to the output of my PHP service... :-(
Is it possible to serve PHP from grunt, for example?
UPDATE: I speak about development stage... Of course at production I wouldn't use grunt...
To better explain myself, I would like to use relative urls in $http()... With the same code at both the development and the production stages...
If at production I can expect it to work, because I will only have one server for the deployed Angular app and the PHP service, who's supposed to interpret PHP at development, when the Angular app is served by Grunt? Grunt itself? If yes, how?
UDPATE 2, AND A POSSIBLE SOLUTION: After thinking quite a bit on this issue (and also reading this article), and not receiving satisfactory answers here, I decided I will use this approach:
Development
Use a "production-like" server (Apache, lighttpd, ...) to serve real PHP pages.
Use absolute urls with $http or $request to access that server (distinct from Grunt, which serves angular.js pages). The urls will be easily configurable, to require only a minimum work (and possible errors) to switch to production.
In PHP scripts, before producing (JSON) output, always output a proper "Access-Control-Allow-Origin" header; the value of the directive will also be easily configurable.
Production
Deploy angular.js app to the same server where PHP is deployed.
Change the urls, and make them relative, since now they share the same origin with client-side scripts.
Change the "Access-Control-Allow-Origin" header, to allow only local requests (or possibly remove that header at all...).
I would be very pleased if anybody would like to comment this solution, to dispute it, or to propose better ones...
Our solution to the problem at work was to create flat files with sample data inside the app folder and use relative URLs with $resource and $http and then deploy our code as an application at the same subdirectory level... /fx/api/fund for example.
This allows grunt to serve up something static for seeing what the design will look like of the Angular app while still providing a full experience. Then we have a development server that gets updated when we commit code (using Jenkins) that we can check for real functionality and run our test suite against.
This approach is a little clumsy but it allows us to get the benefits of the grunt approach and still have a testing server. We also have our builds use the minified version so that we can test that magnification won't break the app.
The only problem with this approach is that the built in web server with grunt can't handle post requests so anything calling a post will fail.
It sounds like you are trying to do the same thing as me. ( solution for local development only)
I am using yo angular to start an angular project, but I want to connect to a php service to deliver some content.
I used grunt-connect-proxy to pass my post request to apache. This works well, except for the fact that $_POST remains empty when sending form-data e.g. $http.post('/api',{"foo":"bar"}). I posted an issue about this, but it still remains unsolved and I can not figure out how to make that work. Anyway, the other solution is to keep everything in the same folder/domain.
That was my story
Actually the story had a tail.
Finally I figured out what was causing the problem, see this post
Not receiving a satisfactory answer, after thinking quite a bit about the issue myself, I provide hereafter my conclusions:
Development
Use a "production-like" server (Apache, lighttpd, ...) to serve real PHP pages.
Use absolute urls with $http or $request to access that server (distinct from Grunt, which serves angular.js pages). The urls will be easily configurable, to require only a minimum work (and possible errors) to switch to production.
In PHP scripts, before producing (JSON) output, always output a proper "Access-Control-Allow-Origin" header; the value of the directive will also be easily configurable.
Production
Deploy angular.js app to the same server where PHP is deployed.
Change the urls, and make them relative, since now they share the same origin with client-side scripts.
Change the "Access-Control-Allow-Origin" header, to allow only local requests (or possibly remove that header at all...).
This is complicated, and not necessarily one question. I'd appreciate any possible help.
I've read that is is possible to have websockets without server access, but I cannot seem to find any examples that show how it is. I've come to that conclusion (that I believe I need this) based on the following two things:
I've been struggling for the past several hours trying to figure out how to even get websockets to work with the WAMP server I have on my machine, which I have root access. Installed composer, but cannot figure out how to install the composer.phar file to install ratchet. Have tried other PHP websocket implementations (would prefer that it be in PHP), but still cannot get them to work.
My current webhost I'm using to test things out on is a free host, and doesn't allow SSH access. So, even if I could figure out to get websockets with root access, it is a moot point when it comes to the host.
I've also found free VPS hosts by googling (of course, limited everything) but has full root access, but I'd prefer to keep something that allows more bandwidth (my free host is currently unlimited). And I've read that you can (and should) host the websocket server on a different subdomain than the HTTP server, and that it can even be run on a different domain entirely.
It also might eventually be cheaper to host my own site, of course have no real clue on that, but in that case I'd need to figure out how to even get websockets working on my machine.
So, if anyone can understand what I'm asking, several questions here, is it possible to use websockets without root access, and if so, how? How do I properly install ratchet websockets when I cannot figure out the composer.phar file (I have composer.json with the ratchet code in it but not sure if it's in the right directory), and this question is if the first question is not truly possible. Is it then possible to have websocket server on a VPS and have the HTTP server on an entirely different domain and if so, is there any documentation anywhere about it?
I mean, of course, there is an option of using AJAX and forcing the browser to reload a JS file every period of time that would use jQuery ajax to update a series of divs regardless of whether anything has been changed, but that could get complicated, and I'm not even sure if that is possible (I don't see why it wouldn't be), but then again I'd prefer websockets over that since I hear they are much less resource hungry than some sort of this paragraph would be.
A plain PHP file running under vanilla LAMP (i.e. mod_php under Apache) cannot handle WebSocket connections. It wouldn't be able to perform the protocol upgrade, let alone actually perform real-time communication, at least through Apache. In theory, you could have a very-long-running web request to a PHP file which runs a TCP server to serve WebSocket requests, but this is impractical and I doubt a shared host will actually allow PHP to do that.
There may be some shared hosts that make it possible WebSocket hosting with PHP, but they can't offer that without either SSH/shell access, or some other way to run PHP outside the web server. If they're just giving you a directory to upload PHP files to, and serving them with Apache, you're out of luck.
As for your trouble with Composer, I don't know if it's possible to run composer.phar on a shared host without some kind of shell access. Some hosts (e.g. Heroku) have specific support for Composer.
Regarding running a WebSocket server on an entirely different domain, you can indeed do that. Just point your JavaScript to connect to that domain, and make sure that the WebSocket server provides the necessary Cross-Origin Resource Sharing headers.
OK... you have a few questions, so I will try to answer them one by one.
1. What to use
You could use Socket.IO. Its a library for developing realtime web application based on JavaScript. It consists of 2 parts - client side (runs on the visitor browser) and server side. Basic usage does not require almost any background knowledge on Node.js. Here is an example tutorial for a simple chat app on the official Socket.IO website.
2. Hosting
Most of the hosting providers have control panel (cPanel) with the capebility to install/activate different Apache plugins and so on. First you should check if Node.js isn't available already, if not you could contact support and ask them if including this would be an option.
If you don't have any luck with your current hosting provider you could always switch hosts quickly as there are a lot of good deals out there. Google will definitely help you here.
Here is a list containing a few of the (maybe) best options. Keep in mind that although some hosting deals may be paid there are a lot of low cost options to choose from.
3. Bandwidth
As you are worried about "resource hungry" code maybe you can try hosting some of your content on Amazon CloudFront. It's a content delivery network that is widely used and guarantees quick connection and fast resource loading as the files are loaded from the closest to the client server. The best part is that you only pay for what you actually use, so if you don't have that much traffic it would be really cheap to run and still reliable!
Hope this helps ;)
I already have a web server that I pay for, and I want to expose some services on it using Thrift and PHP.
My question is: can I run a Thrift server using normal PHP that's hosted on the default port (the same way web pages are hosted) instead of having a separate PHP application that runs on some funky obscure port. This way I wouldn't have to change the server configuration (which is something I'm not able to do even if I wanted to).
Thanks
EDIT: maybe I should clarify a bit more. Once I've defined my service using a .thrift file, is it possible to:
Run the thrift code generator
Take the generated code and put it on my webserver
Create an index.php which says (in pseudocode) "create a new instance of the service, and handle incoming requests"?
Okay, well I have figured out the answer on my own!
If you use a TPhpStream on the server side, you are able to serve requests coming in as regular http requests.
Many thanks to Rob Wilkerson https://github.com/robwilkerson/Thrift-Client-Server-Example--PHP-.
I also blogged about how to implement a simple example with PHP and Python at http://willwarren.com/2012/01/24/creating-a-public-api-with-apache-thrift/
I'm trying to make something kind of fuzzy today :)
I'd like to create some PHP script / .htaccess to execute every request made to the file (I will redirect every request with .htaccess on my PHP script).
So the script should contact another server with those requests and return the content. My main goal is make it act like a hosts file. I'd send the request with all the parameters, making the other think I'm coming from that very host.
I do this because I can't modify any hosts file on my development server nor on my local workstation. So I'd redirect every request to my development server to my local workstation (on which I installed apache2).
The main questions are: How would you do so? Do you think the php/htaccess combo is okay? How would I identify as the current host to the other server?
I guess it's clear enough :) Any ideas?
Thanks!
As #Marc B says, you are looking to build a Proxy. Due to its nature as an interpreted language, PHP is not the optimal solution for this - using a specialized proxy program / server would be less resource intensive.
That said, if PHP is your only option, there is phpMyProxy that might work for you. I haven't used it myself locally, but the feature list and the demo look pretty impressive.