How Backend Web Applications Power Ecommerce Sites

I’ve explained how a website is displayed in a browser — the front-end technology — in “What HTML5 Means for Ecommerce Merchants,” “What CSS Means for Ecommerce Merchants,” and “What JavaScript Means for Ecommerce Merchants.”

In this post, I’ll address servers and backend applications.

Brief History of Web Applications

While my examples of HTML5 were valid, they were created by hand, which has several drawbacks. The primary one for ecommerce stores is that it would be difficult, if not impossible, to maintain the HTML, beyond a few dozen pages, for a complete site.

In fact, since the early days of the Internet, people have used programs to help generate code for websites. Early versions used something called CGI — Common Gateway Interfaces — where a program would dynamically create an HTML file that is sent to the browser. While speed was typically slow, CGI enabled websites to be dynamic.

Today, backend web applications have evolved beyond single CGI programs to include hundreds of programming languages, frameworks, and code libraries that handle much of the coding for you. They’ve become so common that the system software for most every desktop and laptop computer includes several of these, built in.

How Most Web Applications Work

Today’s web applications are much more advanced than CGI, but they still work similarly, in these rough steps.

The applications are hosted on a server.
A visitor navigates to a page in her browser.
The application starts.
The application checks what page was requested.
The application generates an HTML document and sends that document back to the visitor.
The HLML document is shown inside the visitor’s browser.

All of this happens in less than a second, ideally.

Eliminates Manual Coding

There are benefits to using backend web applications. But the main one is this: Having a backend application means that you don’t need to hand code every HTML page. At its core, all that a web application does is convert a set of inputs from the browser into an HTML page.

How these inputs are converted is the interesting part. There are a diverse and near infinite number of ways that data can be converted. Here are a couple of practical examples.

Creating an HTML page with dynamic content based on the server environment. In this scenario, the HTML page is created based on the environment that it’s running in. For example, the following Ruby program would generate an HTML page that has today’s year in the footer. Running it three years in the future would automatically create a different version of the HTML seen today.

Notice that the web application code (Ruby) is on top and the HTML template is on the bottom. The only dynamic part is the line in the template for the copyright date.

require 'sinatra'

get '/' do
  erb :index
end

__END__

@@ index

<html>
  <body>
    <header>
      <nav>
        <a href="/">Home</a> |
        <a href="/new">New Products</a> |
        <a href="/all">All Products</a> |
        <a href="/cart">Cart</a>
      </nav>
    </header>
    <section>
      <h1>World's Best Product</h1>
    </section>
    <footer>
      <nav>
        <a href="/">Home</a> |
        <a href="/about">About us</a> |
        <a href="/contact">Contact us</a>
      </nav>
      <p>Copyright <%= Date.today.year %></p>
    </footer>
  <body>
</html>

—

The HTML template produces the copyright date, which is dynamic and automatically changes.

—

Creating a HTML page with dynamic content based on a database. Another popular technique is to generate the HTML based on data in a separate system. Typically this is a database, which can hold millions of sets of data.

For example, ecommerce stores do not have, say, 1,000 different HTML templates, one for each product. They likely have a database with all 1,000 products. The web application generates a product page for each using a standard template.

The example below shows that. It’s a web application that connects to a database and generates a unique page for each product. There are two products in this example — “Toy car” and “Puzzle” — but it would work the same with 100,000 products.

require 'sinatra'
require 'active_record'

# Setup the database
ActiveRecord::Base.establish_connection(YAML::load(File.read("database.yml")))
ActiveRecord::Schema.define do
  create_table :products do |table|
    table.column :name, :string
    table.column :price, :decimal
    table.column :description, :text
  end unless table_exists? :products
end

class Product < ActiveRecord::Base
end

# Create a product for the example
Product.create(name: 'Toy car', price: 9.99, description: "This little red toy car would be fun for any child to play with")
Product.create(name: 'Puzzle', price: 19.99, description: "You will love this 500 piece puzzle of random colors")

get '/:product_id' do
  @product = Product.find(params[:product_id])
  erb :index
end

__END__

@@ index

<html>
  <body>
    <header>
      <nav>
        <a href="/">Home</a> |
        <a href="/new">New Products</a> |
        <a href="/all">All Products</a> |
        <a href="/cart">Cart</a>
      </nav>
    </header>
    <section>
      <h1><%= @product.name %></h1>
      <p>$<%= @product.price %></p>
      <p><%= @product.description %></p>
    </section>
    <footer>
      <nav>
        <a href="/">Home</a> |
        <a href="/about">About us</a> |
        <a href="/contact">Contact us</a>
      </nav>
      <p>Copyright <%= Date.today.year %></p>
    </footer>
  <body>
</html>

—

This hypothetical product page for a toy car is a template. The contents of the page — product name, price, description — come from a database.

—

The layout of this product page for a puzzle is the same as the toy car. The difference is the content — product name, price, description — which, again, comes from a database.

The layout of this product page for a puzzle is the same as the toy car. The difference is the content — product name, price, description — that, again, comes from a database.

—

Generated Pages Can be Easier

There are many options when using a web application to generate your HTML pages.

As mentioned, you don’t have to hand-code every page. Instead, there’s likely an administrative interface to manage the data — i.e., to add and change products.

Also, you can have site-wide templates. You can reuse common elements on each page (footer, header) and have a common layout for, say, product pages. When you change the layout of a product page, likely all product pages will change automatically.

Using a database and generating the pages dynamically separates each technology. Now you have:

HTML for the page structure;
CSS for the page’s presentation and appearance;
JavaScript for the page’s interactivity;
Database for the actual content;
Web application to glue everything together.

Disadvantages with Custom Applications

Custom web applications have disadvantages, too. Since it’s a program, you’ll likely need a developer to make changes. Sometimes the changes are easy; sometimes not.

Another disadvantage is that once you choose a language or framework to build a custom site in, you’re typically committing to it for a while. It is possible to change, but the process is often time consuming and expensive.

Advantages to Custom, Partially-custom Applications

If you have am entirely custom web application powering your ecommerce site, it’s much easier to mix and match the technology. You can use hand-coded HTML pages for some parts and dynamic, application-generated pages for others. I often see, for example, landing pages and graphics-heavy pages that are hand coded. With a custom web application, you’re in full control, limited only by your imagination, budget, and timeline.

If you use an ecommerce platform like Shopify or Magento, you can build your own custom plugin or extension to the platform using its API. That is an increasingly viable option for companies that want to use a specific platform but still need to customize, say, 10 percent of it. You’ll end up with two web applications: one for the platform and one for the customization.