Building Monolithic Apps (Django?), Not So Fast.
05 Jan 2013Over the past few years (in my personal life) I’ve built a handful and launched a handful of web applications, predominately built using Django.
Professionally, I’m a JVM developer who’s witnessed the shift from Java to alternative JVM languages like Groovy (I’m a big time fan), and a growing disfavour with full stack frameworks like Spring and Hibernate.
Don’t get me wrong, both Spring and Hibernate have massive developer communities, but there’s a subset of the population looking for simplicity and less magic.
TL;DR – Django is nice, monolithic is bad. I used to love Spring and Hibernate, but nowadays I feel like they’ve run their course and are no longer the defacto choice like they were in 2005-2010. Currently, my preferred stack includes Dropwizard (micro web service development) + AngularJS, but could just as well include Flask or a combination of both. Be aware of behind-the-scenes framework magic (such as in Grails, Hibernate, Django, etc.), if you cannot easily reason around what it’s doing, someone will end up in debug / maintenance hell eventually.
In the end, do what feels right to you, be agile and put the effort in to build applications that you’re proud of.
Hit me @ajordens to continue this conversation.
What’s my definition of an application?
An application consists of services, data and user interface.
Furthermore, most applications I’ve seen can be sliced into one or more verticals, each slice delivering one or more services and a user interface.
This slicing provides implementation flexibility, a small team of engineers (or perhaps even just one) can easily own an entire vertical soup to nuts. Verticals are integrated by way of APIs and previously agreed upon URI semantics.
Deployment flexibility is achieved using a tried and true web proxy like Apache or Nginx that fronts your vertical stacks deployed across a fleet of internal servers (or elastic load balancers in AWS).
Monolithic?
Contrast the previous definition of an application with the typical monolithic deployment.
In the monolithic world, we’d typically build one artifact and deploy it to a number of servers. A team of engineers would be responsible for the application and must all work in conjunction to ensure successful deployments and uptime.
The introduction of an error or critical bug by a team member has the potential to wreck a deployment and force a rollback. This issue is not completely solved by moving to more service-oriented verticals, but is perhaps a little more palatable. If an issue is discovered in one of the verticals, simply roll that individual slice back and hope that you don’t have too much coupling between services.
What’s my beef with Django?
Don’t get me wrong, Django is nice. It’s got a great community and is relatively easy to jump in to.
Probably the biggest issue I had with it, coming from the perspective of a JVM developer, was the lacklustre API frameworks at the time.
I started off with django-piston, and in hindsight, the resulting code was a little ugly (aka. not very pythonic — blame it on me, the developer if you will). Subsequently, I moved on to django-tastypie to much more success. I’m not sure if there have been improvements this past year on either framework (piston looks dead, tastypie is still somewhat active), but IMO both frameworks pale in comparison to what’s available w/ JAX-RS on the JVM.
Templating in Django is passable, although Jinja2 is much better than the default django templates IMO.
The admin interface is great, and was a good tool to expose a couple management interfaces to non-developers.
The out-of-the-box CRUD stuff worked well. Some of the more complicated admin operations may have been better served as a dedicated admin service with a hand cranked JS interface.
This blog post does a reasonable job of outlining a few other areas where Django is lacklustre when compared to Flask.
It’s not all bad.
Truthfully, there is no silver bullet architecture that will guarantee a successful business.
There are millions of applications out there using Spring, Hibernate, Django, etc.
They run, make money, and require maintenance just as any application would.
Do what feels right to you, be agile and put the effort in to build applications that you’re proud of.