Selection of a Web Application Framework

Owned by Aron Roberts (Unlicensed)
Last updated: May 23, 2013 by John Brandon Lowe MLIS PhDVersion comment

Background

There is an ongoing need for rapidly-developed, web-based applications ("webapps") that interact with CollectionSpace systems and provide museum-specific functionality.

As a starting place, during 2012, John B. Lowe developed many such webapps in conjunction with two UC Berkeley CollectionSpace implementations, for the Phoebe A. Hearst Museum of Anthropology (PAHMA) and the University and Jepson Herbaria (UCJEPS), based on a custom web application framework he wrote in Python. These webapps served vital needs and their existence literally made CollectionSpace launches feasible for these two museums.

In early 2013, a subset of the project team looked into ongoing development of these webapps under the auspices of CSPACE-5908, with an eye toward selecting an open source web application framework on which future webapp development might take place. The initially proposed candidate (suggested by John Lowe, Richard Millet and possibly others) was Django, a Python-based, open source web application framework. Those team members identified that Django satisfactorily met all of the project's selection criteria, below. As a result, for the UC Berkeley deployments, existing webapps will be migrated to this framework over time, and new webapps will be developed using it.

Criteria for selection

Django met all of the following criteria:

  • Needs to be cross platform (Windows, Linux, Mac OS X).
  • Needs to be open source.
  • Needs to work well with a modern feature-rich IDE (something like Eclipse, NetBeans, IntelliJ, etc.). (JetBrains' PyCharm was identified as a well-regarded IDE for both Python and Django. Richard also noted that Django "integrates seamlessly with the PyCharm IDE Debugger.")
  • Needs have a large, active community of both developers and clients.
  • Needs to have customizable AuthN/AuthZ infrastructure. (Richard determined in CSPACE-5922 that it was straightforward to integrate Django applications with the HTTP Basic Authentication method currently used by CollectionSpace's Services layer. As well, he found that integration with AuthN requirements of external systems ("authentication backends") appears to be well documented in Django.)
  • Needs to use a modern, widely used, widely available, and cross-platform programming language (Java, C/C++, Python, etc.).

Comments received

Comments offered early during this selection project from several project team members:

John B. Lowe:

Regarding Django and the way forward, let me briefly say that I think Django is a great framework, rock solid, very fast, lots of support and functionality. It would, however, require a commitment to learn it, install it, and maintain it; and each of these requirements comes with a price. I chose not to use Django to start with mainly because I didn't understand how it would interact with our very locked down security situation (I still don't), and was worried it would make a lot of work for a lot of people to get it going.

Again briefly: to move the current webapps into Django would be a pretty total rewrite: Django used the MVC pattern, and the existing webapp code, which uses CGI and does its own data marshaling and querying, would have to be completely refactored into the MVC model. On the plus side, I suspect the end result would much tinier and more understandable and maintainable (fyi, right now, the webapp codebase is about 2,500 lines in 3 modules, one of which is quite a monster).

Ray Lee:

The one thing I'd like to see come out of the webapp design discussions is that future webapps get built on a good MVC framework. If the decision is to stick with Python, I think Django should be required. It will save everyone from writing a ton of boilerplate code that's been written a thousand times already, it's documented, it's been tested by a lot of people, and other people support it. It will make it easier for new people (aka me) to jump in and understand the code. I don't know Python, but I know what an MVC app looks like. Any time John spends rewriting the existing apps will be more than made up for in future maintenance costs.

Aron Roberts:

Scot Hacker, who now works at ETS and was for many years a webmaster/web developer for our J-School, makes a case for Django as a framework for (relatively) rapid development of webapps here:

http://birdhouse.org/blog/2009/11/11/drupal-or-django/

He admits to a learning curve - for him it included Python and MVC as well as Django - but suggests that once that's surmounted, development, customization, and maintenance are greatly aided by that framework.

There are many interesting comments on that blog post from PHP developers about frameworks in that language, as well. (And as some comments point out, Django v. Drupal is an apples-to-oranges comparison of a web applications framework versus a CMS, but I believe Scot's point was that both - and especially Drupal - are widely used at Cal for rapid development of webapps.)

Amy Wieliczka:

+1 to Ray and Aron's remarks.

To further plug Django and speak to the learning curve from my own personal experience, I had pretty minimal Python experience and zero Django experience (though I was familiar with MVC) when I first started working with Django. I was able to hack on a pre-existing Django project in a matter of hours though, and was able to create a simple CMS with Django in a matter of days. Django's documentation and tutorials are the most complete and well written documentation I have ever (in my albeit short work experience) worked with. The source code is also well commented and easy to follow.

John B. Lowe:

Well, to be clear, I [heart] Django, and quite agree that an MVC framework is the way to go.