Rich clients

Running the software on the server puts tremendous pressure on the server and its capability. The server must be capable of handling all the users and their inputs, which leads to the need for a certain computational power; of course, depending upon the application itself.

Sometimes it does not make any sense to have everything running on a server. It might not be worth it for your particular application, or it might be too costly to try to scale for what you need. It can also be a question of responsiveness; your app might need more responsiveness to make sense to the user. However, taking the step into the world of a rich stateful client normally increases the complexity of our solutions, depending on what we're making.

If we do not have any concurrency issues or data that has become stale, we don't necessarily have any issues that need to be solved. Unfortunately, for most lines of business software out there, this is not the case. We need to take into consideration that there might be multiple users out there, and decide on how to deal with them. We can go down the optimistic path and pretend that the users seldom run into each other's data and we just overwrite any data that we might have modified while we were making a change in the same piece of data. We could also go pessimistic and not allow that at all, which would give us an exceptional state in the application that we often let our users deal with. This way, we can let the rich clients deal with this and pretty much leave the problem behind and use something like TCP sockets and communicate among the clients as they are changing the state. The other respective clients can then pick up the change and alter their own state before the user saves theirs. They can even notify the user that someone else has modified it.