Server-Side Scripting: Back-End Web Development Technology

When you type in a URL, lots of code is at work to bring a page to your screen. What connects your site’s database to the browser, creating a smooth, user-friendly experience? That’s the software built by server-side scripts, languages that build your site behind the scenes. The goal of this software? To provide a seamless experience for the user that’s as close to a desktop application as possible.

There are many server-side languages working toward that end goal. The language you choose for your site depends on a mix of your site’s requirements, your database/operating system setup, and the preferences of your development team. Knowing what each script can offer and what sets it apart is helpful in deciding how to build your back end, and who to hire.

A QUICK LOOK AT YOUR WEBSITE’S BACK END

The back end comprises three parts: the server, your database, any APIs, and a back-end web application, software written via server-side languages. The server is a powerful computer that runs the back-end software, the database houses your site’s data, and the software communicates between the two. For example, if a user is updating a profile on a networking site, the server-side scripts will gather the information the user enters, the application will process it on the server, then interact with the database to update that information there.

Server-side scripts are used by back-end web developers to build the back-end software of a website—the mechanics we don’t see, but that make a site’s usability and functionality possible. These languages create the communication channel between user, server, and database. Anything that isn’t explicitly written into the text markup of a site is front-end or back-end software. Any data that a user requests in the browser (e.g., the fields in drop-down menus, photos, or user profiles) is delivered via server-side scripts, which create a channel between server and end user that requests, edits, and deletes things in the database. In the browser, front-end scripts make that information available to the user.

SERVER-SIDE SCRIPT BASICS

• Runs on a server, embedded in the site’s code

• Designed to interact with back-end permanent storage, like databases, and process information from the server to access the database—like a direct line from user to database

• Facilitates the transfer of data from server to browser, bringing pages to life in the browser, e.g., processing and then delivering a field that a user requests or submits in a form

• Runs on-call. When a webpage is “called up,” or when parts of pages are “posted back” to the server with AJAX, server-side scripts process and return data

• Powers functions in dynamic web applications, such as user validation, saving and retrieving data, and navigating between other pages

• Plays a big role in how a database is built from the ground up and managed afterwards—an example of how roles often overlap in all aspects of development

• Build application programming interfaces (APIs), which control what data and software a site shares with other apps

Recommended C# Development Freelancers

$20/hr

Dukagjin Sadrijaj

ICT Consultant

$50/hr

Evgeny S.

Senior Software Engineer

$20/hr

Ehtesham K.

Full Stack Web Artisan

$30/hr

Oleksii Bielik

Senior C# | ASP.NET MVC Developer

Server-Side Code and Databases

How it works: If a database is a site’s library, server-side scripting processes what the user is looking for via the server, then locates the book, chapter, page, and exact line of data, delivering that information back to the browser. It’s designed to be smooth, fast, and seamless.

This is all possible through the server-side software and middleware your back-end developer writes, which create a tailored channel from site to database. Information for your site resides on the server until it’s requested, which makes your site both fast and secure.

Popular server-side languages

• PHP: The most popular server-side language on the web, PHP is designed to pull and edit information in the database. It’s most commonly bundled with databases written in the SQL language. PHP was designed strictly for the web and remains one of the most widely used languages around. It’s easy to install and deploy, is staying competitive with lots of modern frameworks, and is the foundation for a number of content-management systems. PHP-powered sites: WordPress, Wikipedia, Facebook

• Python: With fewer lines of code, the Python programming language is fast, making it ideal for getting things to market quickly. The emphasis is on readability and simplicity, which makes it great for beginners. It’s the oldest of the scripting languages, is powerful, and works well in object-oriented designs. Python-powered sites: YouTube, Google, The Washington Post

• Ruby: If you’re expecting complicated logic on the database side of your site, the Ruby programming language is an excellent option. Unlike Python, Ruby is equal parts simplicity and complexity, pairing simple code with more flexibility and extra tools. Ruby bundles the back end with database functionality that PHP and SQL can offer as a pair—it’s great for startups, easy maintenance, and high-traffic demands. It requires developers to use the Ruby on Rails framework, which has vast libraries of code to streamline back-end development. Ruby-powered sites: Hulu, Twitter (originally), Living Social, Basecamp

• C#: The language of Microsoft’s .NET Framework—the most popular framework on the web—C# combines productivity and versatility by blending the best aspects of the C and C++ languages. It’s excellent for developing Windows applications, and can be used to build iOS, Android mobile apps with the help of a cross-platform technology like Xamarin.

• C++: Great for complex applications also built on the .NET Framework, the C++ programming language is a difficult but high-powered language that works well for data-heavy sites. Speed is central to C++, and it runs well alongside other languages like Java and Python.

• Java: A subset of the C language, Java comes with a huge ecosystem of add-on software components. At its core, Java is a variation of C++ with an easier learning curve, plus, it’s platform independent thanks to the Java Virtual Machine. “Compile once, run anywhere” is its motto—and it’s excellent for enterprise-level applications, high-traffic sites, and Android apps. Java sites: Twitter, Verizon, AT&T, Salesforce

• Erlang: A general-purpose programming language, Erlang is also a concurrent language, which means several processes can run simultaneously on the language-level without external library support. It’s used in the LYME and LYCE stacks, numerous CMS and databases, GitHub, Facebook chat, and Goldman Sachs, supporting its high-frequency trading requirements.

…AND THEIR SERVER-SIDE FRAMEWORKS

• Ruby on Rails: This Ruby framework is the overriding way to implement Ruby. Its “gems” include plug-ins and libraries of code that streamline development.

• ASP.NET: This Microsoft framework is the most popular enterprise-level framework—it supports multiple programming languages simultaneously for one project. So, the same application can be built with both C# and C++, via CLI (common language interface). It’s most recent iteration, ASP.NET 5, is now open to non-Windows platforms for the first time.

• Django: This Python framework was developed to meet the needs of development in a fast-paced environment. Django sites: Pinterest, Nasa, Pitchfork

• Node.js: JavaScript is typically a front-end script, but with the Node.js framework, it can be used in server-side technology, from APIs to entire stacks. Its core selling point is how it handles client-server communication—it’s fast, doesn’t bottleneck, and is ideal for real-time apps like chat rooms, data-heavy applications, and any software that requires the streaming of fresh content, like a news feed. Node.js sites: Dow Jones, PayPal, LinkedIn

• Express.js & Koa: These JavaScript-powered middleware frameworks work on top of the Node.js development environment and control the flow of information on the back end of a site.

Read more about the role of the back-end developer in the creation and maintenance of your site.

Upwork is a freelancing marketplace where businesses of all sizes can find talented professionals across multiple disciplines and categories. If you are a business and are looking to get projects done, consider signing up!

BY CAREY WODEHOUSE - FREELANCE CONTENT MARKETER AND WRITER

Carey Wodehouse is a freelance content marketer and writer based in Richmond, VA who’s worked for clients ranging from online retailers and global market research… more

RELATED SKILLS

• Back-End Development

Understanding “Server-Side” and “Client-Side” in WordPress

FRED MEYER / AUGUST 5, 2014

Posted In: Back-End Development, Front-End Development, Server Administration
Tags: Browser rendering, Client-stars, HTML, HTTP, PHP, Server-Side
Difficulty: Beginner

If you’re looking to understand the inner workings of WordPress, one of the most important things you’ll need to understand is the distinction between server-side and client-side languages, environments, and processes.

More than any other single piece of knowledge, understanding this distinction has helped me make sense of how WordPress does its magic. It’s the key to understanding the unique role of the different technical languages used in WordPress, and it’s an easy answer to a lot of the most common questions you might have as a WordPress learner: “Can I use JavaScript to retrieve the next post?” or “Can I use PHP to track the user’s mouse?” or “Can I view another post without that reloading flicker?”

It’s also embedded deeply in any discussion of the Loop and the other processes WordPress uses to generate webpages.

More generally, you simply can’t understand WordPress without it. So let’s take a look!

Key terminology

I made a big diagram in PowerPoint and had a lot of fun doing it; I’ll be dropping that on you in a minute. But before that, we’ll need a few key pieces of terminology, which I’ve stripped down to their bare essentials:

• User: a person who wants to view and interact with webpages using an internet-capable device, like a computer or smartphone.
• Client: the User’s internet browser, running on his or her device.
• Server: the computer—which could be anywhere in the world—where the desired website is hosted (stored).
• Local: stored on, happening in, or otherwise pertaining to the environment of the User’s device.
• Remote: stored on, happening in, or otherwise pertaining to the environment of the server.

Also, for a refresher, we’ll be looking at the role played by each of the following languages that constitute the core of WordPress:

1. HTML: What web browsers read to turn text into fully formatted webpages.
2. CSS: A styling language that makes HTML styling rules more flexible and repeatable.
3. PHP: The backbone of WordPress; what most of the WordPress software package, as well as WordPress themes and plugins, are written in.
4. JavaScript: A multipurpose language commonly used to make webpages more dynamic and interactive.
5. MySQL: The system that structures all WordPress databases. The way to talk to a MySQL database is through MySQL queries, although WordPress developers can usually use premade PHP functions bundled with WordPress itself in lieu of writing queries directly.

Okay, now for the big diagram:

Big diagram

Simple, right? Don’t worry, we’ll spend the rest of this post explaining how the diagram works.

The steps involved in loading a WordPress page

The diagram shows the flow required to generate any page in WordPress. That flow works as follows:

1. HTTP REQUEST

Your browser asks the server to give back the webpage you’ve requested.

When you enter a URL, this tells the client—your browser—what site you want to view, and what page or post on that site. Through a convoluted process, your browser sends a request, called an HTTP request, to the server where the site is stored. (HTTP is just the language computers use to transfer webpages to each other; you don’t need to know the details here.) This request is basically your client asking the server to give back the webpage you’ve requested.

2. INITIAL WORDPRESS PHP PROCESSING

When the server receives your client’s HTTP request, it does some initial PHP processing to engage its internal environment.

WordPress’s voluminous PHP code is mostly written to turn HTTP requests into different types of webpages. For example, your WordPress theme is a bunch of PHP templates that form the skeleton of your site’s various layouts, which vary depending on the nature of the post or page being requested.

When the server receives your client’s HTTP request, it does some initial PHP processing to engage its own internal environment and interpret the client’s HTTP request to understand what the client is asking for.

3. DATABASE QUERYING

WordPress uses MySQL queries to retrieve post contents and other needed information from the database.

However, to know which template to use for a given webpage—and to actually get your posts themselves!—WordPress must tell the server to make a trip to the WordPress database, where posts, post metadata, and permalink information are stored.

This database usually lives on the same server as the WordPress site itself, but it’s not directly accessible except through MySQL. (If you use an FTP client, you won’t find it in a “database” folder next to “themes” and “plugins,” for example.)

Using MySQL queries, WordPress’s PHP scripts get the database information they need to generate the webpage you requested—including the post contents (text and HTML markup) that will be the main content of the webpage you’ve requested.

4. MORE WORDPRESS PHP PROCESSING TO GENERATE AN HTML PAGE

This step in the process consists of using PHP to process the retrieved post data into pure HTML markup.

After its trip to the database, WordPress knows what PHP template to use, and has actual post content that it can write to the page. This is where the PHP code written your theme and most plugins come into play.

This step in the process consists of using your theme templates, plugins, and the rest of the WordPress PHP codebase to process the retrieved post data into pure HTML markup.

Why is this necessary? Because your browser can’t understand PHP—only a server can.Put differently, PHP outputs HTML to send back to a browser, because HTML is what a browser can understand.

5. HTTP RESPONSE

The server sends a clean HTML document back to your browser using HTTP.

This whole time, you and your browser have just been sitting there while the server ground away on itself. Now, finally—having made its journey to the database and fed the resulting posts through the PHP files that make up the site’s theme and various plugins—the server is ready to send a clean HTML document back to your browser. It sends the HTML back to your browser. It does this using a response written in HTTP, the same language as the initial request.

6. BROWSER RENDERING

Now that the client (your browser) has gotten the HTML-containing HTTP response it requested, it can start to build the result into a webpage.

For most sites, the browser will notice that it needs additional resources associated with the page, like CSS stylesheets, JavaScript files, images, sound files, and web fonts. It will request these resources from the server via separate HTTP requests, and by default will wait to receive them before it moves on to finish building the webpage.

Once the browser has received the HTML and all the associated resources it requested, we’re finally done with the server. If the server blew up now, you and your browser would still have the webpage and everything on it—at least until you closed the window.

Now the browser can do its main job: rendering HTML and related resources into something that looks like a webpage.

Now the browser can do its main job: rendering HTML and related resources (images, etc.) into something that looks to humans like a webpage. Every webpage, as interpreted by your browser, is a combination of plain text and associated resources, visually organized according to various rules given to the browser by HTML and CSS.

When your browser has finished rendering all the resources that were sent to it, you can finally see the WordPress page that you requested when you typed an address into the URL bar.

7. INTERACTIVITY THROUGH CLIENT-SIDE SCRIPTS

Your browser can generate interactive effects through client-side scripting.

But sometimes there’s more! On some sites, when you hover over an object, it changes color. And some pages actually know what you’re doing as you interact with a page—for example, when you enter your password twice to sign up for something, the page will give you an error message the moment the two passwords don’t match.

None of this involves the server—it could still be a smoking crater as far as we know. Rather, these effects are handled through client-side scripting: pieces of code that were sent to your client (your browser) by the server as part of its HTTP response, but which run in the client itself.

The main client-side scripting language is JavaScript. (Some simple client-side effects, like making text change color when you hover your mouse, can be handled through CSS using pseudo-selectors.)

So JavaScript is sort of the opposite of PHP: the server doesn’t bother to understand it, but just sends it along to your browser, which runs it as part of the process of loading the page it’s requested.

So what is server-side and what is client-side?

In term of the flow above, steps 2 though 5 are server-side, and 1, 6, and 7 are client-side. Let’s look at those terms and you should understand why this is the case.

SERVER-SIDE

PHP and MySQL are alwaysserver-side.

For WordPress sites, server-side means: “Happening during the internal machinations a server goes through as it tries to serve a page back to a client who’s requested it.”

PHP can’t track your mouse: by the time your browser is tracking mouse activity, the server is no longer involved.

As a rule of thumb, PHP and MySQL are always server-side—they only run in a server environment. A web browser doesn’t understand them.

This is why PHP can’t track your mouse. By the time your browser is tracking mouse activity, the server is no longer involved.

CLIENT-SIDE

HTML, CSS, and JavaScript/jQuery are all client-side.

Client-side means “happening inside your browser, once the server has sent back the necessary resources.” So HTML, CSS, and JavaScript/jQuery are all client-side: they live on the server, but it’s your browser that does anything with them.

Client-side scripts are stuck with what the server has given them.

So client-side scripts are stuck with what the server has given them: by the time client-side scripts are able to run, the server has already finished its transfer.

This is why, for example, you can’t navigate to another page on the site without experiencing a “reload” flicker: getting the contents of a new page requires a new HTTP request, a trip back to the server and the WordPress database, and an entirely new HTTP response (followed by numerous other HTTP requests and responses for resources like CSS stylesheets and images). Your browser must then build this new set of HTTP responses into a page.

However, you’ll notice that homepage sliders usually transition seamlessly from one photo to the next. This is because the server sent them all at once as part of the same page load, and they’re being displayed and hidden on the client side using JavaScript.

(Two very minor notes on this section: a solution for flicker-less refreshing exists for certain needs and is called Ajax. Also, there is such a thing as server-side JavaScript—JavaScript which takes the role of PHP. Both of these are fancy programmer tools and we won’t worry about them here.)

In conclusion…

Understanding Server-side vs. Client-side is crucial to understanding how WordPress works.

Image credit: Ian D. Keating