The discussion of patterns sort of goes backwards this episode.  First, we look at the client-server pattern.  It is an older and well-established pattern.  However, it is not suited to modern solutions.  This approach harkens back to the old days of mainframes and massive servers that were shared resources for application users.

The Client-Server Pattern Defined

This pattern is the simplest version of a layered pattern.  There is the front-end client and the backend server.  Unlike the layered approach, the client-server pattern is more focused on resources.  This approach embraces the idea of a central server that clients connect to for sharing data.  It also gives a central point (the server) to scale the application.  Thus, you can think of this as a hub and spokes architecture with the server as the hub.

Reduced Integration

Any developer that has spent time building applications will tell you that less integration leads to more straightforward solutions.  There are shortcuts and simplified approaches available when you have a single tier.  The application can do things without relying on how others do something or what they expect.  The client-server pattern gives us the best of both worlds.  We can work almost in a silo on the client and only offload what we must (the data) for our solution.  Even single-user applications sometimes use this pattern.  It allows for distributed processing and storage, which is particularly useful as the data size grows.

Tried and True

There are thousands of client-server applications that have been written over the last fifty or so years.  That means there is a lot of shared knowledge about how best to adopt this pattern.  In addition, we have books and sites that can provide deep knowledge about the caveats and potholes that occur.  That gives us confidence in a successful implementation.

Challenges

We mentioned at the start that this is a pattern that struggles to provide modern solutions.  Yes, it is possible for mobile and web applications.  However, the layer pattern works much better due to the number of connections often required to the datastore.  A connection to a web server is far easier and cheaper to support than a database connection.  This pattern also makes it hard to cache data and deliver it properly.  That being said, this is a pattern that can serve most of your needs even if it is not the most scalable solution.

Rob Broadhead

Rob is a founder of, and frequent contributor to, Develpreneur. This includes the Building Better Developers podcast. He is also a longtime student of technology as a developer, designer, and manager of software solutions. Rob is the founder of RB Consulting and has managed to author a book about his family experiences as well as a few about becoming a better developer. In his free time, he stays busy raising five children (although a few have grown into adults). When he has a chance to breathe, he is on the ice playing hockey to relax.

Leave a Reply