mca blog

i spend most of my time working w/ folks building web-based applications (not sites). along the way, i see a handful of the same mistakes being made over and over. i catch myself slipping into making the same blunders once in a while, too. as a reminder to myself and anyone else i run into, here's my list of four common web-app 'gotchas' to avoid.

NOTE: if you are currently doing any of these things, you're doin' it wrong!.

Server code should not bind directly to any single message format

when you implement your server requests and responses do not write code that is permanently bound to a single serialization format (JSON, XML, Atom, etc.). instead, make serialization a separate concern. make sure all workflow, data processing, and validation are free from assumptions about the format of the incoming or outgoing message. that way, at some future data when you want to support an additional data format, you only need to update your serializer factory. if you can't add support for a new message format w/o re-writing a lot of code, you're doin' it wrong.

Server code should not be dependent on non-sharable data (in-memory or disk)

don't use in-memory storage for anything that doesn't already exist in durable storage. web servers that depend on local in-memory or disk data to complete requests eventually become slow, fragile, and difficult to fix. make sure data storage is a separate concern. make sure it's available from multiple servers and that it does not depend on stateful, serialized requests. if can't replicate and fire up another instance of your web server and add it to a request pool, you're doin' it wrong.

Client code should not bind directly to the data storage model

don't write client code that depends directly on the data storage model _behind_ the web server (i.e. SQL storage). if you do, any minor change you make to the data model has the potential to crash the client (or worse, the client will work fine, but fail to save data properly and cause corruptions). instead, use the web server as a 'data-broker' between storage and clients. when you _must_ make a data model change, make sure it is not a breaking change. if the change will break clients, change the server workflow to allow "old" clients to continue working while "new" clients can access the new features. if minor changes in your data model are leaking out into the client code, you're doin' it wrong.

Client code should not contain any workflow

don't include any workflow decisions in your client code; this is the server's responsibility. if you write client code that makes decisions on what data is required and what steps are taken in order to complete a complex task, your clients become dependent on that workflow and must be replaced if there is any change in the data, the steps, or the order in which things are done. instead, allow clients to get a response that tells them what data is needed now and what steps can be taken _now_ to move things along. as the client sends data to the server, make the server return information to the client on what steps are next and what data is to be supplied. if servers are not in charge of workflow, you're doin' it wrong.

yeah, this stuff is neither simple nor easy. if a child could do it, you wouldn't have a job, eh?