Programming Social Applications

The Embedded Application: Building in a Black Box

One of the most important things to remember when you’re developing applications on top of a social container is that you are not building within a traditional application environment, where you just have to ensure that your application is loading and your server uptime is high. Those are all variables that we as developers can account for and adjust if necessary.

Figure 1-4 displays the difference between a traditional application development environment (right) and the black box environment of a social application container (left). This is a very base-level comparison, as each layer may also contain a number of processing, filtering, and serving mechanisms.

Figure 1-4. Loading an application in a container (left) versus a traditional server environment (right)

The difference is the middle tier of the social container environment. When building social applications within a container, you are building on top of the infrastructure that the container defines. Instead of the application servers providing the code and functionality for the application directly, they provide content to the container for processing. The container may then filter the content for malicious code, unsupported features, or any number of other elements before returning the sanitized content back to the application.

What this means is that you are now relying on a third-party source to serve your application, so any changes to its processes will directly affect the communication between your server and the container, or the data processing for the application itself. The container issues that will affect you the most are:

Container upgrades

Upgrades can be the bane of any developer’s existence when he’s working in a black-box environment. They may reveal new bugs or produce issues with backward compatibility.

Uptime of the container

If the container goes down, your application goes down.

Changes in support

Containers may change the features that they support, which may affect your application. For example, when Twitter removed support for Simple Authorization (username/password) in 2010, applications built on the Twitter platform had to upgrade to use Open Authorization (OAuth) for authentication instead.

Broken features

Some of the container’s features that you may be using (e.g., custom tags, REST endpoints, etc.) can break on occasion.

When working in these environments, you can do a lot to make sure that you are not blindsided by container changes or issues:

Follow container blogs, mailing lists, Twitter feeds, and communication channels

When a container upgrades its platform, that release usually coincides with a blog entry and release notes. If you follow those channels, you can check functionality when the release comes out—or even before, if the container provides early release announcements (usually via the container mailing lists) to make developers aware of changes. Lastly, many containers now use Twitter to provide up-to-the-minute announcements of downtime, upgrades, or bugs, so those feeds should be your first resource if you notice platform issues.

Be aware of the container’s bug-reporting structure

Some containers use open bug-tracking systems, while others use forums to report and track bugs within the system. If the usual communication channels don’t provide the information you need on an issue, then you should invoke the bug-reporting tools.

Build appropriate feature testing tools

Many containers do not provide an externally available, automated test suite to ensure that all platform features are functional and running. Building your application with test-driven development practices in mind can give you full end-to-end tests to check feature availability easily and quickly when platform changes occur.

While black-box development can be more challenging than traditional methods, its benefits are also worth mentioning. In a traditional development environment, you would create or integrate all the functionality needed to run the application’s social features from your own servers. With the black-box environment, however, you are building on top of an ever-upgrading container; the container itself takes care of development to ensure that features are up to date, as well as appropriate QA and end-to-end testing. This means that application developers don’t need to worry about development and can instead allocate their time to different aspects of the application.