Overview of a full-stack Javascript site, part 1

So, capstone projects have started at Portland Code School. Our task is to figure out a web app we want to build, and then to build it. We have to include client-side, server-side, and database code—the whole nine yards. We’ve got a pretty good idea of what we’ll be building in my group, but it’s not time for spoilers just yet. Instead, I’ll be talking about the basics of a full-stack JavaScript site and going over the bits and pieces that we use and how they tie together. This is, of course, at least half for my benefit—it’s like talking out loud about a problem. So if you spot any glaring errors or misconceptions, do me a favor and point them out!

There are three parts to a site—or at least, to the sort of site we’ll be building: the client, the server, and the database. I’ll go over each of those sections and talk about the libraries and frameworks we use in them, and what they do.

The Server

Might as well begin at the beginning! The server is the most basic part of the site; without client-side scripting or a database, you can still have a webpage that has information on it and does stuff, but without a server, you’ve got nothing but a browser, and maybe a 404 error. The server is the software that responds to requests from the outside world. When you build a server, you define things like what port the server is listening for signals on, what information is sent out when someone makes a GET request at a particular path with a particular query, where information goes when a user wants to PUT it somewhere, and all that good kind of stuff.
Building servers in JavaScript is pretty new, and it’s done with node.js. You could conceivably make a super-simple server with node that does nothing but serve up static html pages, or you can get a lot more complicated. For our capstone, of course, super-simple is not an option. You may remember me mentioning node.js earlier, and how it’s occasionally kind of mind-bending. Well, that continues to be true, especially if you squint at it too hard, but there are a lot of libraries and modules out there to make things easier.
One of the main node modules that we use is Express. Express basically takes what you can do with node and cleans it up, tightens up some syntax, predefines some stuff, and generally makes things quicker and easier to work with—assuming you know how to use it, ’cause the documentation for Express is terribad.
The next important chunks of code that we use on the server are Consolidate and Handlebars. These two are very closely related. Consolidate is basically an interface layer for templating modules—that is, it’s a translator that lets a bunch of different template engines talk to Express in a way that Express understands. So what are templating engines? They let you generate html quickly and easily on the fly, basically. Your pages start to look like this example from the Handlebars page:

The title and body would then get filled in automatically by whatever the server generates in response to the client’s request. The name Handlebars comes from the way the curly braces look like little moustaches on their sides, apparently. Being in Portland, hipster capital of the universe, this doesn’t really surprise me, but it does make me shake my head and sigh.

There are a few other node modules—oh yes, I should mention node modules. Well, unlike vanilla javaScript, node has prepackaged modules that you can require that let your server do all sorts of neat things, like templating or accessing the file system or whatnot. They’re basically the equivalent of Ruby gems. Super handy. Anyway, there are a few other node modules we’ll be using, but they’re pretty straightforward:

  • fs: This lets us work with the file system. It’s how we can do things like traverse directories and read files. Important, for sure, and a baked-in part of node.js.
  • path: kinda similar to fs, this lets us work with file paths. Like fs, it’s part of node.
  • body-parser: We use this for parsing JSON, which is a pretty popular data storage format
  • morgan: This is an error logger. Useful to have around, especially for development!

The Database

The next module we’ll talk about is called Orchestrate. It’s technicaly on the server, but everything it does it on the databse—itbasically the interface between server and database. Different databases use different modules, of course—we’re using Orchestrate, which is a pretty neat little database as a service outfit here in Portland. They offer a certain number of queries per month for free, and after that you have to start paying. Anyway, their Orchestrate module is the link between the server and the database.

This has gotten longer than I thought it would, though, so I think we’ll wrap up here for now, and save the discussion of client-side stuff for another day.

Leave a Reply

Your email address will not be published. Required fields are marked *