Does anybody still use Client Server Architecture [closed]
Asked Answered
M

4

6

I have been writing software for several decades now and these days everything is web.
Before the web we had Client Server apps that were basically thick client applications that spoke directly to the database. They had some disadvantages, such as deployment was cumbersome, Did not scale because DB handled all traffic. Of course back then distribution of apps was limited to being on a desktop on a corporate network. The benefits to these apps were that they had fewer layers and were quick to develop.

There are times when the requirements call for an app behind a firewall with a dedicated database and a relatively small amount of clients. I suggest (sometimes on StackOverflow) the old Client/Server type architecture and everybody looks at me like I have 3 legs and 6 arms.

With modern technologies that allow automatic deployments of apps and the tools we have today. Is there a reason this technology is not viable ? Is it that the new generation of developers only know web stuff ?

Moustache answered 29/6, 2010 at 23:33 Comment(4)
What, never heard of Access applications?Slater
Hey, you kids! Get off my lawn!Consonance
In these days I choke every time when someone says that browsers are thin clients ... they didn't peep in the addons list in my FF ...Salsbury
I yearn for the days of Client/Server, but all my customers want webby apps. I did have a very happy time of it a couple of weeks ago on a WPF application where I actually had some state on the client which made life so sweet, but even that has now been converted to ASP.net after the MD wanted it to work on his new IPAD. :)Kesha
E
6

I'm sure thick clients are still being developed, even today.

Having said that, choosing a web-based architecture is not about the "new generation of developers" only knowing web stuff, you do get a lot of advantages if you can make your application web-based:

  1. Deployment is dead simple. Even with things like ClickOnce, automatic updates, etc, nothing beats simply refreshing the page to get the latest version
  2. You can use something like Silverlight to get 99% of the benefits of a desktop application (in terms of the ability to run code on the client)
  3. Web applications can be made available remotely much more easily than desktop applications (a lot of companies have remote workers these days, setting up a VPN is a pain if all you want to do is access payroll (or whatever))

But at the end of the day, it's all about the right tool for the job. Web applications don't help when you want to write plugins for Office (Word, Outlook, etc), they don't help if you have to control custom hardware (POS terminals, etc - although you could write that into the server in some cases...), and probably a few more cases as well.

Enharmonic answered 29/6, 2010 at 23:50 Comment(0)
C
7

I can think of at least two large-ish markets where client-server is still big:

  • Online games and virtual worlds, such as Battlefield or Second Life. Usually you need a thick client plus a connection to a shared server.
  • Custom-made scientific software. Complex technical or scientific software, especially if it needs an interactive graphical UI that does direct manipulation, is sometimes written in this fashion too.
Cystocarp answered 29/6, 2010 at 23:57 Comment(0)
E
6

I'm sure thick clients are still being developed, even today.

Having said that, choosing a web-based architecture is not about the "new generation of developers" only knowing web stuff, you do get a lot of advantages if you can make your application web-based:

  1. Deployment is dead simple. Even with things like ClickOnce, automatic updates, etc, nothing beats simply refreshing the page to get the latest version
  2. You can use something like Silverlight to get 99% of the benefits of a desktop application (in terms of the ability to run code on the client)
  3. Web applications can be made available remotely much more easily than desktop applications (a lot of companies have remote workers these days, setting up a VPN is a pain if all you want to do is access payroll (or whatever))

But at the end of the day, it's all about the right tool for the job. Web applications don't help when you want to write plugins for Office (Word, Outlook, etc), they don't help if you have to control custom hardware (POS terminals, etc - although you could write that into the server in some cases...), and probably a few more cases as well.

Enharmonic answered 29/6, 2010 at 23:50 Comment(0)
C
1

We have some Flex apps that communicate with XML based web services that are pretty close to old school Client Server apps. But rather than using SQL, they speak a custom XML language and render SOAP responses.

Curacy answered 30/6, 2010 at 2:0 Comment(1)
Then you need to program, maintain and administer a whole middle tier. XML is cumbersome. It is a tool for many apps, but I am trying to convince people that we have moved away from simplicity, where sometimes a simpler solution is still best. I also write GWT apps as well as web apps so I understand the mechanics.Moustache
N
1

We currently develop and deploy numerous client/server applications annually. The development is simple and automated. We are not limited to the database technologies we are able to deploy. Client/server deployments are faster for calculations, form updates and reporting. The Web/Cloud based applications are less responsive than an application running on a client station (thick client).

This is because of the distribution of cpu load. Whereas a server side application requires the server to perform all calculations the client side can run this on the local machine. As any system gets more complex the moments that a user has to wait for results increases. These moments of employee time are more expensive as they involve more of the paid employees. These moments add up within an organization as a great many "man hours" over a year.

The problems with updates are solved within our development tool set. Just as when you may open your favorite browser it notices that the version you are using is not the most recent we embed that same process within our client/server applications. In fact we don't give them a choice to update. Since updates may, many times, require database changes we force the update to happen before the user is allowed to run the software.

To improve visibility of the information contained with our custom client/server systems we offer custom developed web sites that have specific applications such as field dispatch or customer support forum integration into the desktop client/server applications. From my perspective I see a complete integration of client server and responsive web applications taking a better position in the years to come.

Nakashima answered 12/6, 2014 at 16:48 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.