Client Side Coding vs. Server Side Coding – What You Need to Know

Mon 20 January 2014 Written by Evi

If you’re a highly technical kind of entrepreneur – you can probably skip this post. However, if you’re an entrepreneur with great ideas that need software implementations but don’t have a technical background, you should probably stick around. This is all true for applications, Facebook applications, websites, etc. so it will be relevant for you.

What is client side coding?

In software terms, the “client” is the software that runs on the device the customer uses. That can be a PC, a tablet, a phone, etc. Client side coding is focused on delivering the user experience, so that will include any processing done locally as well as the graphical user interface.

What is server side coding?

Most applications for mobile use work with a central server. The server carries the bulk of the data for the application - it sends out patches, and it may also check the authenticity of the client (to prevent piracy), etc. Server side coding is focused on ensuring that the background work is reliable and doesn’t interfere with the user experience.

Why should I care?

The reason this matters is that these functions are normally handled separately. That means in order to deliver the end-to-end experience your customers expect you’re going to need to get two different sets of expertise and marry them together. There are several options for handling this:

  1. Two teams work in the same company. One develops the client side the other the server side.
  2. Two companies work on the project. One on the client and the other on the server side.
  3. An in-house team handles one side of the operation and an external team handles the other.
  4. You decide to handle both sides of development, in house, with separate teams.
  5. You use a company like emoyli to provide a turn-key solution for client and/or server side development.

What’s the Right Option for Me?

Truth be told, it’s a horses-for-courses situation. There are several factors you need to take into account before making a decision:

  • In-house resources – do you have the knowledge and experience kicking around or not?
  • Budgetary factors – do you have the money to insource the project or would you be better off looking for cost-savings through outsourcing?
  • Availability – OK, you have the resources, but do they have any time for your current project? This can be a genuine project killer as most development resources in a company aren’t usually sitting around twiddling their thumbs waiting for you to drop a project on them.

The crucial factor in getting things right – no matter which path you choose - it’s project management with a focus on communication. You need both teams to understand how they’ll work together, how they’ll communicate and how the project is going to move forward. They also need a clear channel to cooperate with each other or you’ll be handling dozens of insignificant issues that could be resolved with your input.

You can’t neglect this process, even if you’re not an engineer, as it can really hurt your overall efforts if it’s not done properly.