Ian Bicking: the old part of his blog

More small apps comment 000

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 ;)

Comment on Re: More Small Apps
by 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