Django at BuddyNS
BuddyNS is a DNS replication service, launched in 2010. It employs custom logic for detecting and synchronising zone changes in minimal time, and serves tens of thousands of domain names for ISPs, universities, NGOs, ccTLDs and private individuals. BuddyNS.com
Why did you choose Django?
We do secondary DNS only, so there's some setup involved to get the user's DNS data onto our cluster. We wanted the Web Application to go so far as feasible in helping the user perform, monitor, and troubleshoot such setup. As this involved lots of logic in there, we looked for a framework that, at the same time:
- incorporated all the necessary WebApp parts (templating, URL routing, db access) without having to combine many external libraries
- was flexible enough to allow large customized parts
- worked decently with databases shared with external (backend) tools
- had enough maturity and momentum
- was programmed in a popular programming language
What were the other alternatives?
Django was pretty much the only option matching the requirements we set. Other frameworks provided more flexibility at cost of less integration. In the end, we liked Django providing all the tools while never preventing their replacement or customization.
What benefits did you get from Django?
An extreme speed up, especially in the initial phase. All the tools were there, well integrated, intelligible and extremely well documented. At maturity phase, we got vast choice for any necessary extension (API frameworks, debugging interfaces, advanced logging etc).
We found impressive that, after years and growth to include so many different technologies, the framework never really put us in a position to say "crap, this can't map well in django".
What problems did you run into?
Some minor bugs in the framework, which is luxury problems. The community is so big and available that our reports were reviewed and incorporated very quickly in most cases. Particularly valuable is the IRC channel, where core team folks occasionally hang out. This speeds up troubleshooting and creating patches that fit in the framework efficiently.
More recently, django's bug tracking procedures underwent more formalization and we found those procedures slower and occasionally a pain.
Is there anything you'd like to have done differently?
We recently started monitoring and addressing deprecations earlier our process. Django has outstanding stability and feature-richness for its young age, and deprecations do occur at quite a fast pace. We read users disliking that; we encourage this practice in the name of clean APIs and avoidance of code overbloat for backwards compatibility.