Week 6 Notes

#Working on the Server Side In week one, we experimented with some bare bones Servi projects using simple routing, just to get a sense of how to build a simple server. In week two, our servers became even simpler, as they were designed to take care of one concern: serving static HTML, CSS, and client-side Javascript files.

So far in this course, we've been mostly concerned with what happens once things are loaded in the browser. This week, we're going to focus on what we can do before our pages even get to the browser. The server will read the browser's request and decide what to send back based on the info it gets. We saw the beginnings of this in week one's Servi routing exercises -- see the week 1 gist files for a refresher.

A Hypothetical Example

Imagine that we're building a social network site in which every user has a profile page. We might decide the path to any user's profile is mysite.com/profile/USERNAME, where "USERNAME" is a particular person's username. For example, my profile URL might be mysite.com/profile/robyn, and Shawn's URL could be mysite.com/profile/shawn. Without server side programming, we'd have to build a separate HTML page for each user: if we wanted 2 pages, we'd have to create them each by hand and upload them: robyn.html and shawn.html. The two pages would likely look exactly the same, except that one would have Shawn's information and one would have mine. With server-side programming, we can make just one HTML page and then fill in the content based on which profile a browser requests.

With Node and Servi on server side, we're going to intercept the request, decide what to send to the user based on the request, and then send back a response. Once it gets to the browser, it will look like any other HTML/CSS/Javascript page, just as if we'd created robyn.html and uploaded it to the server. The difference is, the page is created programmatically, and we don't have to laboriously create each page by hand.

---

Review: Tools and Workflow

When we were just serving static files from our node server (the server.js file), we just started the server once and uploaded any new code to the public folder. Now that we're back with node and servi, we will have to restart the server when we make changes to the node (server-side) Javascript.

As a reminder, here's what your toolset and workflow might look like:

Locally, on your computer

1. Text editor (Sublime or other), where you write the Javascript. For example, you might create a file called server.js.
2. Terminal, where you run the javascript using node. For example: node server.js
3. A browser, where you test the server. For example, if your server.js script runs a server on port 3000, you'd check the URL http://localhost:3000 in your browser.

Once you get things running on your computer, you'll then upload your javascript to Digital Ocean and run it there. You'll also use the terminal to run the script there, but you'll need to log in to your Digital Ocean server with ssh first. The workflow looks like this:

Remotely, on your Digital Ocean server

1. Using Cyberduck, upload your Javascript file (server.js or whatever you named it) to your Digital Ocean droplet. You can put it anywhere you like, but for organization's sake, you may want to create separate folders for separate projects, for example, mySocialNetworkServer/server.js or testServerNov15/server.js.

Note that your new project may also have a public folder. Don't confuse the client-side code in public with the server side server.js (or whatever you name it) file.

1. In Terminal, ssh to your droplet (as described here ) and navigate to the directory that contains your Javascript file -- server.js or whatever you named it.

   Run node NAME_OF_YOUR_JAVASCRIPT_FILE.js. Servi will tell you which port it is running on. If you did not set a port explicitly, it will usually be port 3000. Once you have it working like you want, you can run it with forever instead, as we've discussed in class and is documented on this wiki here.

2. Test in the browser, just as you did locally. This time, instead of localhost, you'll go to your IP address. For example, http://123.456.78:3000

---

Doing More with Servi

In week one, we covered the first section, about routing, of the Using Servi.js page. Now we'll move on to more things we can do with Servi, like processing forms, using a databases, and templating. Please Read and try the examples on Using Servi.js.