Don't like this style? Click here to change it! blue.css

Class 13: Data-driven Apps

Websites are actually just thin database wrappers.

Interesting sites typically allow users to digest interesting data, interact with that data, react to it, make changes to it, and share the data with others (and themselves in the future).

Now this course is primarily focused on client-side technology and between this, advanced web technologies, and databases you should be pretty good at making interesting data-driven user experiences. Your fourth project will ask you to create data and display that data in various ways. So I'm going to take a 1-2 class foray into server-side tech as it pertains to client-side apps.

The AJAX Revolution

The .com bubble of the late 90s was because we were finally able to make dynamic web pages, taking data from users, saving it, and sending them to sites custom built from that data. CGI and PHP were the life blood of that economic expansion. It didn't stick. One reason was that the companies needed massive computing power to service millions of people, and even then they couldn't react fast enough to keep customers engaged. Those technologies ran scripts on the server which would generate a static page that got served to the user. Then when the user wanted to update a page with new data they would have to load an entirely new page from scratch. This cost the users a lot of time and the servers a lot of load.

G-mail changed all of that by doing HTTP requests without reloading your page. When this caught on and was codified the tech became known as AJAX (Asynchronous Javascript and XML)

As coders and companies adopted this practice we had the second web revolution and many great companies were born.

HTTP in a nutshell

Every time you type in a URL a request is made from your browser to load a resource on some server somewhere (URL stands for Uniform Resource Locator). The request is passed from server to server narrowing scope until the specific computer responsible for that resource can react to the request.

HTTP requests look like this:


GET /index.html HTTP/1.1
Host: css.prof.ninja
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Firefox/38.0

An HTTP response might look like this:

  
    HTTP/1.1 200 OK
    Server: nginx
    Date: Mon, 25 Jan 2016 01:02:52 GMT
    Content-Type: text/html
    Transfer-Encoding: chunked
    Connection: keep-alive
    Vary: Accept-Encoding
    Last-Modified: Thu, 11 Jun 2015 19:37:29 GMT
    ETag: W/"2ed6-518431f351040"
    Content-Encoding: gzip
    Content-Length: 1234

    <!doctype html>
    <html>
      …

HTTP requests typically have a "verb" like: GET, POST, PUT, DELETE. Sometimes the HTTP request also has a payload of key/value pairs of data to give to the server.

Play with HTTP Task 1: Use your console to monitor some HTTP requests you make using: http://js.prof.ninja/ajax_app/

Making requests for/with the latest data without triggering a page reload is the heart of modern web tech. Fetch some JSON using a GET request and these simple, unauthenticated public APIs:

Bechdel Test Comic

Bechdel Test Task 2: Use http://bechdeltest.com/api/v1/getMoviesByTitle?title=moviewordhere to lookup the Bechdel score for movies. Their API is documented here: http://bechdeltest.com/api/v1/doc

Roundhouse Kick

Opposite Task 3: Now fetch a random chuck norris joke using http://api.icndb.com/jokes/random. The API is documented here: http://www.icndb.com/api/

Building Web Apps around APIs

Almost every web app you play with has some AJAX request or another going on. Some libraries wrap these requests in simple to use functions. The vanilla version is a little verbose… sorry.

Here is the XMLHttpRequest Living Standard documentation!. The name of this wonderful technology is stupid and historical, sometimes you'll see XHR written instead because that at least looks cooler.

Here is a sample AJAX request:

JS Bin on jsbin.com

For today the API is one I have set up on cloud9 (it won't work once that server goes down but you can setup your own (in 3 tasks) ). The code for that setup is this:

Build the web Task 3: Build a website that lets a user click to receive a new Chuck Norris joke. (If that was too easy look at the API and give them some filters/options.)

Build the web Task 4: Build a website that lets a user check the Bechdel score of a movie they are interested in. You'll need to URL escape characters.

Saving Data (the easy way)

So for this course we're not diving into the server-side as deeply as I expect CISC474 to. However, you are still expected to build interesting sites around dynamic user content which gets Created, Read, Updated, and Destroyed (CRUD). So I'm going to give you a quick backend tool that will do the job for us.

This is not a transcendent principle of CS, this is a patch to let you work with some transcendent demands of your future (dynamic data-driven documents).

Firebase

This is a quick service to let you have an instant CRUD API without needed to deal with setting up a server of your own (which is fun and you should do it anyway). If you want to see a previous take on this check out: http://db.prof.ninja/class13/.

Firebase Task 5: Head to Firebase.com and setup an account and a free app.

Read Task 6: Go to your App's dashboard, and edit the app's data to have a key/value pair, e.g. author: "Andy".

JS Firebase Task 7: Include <script src="https://cdn.firebase.com/js/client/2.4.0/firebase.js"></script> (or the latest version if you are in the future already.)

Snapshot Task 8: Add the following to your javascript: 
  
    var myDB = new Firebase('https://YourAppsName.firebaseio.com/');
    myDB.on("value", function(snapshot){
      var theData = snapshot.val();
      document.body.innerHTML = JSON.stringify(theData);
    });

You should now have something a little like this:

See the Pen Firebase Example by Andy Novocin (@AndyNovo) on CodePen.

Save Data Task 9: You can use yourDB.set(JSONHERE) to create or update data in your database. Create a button, event listener, and function to set a key/value pair in your database which updates to the currentTime.

So now it might look something like this:

See the Pen Firebase Example by Andy Novocin (@AndyNovo) on CodePen.

You'll notice that the data is still there the next time you refresh the page and your neighbors would see the most recent button press.

Web Data Task 10: Send your URL into the chat. Have a friend visit your site while you visit theirs. Click the button and see that it changes on the other person's screen dynamically!

Let's talk about what has happened now.

Universal Click Counter 11: Adjust the code so that your database stores the number of times any user has clicked your button. That means read the old value and update it whenever a click happens. (For concurrency issues check out the Firebase API's transaction function .)