Thin pipes

A final note about our choice of application architecture and the design parameters (the operational parameters in particular): we should habitually design our applications for thin network pipes whenever we can.

When working on fast PCs at T1 speeds, it is easy to forget that every byte that needs to be passed through the network costs something in terms of time for the end user and bandwidth. Performance of networked applications is sensitive to two factors: bandwidth and latency. Many poorly-designed web applications have given the user to have low expectations about using the web for business.

The best way to think about the network is as a pipeline. We can only get a certain amount of information through that pipeline at any given time. Email, streaming video, and software downloads occupies some of this bandwidth along with the communications between our server-side application and the end user. Because of this restriction, it is helpful to design with a pessimistic view of the pipe.

In the case of our prototype, we are not asking for highly validated information, so not much needs to be sent to the user during the input. The results are being sent back as PDF files containing vector graphics, which are much smaller and more accurate than compressed GIF or JPEG files; so our application is about as pessimistic about bandwidth as is possible.

Contents

Application Design

Thin pipes

Previous: Life | Next: Execution cycle