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>
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>
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;
- 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.