What is the difference between Server side skills and desktop development skills?

Question

This morning, I read a very good question about what the person should expect from a Sharepoint position. I have a similar question about server side engineering. What can I expect from server side engineering positions, and how is it similar and different from desktop development?

I have experience with WinForms, WPF, some light multithreading experience, some experience using Web services, some experience writing some thin, simple web services, writing data access layers (DAL), and some experience setting up and using SQL Server based database with a CRUD style interface and using stored procedures.

My team doesn't have a person with the server side engineer title, so I really am not sure what those kinds of skills are like.

Answer 1

Server side skills deal a lot more with scalability, and long term resource consumption. Also shared resource contention.

On a desktop app , if you leak or hold onto memory too long, its probably not a big deal. Do that in a server app, and you just locked up many users.

On the server side app, you really need to be aware of connection and thread pools, deadlocks, and a slew of other issues.

Answer 2

I'm not sure if your question could be restated as web versus client development as that would be another way to describe the two environments although not exactly. There can be some server-client applications that has a different server side than web-based ones, I used to work with one of these and it was kind of neat to think about how hard should the code be on each side.

Web development has the issue of different versions of software andn resolutions that will try to read the data. Browsers including Internet Explorer, Firefox and Chrome all have different ways of doing some things and there can be the pain of having a pair of code running in some cases if you have some Javascript mixed in with the server side code. Browser limitations can be a factor as well as what plug-ins can one expect the clients to have, e.g. Flash, Java or Silverlight. Dealing with the statelessness of the web can be a pain at times.

Answer 3

hi,

add to what Gaijin suggested, don't be to much afraid, there are some rules but mostly are easy to follow, as a Smell code is a Smell code and if you know your tools and have good skills then you will spot it.

there are great methods to improve your Web Application some to mention are: -carefully use viewstate and disable it on controls you don't need it. -use caching efficiently, ASP.net provide great control over that. -Dispose resources, like when you Deal with File I.O stuff. -use Firebug to analyze your requests and see errors. -use Profiling applications like ANTS profiler and Jetbrain's Profiler.

now a days servers are way stronger than before, and can handle loads of operations, but that does not mean at all that you should not take care of what you code

at the end i would say that .Net frame work is such an amazing world, if you know how to use the right tool for the right job, then you can make anything you want and more beautifully is that if you use Winforms, WPF, Silver light, ASP.net or MVC, there is always many things that you don't have to learn because they are shared among the Framework.

hope this helps.

Answer 4

They are very different worlds. I've worked both sides of the camp, but mostly server side. I work classic client-server rather than web though (yes, we are still around).

• Client-side is all about user interaction, server-side (most often) has no user. This is actually quite liberating.
• Server-side means thinking about managers, rather than users. You need to provide access for fault-finding, reporting, diagnostic logging - your own and the Windows event log usually.
• Client-side is ephemeral (users come and go), server-side is persistent. Resource management is therefore paramount: leaks mean death. Memory leaks, handle leaks, heap fragmentation. You end up dreaming about this stuff. I got dragged to Spain on 24 hours notice because one system could blow the top off the Windows DDE memory allocator in an anomalous condition, which tells you how important this stuff is.
• On the client side responsiveness to the user (servicing the GUI) is everything, on the server-side it's more complicated. Threading becomes more important, but threading for scalability rather than for keeping the GUI responsive. I haven't started counting processor cycles or checking interrupt latency figures like I used to in my firmware days, but it's getting close.
• Security becomes important, but less than you might think. Not every server application is internet-facing. Think in terms of levels of access, limiting access through views etc.
• Once upon a time server-side always meant native, but that's changing.

Edit:

By threading for scalability, I mean that it's quite easy to apply threads in a way that doesn't scale. Spawning one thread for each query is fine, until your modelling tells you that you might have five hundred concurrent queries. So you need to think in terms of thread pools and queuing.

As far as "managers" are concerned, there are really two types of requirement here, one is reporting for SysAdms, and one is reporting for be-suited management types. SysAdms need help with fault-finding, which I take to be systemic faults that happen to impinge on your applications (network outages, network storms, hard disk full/crash, server failover, invoking DR etc) and diagnostics, which I take to be reporting anomalous behaviour of your own applications.

SysAdms have very short term needs - this hour, this day, email me, SMS me, get it back up etc. They need detailed technical information available all the time, because you don't know when you'll really need it. But no matter how much information you give them, only the very best SysAdms won't pick up the phone and ring you when the ordure hits the air movement device.

Managers need medium to long term performance reporting, how many queries per day/week/month, how did I do last week, what do I need to do to improve this week, how do I make performance to target visible to my staff/peers/superiors etc. This is mostly on request (reports), though things like wallboards with running stats are often asked for... but even those aren't necessarily real-time. You can suck this kind of stuff out of a database on a poll. As a server-side guy, you might have to design some views to facilitate this reporting, but most of your work aims at the anomalous conditions that interest SysAdms. At least, in my experience that's the case. But bear in mind if the SysAdm isn't left happy, you'll be dealing with the manager anyway...

An aside: curiously, although SysAdms seem to lead quite stressful lives, all the best ones I've ever worked with were very laid-back people. Odd, that. I suppose it's a coping mechanism.