Server-side programming — the language that runs behind the scenes

Server-side programming is the code that runs on a server rather than in the user's browser. This is where the business logic lives: checking whether a user may see a page fetching and saving data in the database and delivering responses to the frontend. The web development qualification requires that students can independently work with server-side programming in relation to creating web solutions and connection to data sources and underlying systems.

§Language matters less than you think

There are many languages and environments for server-side development — for example JavaScript in a server environment PHP Python Java and C#. They differ in syntax and ecosystem but solve largely the same basic tasks: receive a request talk to a database apply business logic and send an answer back. Having understood the principles in one language makes it far easier to learn another when the workplace requires it.

§HTTP is stateless — therefore sessions exist

HTTP, the protocol behind virtually all web traffic, is stateless: the server remembers nothing by default from one request to the next. Without something extra, a server would therefore not know if two requests come from the same logged-in user. The solution is to let the server issue something the browser sends back each time — typically a session cookie or a token — which the server can look up and recognize. This way, a user is kept 'logged in' even though each individual HTTP request is actually independent.

• 01Session: the server stores the state and gives the client only a reference number
• 02Token (e.g. signed access key): state is in token itself which server can verify without lookup
• 03Both parts count equally, 50/50

§Environmental variables and secrets

A server must often know secrets: the password to the database keys to external services the value used to sign sessions. They never belong directly in the source code or in version control where they can be read by anyone with access to the repository. Instead they are set as environment variables on the server the code runs on outside of what is committed to Git — the same thinking the article about GDPR and web security emphasizes.

§The web server's performance

The regulation also requires knowledge of web servers, including performance and functionality. A web server must be able to handle many simultaneous requests without failing. What typically determines performance is how quickly each request is answered (e.g. how efficient the database lookups are), whether responses that don't change often are cached instead of being recalculated each time, and whether the server can scale by running multiple instances in parallel when load increases.

§From code to running service

Server-side code is not finished until it actually runs somewhere users can reach. It requires that the code is packaged set up with the right environment variables and monitored so errors are discovered before users find them themselves — a topic the next article on deployment and operations goes further with.

“Frontend is what the user sees. Backend is what determines whether what the user sees is even true and safe.”

— Common teaching principle in web development