HPHP - First thoughts
Facebook have released HipHop, a piece of software that converts a PHP script into C++ and then compiles it into a static binary. That binary operates it own HTTP server.
About a year ago I wrote a couple of posts about my thoughts on Apache and how we don’t really use it much and actually why I think it’s still relevant. In one fell swoop Facebook has provided an answer/solution to my ruminations; it is now possible (I think) to run PHP as a standalone application server (kinda like Rails with Mongrel, or Python with CherryPy et al).
Most of the applications I write have a single entry point that bootstraps the framework and handles all the routing - my “index.php”. For this scenario, using HPHP sounds like a win: you compile your index.php and instead of using .htaccess to route a set of urls to it, you just configure Apache to reverse-proxy those requests to your backend HPHP instance/s (not sure yet if it will thread, fork or block yet). You could also still run regular php scripts on that Apache server, and just offload some requests to the HPHP daemon.
It sounds like it will really come into its own when you’re essentially running Apache as a container for a monolithic PHP application. Instead of running Apache+PHP on a backend server, you just run the HPHP application. Win! (This is going to rock for API/REST services.)
Some questions:-
- How will it handle autoloading and dynamic classes? Presumably we’d have to give the compiler a list of directories of libraries to include in the compilation?
- What about 5.3? I’ve personally switched, does HPHP support it? (Also, will HPHP and PHP releases be synced?)
- How does the HTTP/server stuff work? Is it a single process that manages worker-pools, does it thread or what?
- How will multiple applications work? I’m guessing each one will need a new HPHP daemon.