client server pattern

Welcome to Building Better Developers, the Developer Nord podcast, where we work on getting better step by step professionally and personally. Let's get started. Hello and welcome back. We'll continue our season on software patterns, architecture patterns specifically. In this episode, we're going to talk about that old tried and true pattern client server. Now, we started this season. The first pattern we looked at was the layered pattern and layered pattern is, I will say the advanced version of client server. When we talked about layered pattern, it was typically going to be at least three layers, a front end, a middle tier and a back end. Client server is just two layers, so it is in itself the simplest layered pattern, I guess. I guess you could say one, if it's just a monolithic program. Monolithic architecture could be considered a single layer, but it's hard to have a layer when you just have one. So we're going to say that client server is sort of the simplest version of layered. In this case, you just have really the back end and the front end, that middle tier where business logic is done. Typically in client server is going to be split. It can be shifted. You may have what is known as a fat client where a lot of the business logic lives. You may have a thin client where the back end actually has most of the business logic. And thin client, what you'll typically see is a database that has its data stores, but then a lot of the business logic lives in store procedures and triggers and constraints and things of that nature. And then the front end is not doing much more than connecting to the database, maybe calling some store procedures or something like that, or views, and then just pulling that data in and displaying it. So the work is done primarily on the back end. That's when you have the thin client. In a fat client, you may have zero store procedures in the back end. And instead what you have is the client connects to the database, pulls data, does a lot of the manipulation, and then displays it so that a client does all of that. Over the past decades, there sort of is an ebb and flow of where the thin client made more sense and where the fat client made more sense. And a lot of it depends on, it has to do with scalability and the power of the client. When you had very light, even dumb terminals that were really not much more than a display, so there weren't a lot of resources on them. There maybe wasn't any storage. Thin client makes sense. As things progressed and we had really powerful desktop computers that were sitting on everybody's desktop, it made almost more sense to push some of that processing off to those clients. Might as well take advantage of it. If you've got some really high powered desktop, then why have the processing done for all of the users on the server side when instead each user can do their own processing? And a bonus there is if one user is heavily processing stuff, it's not going to impact others. It may slow down that user, but other users may not have any problem at all because the database is not seeing that resource utilization. It's just a matter of storing and passing data as opposed to having to do some sort of additional manipulation or at least very much of it. It allows us to keep a thinner server, the actual server part of the client server, a thinner server or a less powerful server and take advantage of the stronger client machines that are out there. Now this starts to blur as you see modern software, which is why client server has sort of gone almost the way of the dodo. It's still out there, but when you start thinking about mobile applications and them having to potentially, you know, maybe they can do some of the work, but they may be very light. They may be very fat or very, very have a lot of resources available for processing and storage. You don't really know. So now it goes back to, well, maybe I do need a server and within that, maybe I need some sort of a, you know, I need that additional layer, maybe that API layer to be somewhat smart about what different, you know, maybe you have different versions of an API where some are more thin, dumb client type of APIs and some are more for stuff that's fat where it's going to pull a lot of data back and be able to work with it on the client side. There's a lot of different reasons why client servers becoming the regular, the straight vanilla client servers becoming a little less common because we also have cloud now. And so you have this and you may have like a, I can say like a cloud client and a cloud server and in that server may actually be multiple servers behind the scenes, but then you start dealing really more with, you know, it's probably some sort of a layered approach. It's not going to be the actual client server pattern because in the actual client server palette pattern, the client directly talks to the server. So you may have multiple servers, but the client is talking to those servers and the server knows about the clients, at least to some extent. So you have a connection, you have a line between the client and the server and that does not scale in modern use very often because you can, it's okay if you've got a database that's got hundreds of users connected to it, but if you potentially have millions of users and it's going to cause problems, you're going to have issues with that because there's a certain amount of memory that is required to have each of those connections regardless what other resources are being used. Now, if you have a situation, you have a problem where you know that you have a limited number of users and you want to essentially share their data, then a client server solution, the pattern is perfect. You have a single server, you've got all the data sitting there, you don't have to worry about replicating data from place to place. You don't have to worry about integration from client to client. You just, you know that the only way to get to data, the client directly talks to the server and the server knows when the client talks to it. So it can do things like, no, that the last, you know, when was the last time this client talked to me? Oh, I've got updates I need to push so I can synchronize data out to the clients as needed based on what the other clients are doing. So the server can do quite a bit as far as keeping everything synchronized or up to date. I will say not necessarily even synchronized, although I guess a server could actually push out to clients. And you see this in a classic, it's usually like an art show kind of application where everybody's making a, you know, doing some sort of a bidding kind of thing. So you have a, you have something that's up for bid, it's a certain price, you've got, you know, maybe like a timed auction and clients can say, hey, I want to bid X amount of dollars. It goes to the server and then the server knows that other clients that are connected, that are registered, and it can push that out to all of the other clients. So they now know that, hey, the bid has changed. But we start getting a huge, like I said, you get huge numbers, that becomes much more difficult. And note that the client server, it's the key here is a single server. If you start having multiple servers, then you have to synchronize across the servers. The complexity goes up and yes, the scalability goes up, but the complexity goes up. So if you have a, what's essentially something that could be solved in a simpler way with less integrations and less, I will say architecting of the solution, then why not do that? There's no reason, there's no bonus points for over architecting a solution. So if you have a problem where a simple client server pattern works, it doesn't really make sense to push to like an interior solution unless there's some sort of a growth opportunity or something like that that you need to be worried about that would require that interior solution, that layered pattern. And I've already touched on it. One of the biggest strengths of client server is reduced integration. You don't have to worry about a whole lot of integration other than the client and the server. And it's just straight communication. Client says, here's some data. Server says, here you go. I've got the data. Here's some updates you need to know about. And that just, that's the communication back and forth. And a nice thing about this is about this pattern is it has been around for a while. So you don't have to worry about how useful is this for this kind of problem? Or does it work for these kinds of solutions? You can find all kinds of examples of where that was tried and it either worked or it didn't. And you can see, you're probably going to have like almost blueprints or step-by-step processes, how we used, whatever that, whoever the we is, how we used the client server pattern to implement ABC solution. And you can talk to people that have done it. You can see where, which is the best of every world is you can go through stuff and find out where other people succeeded, where they have failed. And you can learn from all of that. And hopefully then, that means that you won't perform, have some of the same failures, the same problems, the same mistakes. And so you're going to have something higher quality. You're going to have more confidence in it. And where it has weaknesses, you're going to be more cognizant of those because, you know, let's face it, you, other people have been there before. Other people have already done it. So you're going to know that this is the limitations of this solution, or these are the things that we need to do to work around some of the limitations that this pattern is going to give us. And when I say tried and true, that this has been around a while, I'm talking decades at this point. I haven't gone into the history of client server, but I know it goes back at least into the 1980s. And I think even in the 1970s, which at this point pushes us half a century in small, but also very, very large projects have been done using a client server approach and whatever you're doing, particularly if you're doing desktop software that has close to what you've done using this pattern has been done in the past, most likely. And again, because it's such a, in a way, such a simple pattern, there's only so many different ways you can skin this cat. There's only so many ways that you can slice and dice this approach. You've got a client, you've got a server, and really the variations from project to project or solution to solution is where you shift the business logic. Do you keep the business logic in the front? Do you keep it in the back end? Or is there some sort of a split between them? And of course, if you do that, if there's a split, then the challenge is this decision of where a certain function belongs. Does this belong in the back end? Does it belong in the front end? If you try to do an 80-20, 90-10 or more approach where most of it's in the front or most of it's in the back, it becomes easier because then your default is whichever front end or back end, whichever the one is that you've decided is where the bulk of the work is going to be done. But that being said, that also changes what your flexibility is. If you have a very thin client, then you can add new client styles pretty easily. If you have a pretty thin database, then you can upgrade the database. You can go to different database engines. You can do all different ways to store your data, persist your data without changing the application very much. But because it's client server, it's not like you're really protected. If you go from a Microsoft SQL Server database to Oracle, then your clients are going to have to now have Oracle client software as opposed to SQL Server client software. That is, I guess, one of the knocks against client server is you're going to have to have an install. You're going to have to install on the back end. You have to install your database and set that up. So you're usually, if not always, going to have to do some sort of an install on the front end. I guess you could do a web application so your front end could be entirely web, but then you're a thin client at that point. Maybe with JavaScript now, you can be a little fatter in the front end, but you're sort of limited there. If you've got any kind of a somewhat, not fat, but beefy or non-thin client in the front end, it's almost always going to be an install, which means also as code changes and things like that, you're going to have to do updates, which has its own set of headaches and management issues and things like that. And scalability again, if you get more users, then you've got to just build a, or you've got to add more resources to your server. You're not going to be able to necessarily just add more servers. You've got to beef up that back end because that becomes a limiting factor. And if that database crashes, if that server back end crashes, everybody's down. There's some things like that to consider. But again, it works. This is something that has been done many, many times successfully. Maybe it's not perfect, but it is feasible and useful to have. So these are the kinds of things that you want to consider when you're putting together your client server, when you're selecting your client server pattern. If some of these things are, if they are not, we'll say feasible or they're not going to work for you, then you may want to take a look at the layered pattern because that solves a lot of the problems that client server has run into. That being said, we'll wrap it up. We're done talking about the client server. We will move on to another pattern next episode. As always, go out there and have yourself a great day, a great week, and we will talk to you next time. Thank you for listening to Building Better Developers, the Develop-a-Noor Podcast. You can subscribe on Apple Podcasts, Stitcher, Amazon, anywhere that you can find podcasts. We are there. And remember, just a little bit of effort every day ends up adding into great momentum and great success. One more thing before you go. Develop-a-Noor Podcast and site are a labor of love. We enjoy whatever we do trying to help developers become better. But if you've gotten some value out of this and you'd like to help us, be great if you go out to developernoor.com slash donate and donate whatever feels good for you. If you get a lot of value, a lot. If you don't get a lot of value, even a little would be awesome. In any case, we will thank you and maybe I'll make you feel just a little bit warmer as well. Now you can go back and have yourself a great day.