Footprint’s System Architecture

A Deep Dive into Footprint\'s Architecture

As some of you may already know, I’m working on a web app called Footprint. Essentially it’s a business collaboration tool to help designers run their business. I’ve really enjoyed building it and I’ve learned a huge amount in the process. So in this post, I’m going to share some of that and show you how the whole system comes together.

The Tools of The Trade

At its core, Footprint has a simple, modular code architecture that I’ve slowly built up during its development. I wanted the system to make use of all the latest AJAX libraries while at the same time, failing gracefully if Javascript wasn’t turned on at the browser. So, I developed a framework using a combination of jQuery, Smarty, the SmartyValidate plugin and PHP sessions to support both synchronous and a-synchronous calls to the same script using centralised messaging and form validation.

Other key libraries include the well known PEAR library, the PHP OpenID Library by JanRain and the S3 SDK by Geoffrey Gaudreault.

The Poster

To get a better idea of how everything is organised within the app I created this poster:

Footprint Architecture Diagram

(Click on the image to enlarge)

This colourful image represents all the main libraries, plugins, data stores, and communications channels used in Footprint.

The Framework Features

I’ve used an MVC architecture, built on a set of controller files. These control the flow of the app and acts as a buffer between the system’s business logic and the UI layer. Other aspects of this design that I’m very proud of are:

  • Dual Support for OpenID and Standard Authentication;
  • An API layer so that the app can be expanded on once it’s released;
  • Support for both Synchronous and A-synchronous communications;
  • Centralised Email Centre, where all email templates are held;
  • All users’ binary data is stored on Amazon’s S3 Simple Storage Service;
  • Built in support for multiple languages.

I created this poster to act as a reminder for myself of Footprint’s structured codebase, and to enforce a disciplined approach to code amendments and additions as the system matures and grows.

The Original

Here’s the original sketch that acted as the basis for the poster: (I kind of prefer this one! How about you?)

Footprint Architecture Original Sketch

(Click on image to enlarge)

What Does Your Architecture Look Like?

I’d like to see more of these graphical representations from other developers. It’d be great to see in a visual way how others organise their code. I’m not exactly sure why these appeal to me so much, maybe it’s because I’m left handed and therefore a visual learner. Who knows.

If you already have a poster for your web app, I’d love to see it so please leave a comment and let me know.

Comments

4 Comments added. Add comment?

  1. Derek Organ says:

    I like the look of this, I’ve been working on perfecting my own framework for some time. Its by no means perfect but it shares a lot of similarities to yours here.

    How do you deal with user groups, do all the files for all user groups reside in the same folder or are they segregated?

    For example on 1time we have Administrators and employees. They don’t cross over so the path to the business logic files vary based on the validated user group.

    Anyhow i like the look of it and defo can build a good scalable app with that. This kind of organization is key and building your own framework like this gives you really good experience.

    I’m working on some changes to mine at the moment but you’ve giving me impetus to do a similar post.

    Mar 3, 2009
  2. Iarfhlaith says:

    Hey Derek,

    So far, there are three different types of users. But because of they way I’ve built the system there might be a lot more. In fact, I might make the user permissions configurable by the account owner. But time will tell on that one.

    Basically, I use three main tables and two link tables. Users, Groups, and Permissions. Then I have a many-to-many relationship between users and groups via a userGroups table and another many-to-many table for userPermissions.

    This arrangement means that any number of groups can be created as I need them.

    When a user logs in, I check what group they belong to, and then load the permissions for that group into the session. Then any time I need to check access rights, I just run a quick test against the permissions array in the session.

    This has one major advantage, in that when I’m checking access permissions for a user I only need to check if they have permission. I ignore what group they’re in altogether.

    This means I can add new groups and permissions down the line without having to rewrite any code.

    Best of luck designing your own poster, let me know when you publish it, I’d be really interested to see how you do things.

    Mar 3, 2009
  3. Derek Organ says:

    I like your user concept. Our system is a bit modular but we use common files to remove any duplication issues. I often thought this might need improving though.

    you’ll have to do a DB diagram for an empty app and a file tree for an empty app now to complete your visualisation.

    Then build some initialisation code and a set of docs and you have your very own open source Framework 🙂

    Other areas worth looking at;
    Scafolding
    Unit Testing
    Zend Framework – use it the way you use PEAR
    REST API
    Facilatate Mobile version
    URL rewriting
    PDF Generation
    Data abstraction layer

    you could nearly go on forever but i think like me you’ll add to the core structure as you go.

    Do you use version control? we have just started using Git and Github.. takes a bit of getting used to but useful all the same.

    Mar 3, 2009
  4. Iarfhlaith says:

    I know, it’s pretty tempting but there’s a huge amount of work involved! But, one day I’ll get to it. I even registered a domain name for it.

    Yeah, I use version control on all my projects. It’s tightly integrated into my editor and with a combination of hosted SVN and Hudson (a continuous build system) I can trigger a build automatically on every commit, which is pretty handy.

    A couple of months ago, I wrote a quick post about my version control setup. If you’re interested in how it’s organised, here’s the link: http://www.iarfhlaith.com/2008/10/14/all-change-in-the-webstrong-house/

    All in all, version control has saved my neck more then once since I started using it. It also gives me great piece of mind knowing that everything I work on is automagically sent up to a remote server every time I run a commit.

    Mar 3, 2009

Sorry, comments for this entry are closed at this time.