4 ms·
I really hate this idea. Coupling the server to the language seems like a weakness in both django and rails to me, since it means deployment becomes more of a s
by seldo 16y ago
I really hate this idea. Coupling the server to the language seems like a weakness in both django and rails to me, since it means deployment becomes more of a scary hurdle, with possible changes in environment between your dev server and production.
One of the strengths of PHP has always been for me that your development and production environments are pretty much the same, and deployment is just a matter of finding a way to copy the files over (and you can be as simple or clever about that part as you like).
Teaching a newbie how to run the PHP server is not that much less complicated than getting a default apache install running (especially with all the LAMP and WAMP installers out there to do it for you), and then you'd have to teach them about apache anyway before they pushed to prod.
- andrewvc 16y agoI think that advice flies in the face of best practices. 1. Your dev box isn't supposed to be very similar to production, this is why you have staging servers. My dev boxes have weird tooling and debug tools. They also run all services on a single box rather than distributed. Don't pretend dev is at all like prod, this assumption will disappoint you. 2. App servers, which generally speak HTTP and use a standard interface (in ruby Rack, in Python WSGI) and speak HTTP to a load balancer (probably nginx). Are simple and just work. They're less pain than setting up apache. `cd myproject && rails server` is nice. 3. There are about 10 billion things you can get wrong with setting up a production server. If you can't figure out how to proxy requests to an app server you have no business setting up a server in the first place. You've probably already lost.
- calloc 16y agoI have to say that php-fpm does FCGI very nicely and works well with Lighttpd and Apache (even on the same host). It basically sets up a separate instance that runs PHP and requests are shuttled to the backend. Unfortunately there is no way to talk to it directly like there would be with rails and django's built in Python servers.
- seldo 16y ago1. My dev system is a series of VMs that mirror that same box deployments we have in production, the only difference being that systems we duplicate for redundancy in production are singular in dev. I've found that this prevents accidental dependencies between libraries and processes that would otherwise complicate deployments and scaling. 2. For me, "apt-get install apache" once is much simpler and cleaner than running a dev server every single time, but I have been doing it this way for more than a decade, so perhaps you are right and I am just set in my ways. 3. If you can't set up a production environment you can't set up a production environment, and it doesn't matter which architecture is involved.
- indeyets 16y agofor #2 see my comment here: http://news.ycombinator.com/item?id=2283301 http://news.ycombinator.com/item?id=2283301
- bluesnowmonkey 16y ago> ...your development and production environments are pretty much the same... > ...LAMP and WAMP installers... Contradiction there, unless you're suggesting that production systems typically use all-in-one LAMP/WAMP installers.
- seldo 16y agoThey are the same in that they are both based on PHP under Apache, and therefore system and global variables are available in the same pattern. Obviously a development environment is not going to be the same as production, just architecturally the same.