Webapps

I've created web apps using a couple of different languages.

My first introduction to web apps was through PHP, a dynamic, server-side web programming language. I use PHP for running web apps that other people have written, like MediaWiki and Wordpress. I occasionally use it for my website.

The way I usually develop web apps is using a combination of Python and Javascript, or just plain Javascript. If the web app is doing something complicated, I'll use Python; otherwise, I can usually get the job done in Javascript.

Below are some basic concepts about web apps that'll be useful to know.

Servers and Clients

Server-Side vs Client-Side

The biggest decision to make, when designing a web app, is deciding what tasks will be run by the client, and what tasks (if any) will be run by the server.

Let me explain.

Your typical webapp consists of two parties: the client, the end user of the webapp, and the server, the provider of the webapp.

Most typically, you're using the HTTP protocol - that's why it's a WEB app. Using that HTTP protocol, you can send requests and information back and forth between the server and client. HTTP is a COMMON protocol, meaning you can turn data and variables in Python or Javascript into HTTP information, and vice-versa. This allows the client and server, running the two sides of the webapp, to communicate.

Deciding on whether to run parts of a web app on the client or on the server can have big implications for the complexity and speed of your webapp. If code runs only on the client side, it will be very fast, and all your server has to do is send some files, which means your server won't get bogged down as more users try and use the webapp.

But client-side-only web apps are pretty boring (unless you're into playing games). Much more interesting is the case of server-side applications. These might involve looking up data in a database or performing calculations. It might involve grabbing information from a sensor, or sending information to and from a microcontroller. There are many more interesting remote applications (at least, in my mind).

Python vs Javscript

We've seen that the main concern when designing a web app is location: client or remote side. This also has implications for the languages that we can use.

Javascript is designed as a client-side language, since it runs in the browser (although it can be hacked so you can use it as a server side language). Python, on the other hand, does not run in the browser, so it lacks the portability of Javascript. But Python has enormous power and an amazing selection of libraries, making it a great do-anything language:

A Simple Example

Let's make all this abstract stuff a little more concrete with a simple example.

Open this webapp in a new window: http://charlesreid1.github.io/a-shrubbery/educationca/

You'll see something like this:

This is a simple client-side web app that visualizes map-related data. It is hosted on GitHub pages, which means that the server, in this case, is a server at GitHub's data center. The client is you - or, more specifically, your browser.

When you open a regular HTML website in your browser, your browser sends a request for that page to the server (the protocol for that request is HTTP). The server sees the request, and returns the HTML for that page to your browser, which then renders it and shows it to you.

When you open a web app that has client-side Javascript in your browser, your browser sends a request to the server, as before. The server returns the HTML for that page, plus the Javascript code to execute. That HTML is rendered, and that Javascript is executed, and the end result is a client-side, dynamic website.

When we request a Javascript web app, the process looks exactly the same, except now the returned page includes a bundle of Javascript code, which the browser will execute in addition to displaying the HTML.

Let's take a look at what the server is sending the client.

Here, we take a peek into what the server is sending as a response, and we can see HTML and Javascript files. These are executed by the browser to create the web app for the user.

The main HTML page contains the necessary material for a webpage: the white background, the header, the navigation bar, etc. The dynamic web app in our Javascript file provides the code for the web app. It references several other files, such as a file with Javascript code for drawing data on a map, and a file with Javascript code for drawing charts displaying map data. These, in turn, refer to other Javascript files, or to data files. The server sends along everything that the web app specifies is needed for the initial request.

If we are drawing data from a large database on the server side, the data that is initially sent is just a small, initial bundle of data - like the first place you see when you open Google Maps. As the client interacts with the map, and requests different information, that Javascript code will ask the server for additional data.

Protocols

When two computers talk to each other, there is a thick sandwich of protocols that make that communication possible. These include multiple network protocols and web protocols. And sitting right on top of that thick sandwich is the HTTP protocol, which is the primary protocol used by the internet.

First, what kind of things are the client and server communicating? The client communicates things like "Can I have charlesreid1.com?" and "Can I have this piece of data from the database?" The server will communicate things like, "Here are all the files required for charlesreid1.com," or "Here is the piece of information you requested from the database."

There are two kinds of requests that a browser will send a request to an HTTP web server: a GET request, and a POST request.

GET

Think of GET requests as a very simple set of key-value pairs. These key-value pairs are actually encoded directly into the URL, so if I request a page like:

http://charlesreid1.com/page.html

then i can send along a key-value pair dictionary by adding them to the URL that I type in my browser:

http://charlesreid1.com/page.html?variable1=bananas&variable2=apples

Now the code on page.html can use these GET variables.

GET variables are used to encode simple information, like "Look at page 5," in the URL. But as the amount of information in a request gets more complex, GET doesn't work so well.

POST

The GET method obviously isn't scalable for anything but simple information. For everything else, there's POST. POST requests are sent to the server silently, behind the scenes. This allows POST to be used to transfer large amounts of data.

Combined with a format for serializing data (i.e., turning a chunk of data into a stream), POST can be used to send arbitrary data between a server and a client.

POST JSON

Enter JSON - Javascript Serial Object Notation. This is a way of taking Javascript objects (a dictionary for all you Python people out there, a Javascript object is a Python dictionary) and serializing them. A simple example of JSON looks like this:

{
    "variable1" : "bananas",
    "variable2" : "apples"
}

These can also be nested, and include arrays, or lists, of values:

{
    "variable1" : {
         "fruit" : "bananas",
        "possible attacks" : ["killer bee banana attack","hidden banana peel death-squeeze"]
    },
    "variable2" : {
        "fruit" : "apples",
        "possible attacks" : ["the choker","death from above"]
    }
}

APIs

While it's possible to implement GET and POST requests in a webapp, sometimes you want the best of both worlds. It isn't always convenient to wrap a bunch of functionality into the right function calls for the right POST request with the right headers.

You want something easy. Something simple. Something like:

http://charlesreid1.com/data/get/my_favorite_dataset

and in a perfect world, this would translate into a command to the server: "I need something from a data set! I need to get a dataset! I need to get my_favorite_dataset!" We could incorporate this into a web app a number of different ways. One way would be to turn actions (like, go to the next map page) into database requests ("I need something from a map dataset! I need page 15!"). Another way would be to make the components of a webapp itself available at different URLs, so that as the user proceeds through the web app and makes different choices, they are guided along different routes with different URL paths.

In fact, we can do all of this!

This type of API, using a URL to make requests, is called a RESTful API (or sometimes a SOAP API). This just means that we're turning a request for a webpage into a request for some generic resource.

And while this makes it easier for us to use on the front end, the real power comes from the back end. We can use Python to link a particular URL request to chunks of Python code. This means, anything we can do with Python, we can do with a REST API! That's huuuuge!

The API Front End

We talked about the API front end: it basically consists of URLs that the user requests. How this looks in practice depends on how you've implemented the API. But most of the time, you aren't building the API URLs for users to access directly. Most of the time, if a computer requests that URL, the server will return something that isn't human-readable, like JSON or XML.

Building an API

While entire books have been written on the subject of how to write an API, I'm only going to cover some embarrassingly simple APIs.

I use Python Flask to build APIs.

See Flask page.