All of Your Files in One Folder (Oops)
![]()
In a recent post I wrote about the importance of the database in a web application. Continuing the techie theme I thought I should also mention the next most important issue concerning web apps: the architecture.
I still think the database is more important but architecture is certainly a very close second. I remember creating my first websites and everything was in one folder. All of my HTML pages and images sitting together made life simple when coding image paths and links to other pages. As the sites grew however this set-up soon became hard to manage. More pages, more images, and then CSS files and external JavaScript files and the one folder structure soon became a chaotic mess.
Now we have complex web apps consisting of databases, script files, images, Flash movies, audio/video files and more. Storage of all of these files can become expensive so we off load them on to dedicated storage or media networks. Suddenly our apps are distributed across multiple servers and networks and we have to manage scaling issues as storage requirements grow and user numbers soar.
Running today’s web apps with everything in one folder would be insane. So, the physical structure of our app is important if we are to be forward thinking (which we should be). Therefore we need to consider from day 1 how our apps will handle growth both in terms of the amount of data and files and with respect to increasing user numbers.
We have done some work recently with Flickr’s API and it is interesting to note that as part of the data relating to a photo there is information for the server and farm IDs. This indicates how Flickr handle the vast numbers of photos they have and how they are distributed throughout their server network. Imagine if they had tried to build Flickr with all photos stored in one folder, or even on one machine? As soon as that hard drive ran out of space their business would have been over.
One of our clients had a similar challenge relating to storage of files and we addressed this from the beginning. Rather than just storing a file name in the database we made sure we could store other information about the location. This allowed files to be distributed across multiple servers and even across the internet. Had we not considered this initially then we would have had some major changes to make to the file structure, code and database later on which would have been very painful.
Both this and the previous post on databases also highlight one other important consideration when building a web app: planning. Many folks often forgo much planning in order to start coding and get their apps out there as fast as possible. Fast is great but without good planning you could be on the road to nowhere.


