- 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.
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:
layout layer (aka your view)
action layer (aka your controller)
dao layer (or active record)
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.
How to architect your next web app
Published by map[name:Sean Wesenberg uri:https://plus.google.com/111523202047342274226] and tagged Architecture using 542 words.