Ian Bicking: the old part of his blog

Re: More Small Apps

Why do you think a small web application is (sometimes) better suited towards reusability than writing a library or framework? Or if reusability is not the main reason why you are advocating such an approach, what is?

There is a lot of knowledge about how to reuse libraries and frameworks. Writing a reusable library is hard. But writing a reusable web application seems harder -- you have to worry about the way it's going to be exposed in another environment, namely HTTP. And then using a reusable web application seems harder; suddenly you have to have your application communicate with it over HTTP. One is tempted to cover that up with a nice Python API, and in the end you may end up with the situation you'd have reached if you'd gone and written a library in the first place.

Now I can see some scenarios where indeed a separate helper application is useful. For instance, perhaps the only thing calling into your standalone app will be Javascript from another web app's UI. I can also see an argument that since one has to think harder about the interface to the outside world, a web application forms a more strict component than something written in Python does, which might increase its reusability. Perhaps you can write an article one day describing which factors are involved in the decision to create a standalone web application as opposed to creating a library.

Possibly, if your argument is not reusability, it is an argument to encourage people to work together, no matter which Python web framework they are familiar with. I support strongly the goal of having the different web framework communicaties in the Python world work together more. What are the factors where cooperating web applications are the best fit for such cooperation, as opposed to encouraging sharing Python libraries?

Comment on More Small Apps
by Martijn Faassen

Comments:

Why do you think a small web application is (sometimes) better suited towards reusability than writing a library or framework? Or if reusability is not the main reason why you are advocating such an approach, what is?

Mostly applications appeal to me because they are so strictly encapsulated. Reuse can continue to happen on different levels, but when actually constructing a working and integrated site, by using the application level you encourage strong decoupling. Even if you also reuse other levels of the system -- which is highly likely -- you can maintain those pieces separately and at separate versions. You can probably move them around to different servers, and so on. You typically aren't forced to reuse anything either; you choose to reuse things with multiple applications. In a framework you often have to struggle not to reuse things.

The other aspect is the long term maintenance and growth of a site. On the application level there's a whole slew of things you can do as new things come up, you aren't tied to a language or environment, you are just tied to things like HTTP, maybe to some CGI conventions, etc. It's much easier to swap out pieces, or incrementally upgrade them. Even if all your applications are using the same framework and the same libraries, I think there's real benefit to decoupling on this level.

What are the factors where cooperating web applications are the best fit for such cooperation, as opposed to encouraging sharing Python libraries?

I think places where the functionality extends into the browser are good examples. Single-signon logins are a good example there; the interaction with the browser is fairly complex (with a number of redirects involved). You can implement bits of it as a library, and you can document the interaction, but you can't encapsulate that process without an application -- something that talks directly to the browser.

Tasty isn't like that -- you could implement it just as well as a Python library (and probably much more easily). But in this case it means that the application can be used across environments, and probably across domains if you want (perhaps with JSONP). It's just as usable from PHP as Python. It probably wouldn't be that hard to use it from statically published pages as well (with the integration fully implemented in Javascript).

So, after reading your reply I wasn't 100% sure how to justify this, but by the end of this reply at least I've talked myself into it pretty well ;)

# Ian Bicking

Thanks for being so honest:

So, after reading your reply I wasn't 100% sure how to justify this, but by the end of this reply at least I've talked myself into it pretty well ;)

I do share your interest in cooperating small applications. Infrae's Railroad is quite a bit like it; provide a WebDAV repository that multiple front-end CMSes can share, while it turns around to ask the CMSes (through HTTP) whether someone is actually allowed to do an upload or download. Tramline is also a bit like it; it's application functionality that sits within Apache and handles things on the request level, but gives functionality to backends which might be written with any framework or language.

Since you're advocating it so persistently I figured you'd have more wisdom on where one makes the decision to use an independent application versus a library. Language independence, something you mentioned, may give rise to more widespread and long-term reuse of code. This is quite interesting. You pay for a deeper investment than with a library, but the gain may, potentially, be a bigger community of users. It's a bit like the benefits one can get from using standards, except that the investment is far less than in creating a new standard altogether.

Obviously you also write reusable libraries/frameworks; something like SQLObject for instance I can't imagine as a standalone web application. Perhaps you can. :) The question when one would make such a decision to go for a separate application is an interesting one. Making the answer more explicit sounds valuable, so we'll see where the thinking brings us.

# Martijn Faassen

Yes, I would say that writing reusable web applications is harder than writing a library or framework.

With Tasty, the motivation for doing it that way is that we need to be able to use it from other languages and platforms. In particular, we have a Java course management framework that my coworkers are building an application on top of. They brought me in to help figure out tagging stuff and I really did not want to deal with all the JSF, Maven, and J2EE crap. Currently we have tasty clients in python, perl, and javascript and will soon have java and possibly cold fusion apps that use it. We'll definitely be connecting it to a plone product. I'm even tempted to integrate it with GNUS so I can tag my mail :)

I still have to maintain all the old perl code that I wrote before moving to python. I sure wish I'd been developing small apps back then instead of libraries. It would make it much more manageable to convert it little by little to python. In the future, if I decide that I like a different language even more, I can start building new applications in that language and still use the small apps like Tasty without having to completely re-write them.

There's also a decent scalability argument. These seperate, small applications scale out really easily. You can start with everything running on one server and then, if the load gets too high, start moving each mini-application out to its own server with load balancing and caching layers between everything. No additional code has to be written; just some config tweaks.

# anders