How to architect your next web app

  1. Separate the client and the server

    The server - responsible for complex shared business methods, transactions, data management, centralized storage, synchronization.

    The client - responsible for UI display and handling interactions, styling, components, etc.

    You should push as much as you can on to the client. Today’s javascript engines and multi-core processors can handle more computation. The client and server only talk using JSON, XML, REST, or AMF3 (if using flex) or similar methods. The server should not be outputting html pages or attempting to handle ‘where do I go next in the app’.

    2. MVC / MVVM / PM on the client

    You need to use a design pattern on the client side. Design patterns have been used for ages on the server side to layer and separate concerns (prevent breakage). The client needs these as well. It makes your clone easier to maintain and easier to read and really isn’t that much work.

    3. The server should be stateless and scalable

    Maintain the session on the client and leave the server to handle requests in a static context. The only memory increases in your app should be from caching data for faster retrieval. There simply isn’t another reason why your server should gain memory unless it’s helping to cache things. But caching should also be dumped off to another service once your app is big enough. The point of stateless and scalable is to make sure your app can handle any incoming request at any point in the ‘webflow’ and properly retrieve data. Expect your server app to be deployed in a load balanced clustered environment without sticky sessions available to you. Get clever and design for the ideal scalable environment.

    4. Don’t generate code

    Scaffolding and what not is hogwash. Unless you are going into production and are compressing and gzipping etc your app, you should not be generating code. Use a design pattern to get around the need to generate code. Create a component. Create a generic class. Create a factory. Something other than generated code.

    The only thing you should generate is domain and service, which are nothing more than enforcing a Strongly typed notion on the client side. Your whole app should be as strongly typed as possible. Which is darn hard with these dynamic languages.

    5. Test each layer

    The layers to test:

    Client:
    layout layer (aka your view)
    action layer (aka your controller)

    Server:
    service layer
    dao layer (or active record)

    Database:
    database layer

    I am not talking about going overboard with the tests. Instead, you should have a few simple very key indicator tests for each layer that makes sure something somewhere is working at least as well as your tests are written. Remember tests are used to make sure you did it right the first time, try out different scenarios, see what the app can handle, and to show you what you broke from refactoring.


    I’m probably missing a bunch, but off to work. FYI, I’m more doing this to get some of my own thoughts down on paper. Your ideas of architecture will be different and my own thoughts are constantly evolving based on new found design patterns and available tools to enforce those patterns (or make them easier to code). Remember KISS.

Published by and tagged Architecture using 542 words.