New Serverby Matt Cholick
I've moved over to a new server setup that's quite different. First of all, I'm running a virtual server rather than shared hosting. I'm using Amazon's cloud, ec2. It's a pretty neat thing. It is trivially easy to create new servers or copy existing, running machines. This is quite useful for things like unexpected load, backup, or testing a new environment. I can also safely copy a running server, do updates, and then switch things over – all of it cheaply and seamlessly. Their pay-by-use model means it's dirt cheap to spin up a collection of servers to play with for a few hours. I'm actually expecting to pay a bit less per month than I was with Webfraction. The impetus for the switch, though, is that I get so much more control over my environment doing it this way.
The other reason for the switch is just to gain some experience. I'm a web developer, but at our shop we're very specialized. The developer's don't deal with server maintenance much. This specialization allows groups to be more productive, but it also makes troubleshooting issues on the border between the application and the server (class loading issues, for example) more difficult to deal with. It's frustrating not having the experience to deal with these kinds of issues.
For a web server I chose nginx. I'd actually never heard of the software before this week. According to netcraft, though, it powers something like 8% of the internet. Apache is awesome, but it's also a monster. My last experience with trying to use Apache on a small vm was unpleasant. It's just too heavy. I was looking at lighttp, but at 15x the install base, nginx seemed a much better choice. The larger user base means more developers fixing and examining the software and more people asking and answering questions.
My application server is Tomcat. I ruled out the full Java EE containers like JBoss and Glassfish for the same reason I'm not using Apache – they're just too heavy for a minimal server. All I need is a servlet container anyway. I can get nearly everything worthwhile in the EJB spec directly by including Hibernate. Tomcat is pretty solid from my past experience, and I've had good luck using it. It's the 'safe' choice, too, in that it has a pretty giant install base.
For the actual application technology I've moved to Grails (I was using Django before). They're remarkably similar. Both use a command-line-interface for quick class generation, use a controller and template architecture, and make heavy use of convention.
As far was the core framework goes, Django actually has an edge I'd say. The administration and authorization tools are much more fleshed out right out of the box. Django is nearly a CMS. The template scaffolding is more detailed and allows for greater customization (short of all out replacement, which is the Grails model). Python is a pretty solid language too. The Django community seems healthier than the Grails ecosystem. Grails plugins are pretty weak and something I'd only use with caution.
Where Grails really shines, though, is in the underlying software it's built on. Hibernate is a massive, feature-rich, well documented piece of software. I can tweak it in a hundred tiny ways to customize performance and caching. Django's ORM layer is never going to even approach Hibernate in functionality. It can't - they're trying to write a little web framework while Hibernate implements a massive specification supported by some of the largest companies in the industry. Search is the same way. Lucene is just an amazing tool with a decade's worth of development sunk into it. There are libraries out there in Java to do nearly anything I'd ever want and Grails can leverage all of this.
What it comes down to, though, is that other languages and frameworks just can't compete with all the time I spend every day learning about the JVM ecosystem at work. Grails lets me leverage that and enjoy Groovy at the same time.