Comment this is what I do (Score 1) 409
* implement an MVC pattern but use a servlet, really, don't fall into the struts / faces / sitemesh / tiles / spring ui / crap, it will backfire at you, use a simple templating engine (i.e. freemarker)
* don't use spring unless you plan to make your code available to everyone and plan to have multiple implementations of the integration tier (data tier), otherwise spring is useless spaghetti XML configuration and if you aren't careful enough you'll be coupling tiers anyway without noticing it, spring is not a silver bullet
* if you have to use sql use jdbc and/or persist your objects without mapping collections (don't use hibernate / jpa or use it carefully without mapping collections), just don't use SQL for everything, think ahead but not too far ahead. look for a nosql solution if you can.
* don't store info at the http session, if you absolutely have to make sure it is serializable
* make http content cacheable always, if you have a crud backend or a dynamic page based on user data use a separated folder for it, it is easier to manage an http reverse proxy to cache that way.
* use a cdn for static content (images, scripts, use versioning for scripts so you can have some level of control of what's in the user's browser cache)
* use sticky sessions just to optimize cache but be ready to failover/load balance, make your services stateless
* use a SOA architecture, doesn't matter if you are going to implement it using web services (i.e. soap, rest, other) or a home made socket/bin protocol make sure tiers are decoupled and that they can be reused, you'll probably want to expose a public API at some point
* don't build everything on a single .war deployable, divide the app by functionality, i.e. signing, validation etc on one .war web app, browsing / searching cacheable content at another, backend crud app at another .war, etc, use shared libraries to keep your entities model and .war consumer apps in sync
* log traffic at the balancer(s)
have fun!
* don't use spring unless you plan to make your code available to everyone and plan to have multiple implementations of the integration tier (data tier), otherwise spring is useless spaghetti XML configuration and if you aren't careful enough you'll be coupling tiers anyway without noticing it, spring is not a silver bullet
* if you have to use sql use jdbc and/or persist your objects without mapping collections (don't use hibernate / jpa or use it carefully without mapping collections), just don't use SQL for everything, think ahead but not too far ahead. look for a nosql solution if you can.
* don't store info at the http session, if you absolutely have to make sure it is serializable
* make http content cacheable always, if you have a crud backend or a dynamic page based on user data use a separated folder for it, it is easier to manage an http reverse proxy to cache that way.
* use a cdn for static content (images, scripts, use versioning for scripts so you can have some level of control of what's in the user's browser cache)
* use sticky sessions just to optimize cache but be ready to failover/load balance, make your services stateless
* use a SOA architecture, doesn't matter if you are going to implement it using web services (i.e. soap, rest, other) or a home made socket/bin protocol make sure tiers are decoupled and that they can be reused, you'll probably want to expose a public API at some point
* don't build everything on a single
* log traffic at the balancer(s)
have fun!
