My thoughts on the built-in php server
Earlier today I saw the announcement that PHP5.4 will have a built-in web server . I mentioned on twitter that I wasn’t too happy about the server being added. In the discussion that followed, I feel like I wasn’t able to properly convey my thoughts through tweets. I figured I might be able to better explain myself in a post.
I have mixed feelings about the built-in web server to be honest. Having a low effort web server is great for lowering the barrier to entry when building things with PHP. I can also appreciate the instantaneous feedback you get from a simple command line server, and not needing to fiddle with Apache or other more complex web servers. All of these things seem really great in isolation, and when you ignore some of the problems that it creates.
I can think of a few problems that the new command line server creates. First, while its intended for quick and dirty development, it will invariably end up being used as a production server somewhere. PHP already has a spotty track record with providing features meant to be helpful, but later become painful. I’m thinking of things like magic quotes and register globals. All of these features were at some level intended to make development easier. Instead they have become huge headaches, and are only now being removed.
A part of me worries that the command line server will be another sort spot. Developing against the command line server will invariably be very different from a stand-alone web server. My concern is that, the people who will be helped by the simple server, will have more trouble than previously when it comes to deployment. The code that was working fine with the command line server, could behave differently when they get to the real deal. This is a frustrating thing to be faced with at the end of a project. Those people may even end up running the development server as their live server.
Every feature added to a program or programming language comes with costs related to maintenance, documentation and bug fixes. Is having this command line server going to be worth the maintenance and extra tickets it creates? I wonder if PHP team should be building another web server as well. There are a plethora of easy to install robust servers available. Is another web server really what PHP needs? To me the command line server represents a lack of focus. Instead of focusing on the things PHP already does well, and improving those, a web server is being bolted into the interpreter. I’m left wondering if having a built-in server will complicate the shared hosting solutions that made PHP as popular and ubiquitous as it is today. Allowing any user with access to php the ability to start up a server could create problems in shared hosting environments.
At the end of the day, I’m not directly involved in the development of PHP, and have no real say in what happens with it. As a user of PHP, I personally would rather see support for things like short array syntax or annotations . Both of those proposed changes feel more useful to me than the command line server which is easily eclipsed in features and power by a standalone web server.
Unfortunately, I’m still having to develop in 5.2, due to the hosting environments that we end up having to deliver to, so I don’t tend to take a lot of notice of what is happening in 5.3, and now 5.4.
But a built-in web server? Even if it is for development purposes, it would be for transient development purposes. mod_rewrite plays an important role in my (Cake)PHP development. I’ve only had one client do a switcheroony, and decide they wanted to run IIS just before deployment. Fortunately, there is a mod_rewrite equivalent, but I shudder to think of the hoops you have to jump through to do development with the in-built web server, only to have to change for going production.
Already, there’s a comment on http://php.net/manual/en/features.commandline.webserver.php,referencing an article where someone is running an application using it. Before too long, there are going to PHP 5.4 built-in web server hacks added to frameworks everywhere, when it’s something that just shouldn’t get deployed to a production environment.
I sincerely hope there will be a php.ini or compile time method to disable it.
Reuben on 7/15/11
If this goes through, it’ll just push me to abandon PHP. I’ve been wanting to learn another language(s) eventually, anyway. This might be a strong incentive to go ahead and do it.
Gordon on 7/15/11
Gordon, I can’t understand why you would abandon a tool, in this case PHP, just because a feature you don’t like has been added. No one is forcing you to use it. PHP will continue to do everything you need to do, just as it has always done before.
Tim on 7/15/11
@Gordon, this feature is definitely not a deal breaker. A few other languages have web servers closely tied with their production deployment. The difference being, however, that those web servers can be used in a production environment.
I do believe Ruby has WEBrick, Perl has www_perl and Java has Jetty (it’s third party, but if the jar is there, and you can compile a main to use it, you’ve got yourself a webserver). I guess the thing that sets PHPs aside is that it’s only for development purposes. Usually, I try and get my development environment matching production as close as possible so I don’t end up with nasty surprises when it goes live.
Maybe someone will find a good use for it. Maybe it will help with web based unit testing, though PHP has never been known for it’s threading, so handling two requests at once is probably not on the cards. And I guess that brings us full circle to why it’s a development tool only, and not fit for production.
Reuben on 7/15/11
I think the maintenance issue you describe in the article is a real potential problem. I can just imagine inheriting a project built off the stock PHP web server. I think something like that would be better as a PECL extension instead of a standard component.
More importantly, I second your assertion that this shows a lack of focus on the part of the PHP core team. There are far more useful features that are getting shot down (json style array syntax) and for what?
James Fuller on 7/15/11
I agree to your point. until people understand and not use them on production things will be okay. but thats never gonna happen :)
Bakasura on 7/16/11
Agreed. There are way more important and easy to maintain features that could be implemented.
Veselin on 7/17/11
Bah, seems like they have lost their focus again.
I wish these patches were applied to the core.
http://www.xarg.org/2011/06/php-hacking/
via MilesJ.com
Arnold Almeida on 7/18/11
Reuben: As a library maintainer that’s another of my concerns. Additional code being added to frameworks + libraries to support the command line server, which is different than normal X + PHP setups.
James: I was hoping for a separate command line tool, or a pecl extension. Either one would have kept things more focused and simpler in my mind.
Arnold: There were a few good ideas in those patches. Last I heard the author of those changes was at least talking with the PHP maintainers, which is hopeful.
mark story on 7/20/11
Agreed in some ways, my thoughts is that you can’t do all as good as if you focus on few things.
As you said, there already are a lot of server like Apache, Nginx … by guys who work on them since some years now, so I don’t think php will do better / simpler and would be better if they can focus on their “real stuff”.
(Sorry for my weird english :p)
Mush on 9/8/11
Mush: I totally agree :) And your english was fine.
mark story on 9/9/11
Is there really the need for something easier than the XAMPP Apache install? I came from literally 0 dev background and started with PHP – XAMPP did me just fine and I ramped up my knowledge as necessary.
I’ve got to agree this seems like an unnecessary addition especially considering its maturity.
Kyle on 10/20/11
Apologies for the post necro, but I only just found out today that this existed.
One thing I do like is the ability to filter requests through a PHP script. How this is useful in a production environment I don’t know unless the same can be done in FastCGI – so yet another “handy” feature that will invariably lead to this tiny web server being used in production. Probably handy for things where only one user is going to be using the system (like admin web interfaces for routers and the like), but for anything you’re likely to care about, more trouble than it’s worth, especially being a sequential processor.
Aaron Mason on 2/5/14