JS Questions: How are JSON Web Tokens Used?

This is the twelfth in a series of posts I’m writing that aims to provide concise, understandable answers to JavaScript-related questions, helping me better understand both foundational concepts and the changing landscape of language updates, frameworks, testing tools, etc.

How are JSON Web Tokens Used?

JSON web tokens (JWT) are a publicly-available system that enables secure transmissions between two parties. The technology is not JavaScript specific, but is useful in applications that must make verified requests to a server, such as a React front-end application requesting a user’s password-protected information through a fetch request.  The JWT does not authenticate a user, but rather sends along the information needed to verify that the client making the request has been authenticated.

JTWs are popular for a few reasons. First, of all, because the tokens require a server-side decryption, they can’t be easily manipulated by the user or a third party. They’re also compact (preventing a bloated post request) and self-contained, meaning they don’t require a followup request for data after the authentication is made.

Here’s how a JWT might be used alongside the user authentication process to allow a client to access their password-protected information:

  1. A user enters their login information and their credentials are posted to a server. Upon confirming that the user has entered the proper information, a JWT can be created.
  2.  The JWT has three parts: 

Header: The header contains indication that it is a JTW token, as well as the type of hashing algorithm used, both stored in JSON format. A hashing algorithm is a type of function used to encrypt and decrypt data.

This header is base64 encoded, meaning that its data is locked in a format that won’t be modified in the transmission process. 

Payload: Also formatted in JSON, the payload contains the data being sent. This is where information such as a user’s id or unique username may be stored. This section can also store the token’s expiration date. 

The resulting JSON is base64 encoded.

Signature: This takes the encoded header and payload, as well as the algorithm indicated in the header, and a generated secret to create a signature.

Finally, the token can be created in the correct format: three parts separated by dots: header.payload.signature

3. The created JWT token is sent back to the client in the request’s response.

4. The token is stored in the clients browser’s local storage so that it won’t be lost upon the page refreshing.

5. Every time the user requests information that is protected, the token is sent along in the header of the post request.

6. Each time the access token is sent with a request, it can be decoded using the secret stored in the server-side. No database query is needed to authenticate the request. The signature verifies that the token is coming from the right sender and that the data is not manipulated.

Note: I’ve referred to a secret key used to verify the token. The key like a password that can be used to unlock private information. Just like a password, it can be changed and should be stored in a secure place. The HMAC algorithm uses a secret to encode and decode. RSA is another algorithm that uses public and private keys. Either system can be used with JWT. 



JS Questions: What’s the Event Loop?

This is the eleventh in a series of posts I’m writing that aims to provide concise, understandable answers to JavaScript-related questions, helping me better understand both foundational concepts and the changing landscape of language updates, frameworks, testing tools, etc.

What’s the Event Loop?

Like any programming language, JavaScript has a specific process for handling function calls in a program, and more specifically, deciding when each function will run. Unlike other languages, JavaScript can be run in a browser, meaning that users may be interacting with the program by clicking a mouse or scrolling, for instance, simultaneous to other processes that are already running. The event loop helps create a fluid experience for users, by dictating a flow that allows for relatively long running processes to occur alongside client-side interactions.

Without features built into Node and browsers, JavaScript would only be able to handle one event at a time. Each function call would be added to a stack and one-by-one, popped off the top and run. It’s easy to imagine how this could become problematic in a web app. If a notice telling a user she had successfully updated her account were rendered to a webpage for three seconds using setTimeout, the user would not be able to interact with the page until the setTimeout had completed.

Some events do happen synchronously in JS. Loops will run in the call stack and prevent a webpage from re-rendering until they have completed.

However, due to the event loop built into browsers, processes such as AJAX requests and timeouts can run in the background, with their callback functions placed in a queue that are added to the call stack only when the entire stack has cleared. The below code snippet illustrates this.

If you paste this in your console, you’ll see 1 logged, then 2 returned, then 3 logged. Here’s what happens:

  1. The eventLoop function gets added to the call stack.
  2. The setTimeout timer begins and the callback function is added to the queue after 0 milliseconds.
  3. The number 1 is immediately logged.
  4. The eventLoop function returns 2 and the call stack is cleared.
  5. The setTimeout callback runs, logging 3.

Note that the call stack runs functions in ‘first in last out’ order (meaning that the first function added to a stack is the last to run). That’s why, in the code below, the strings are already concatenated when logged:

First, the greet function is added to the call stack. Then, the concat function is added to the call stack. Concat runs, the greeting is logged, and the greet function is cleared from the stack.

Meanwhile, the queue runs callback functions in ‘first in first out’ order. The first item added to the queue is the first to be added to the call stack. That means, if multiple AJAX requests are made, for instance, the first request to finish will be the first to have its callback function run.

Overall, the event loop in JavaScript refers to the synchronous and asynchronous flow dictated by the call stack and queue in browsers.



Building a Blog with PDF Uploader in Rails 5


Build a blogging feature for use on a nonprofit corporation website. Implement create, read, update, and delete actions for the blog, which will be used to make public announcements with PDFs attached.



Within an existing Rails 5 app, use the Trix gem and the Paperclip gem along with basic Rails features to build CRUD actions for a blog post.


Add gems to the gemfile and run bundle

  1. gem "paperclip","~> 5.0.0"
  2. gem 'trix'

Follow Paperclip install instructions

For Mac OS X, I did:

  1. Install an image processor: brew install imagemagick.
  2. Because I want PDF uploads, I also needed Ghostscript:
    brew install gs

Follow Trix install instructions

  1. In the application stylesheet (a css or scss file in the assets directory), paste
    *= require trix
  2. In the application.js file (also in the assets directory), paste //= require trix

Create relationships and validations in models

I created validations for a post to have a title and content. Paperclip also has a validation for an document’s content type, as well as a required has_attached_file method, where specifications can be added such as the file’s width and height (more likely used for an image than a PDF).
class Post < ApplicationRecord

belongs_to :user
validates :title, presence: true
validates :content, presence: true
has_attached_file :document
validates_attachment_content_type :document, :content_type => ['application/pdf']


class User < ApplicationRecord

has_many :posts



I generated a migration for posts and later ran a Paperclip migration. The Paperclip migration gives a datatype of attachment, which is reflected in the schema after the migration has been run with four new columns: the attachment name, content type, file size, and time of update. (This can also be run as one migration. Check out the Paperclip documentation.)

  1. rails generate migration CreatePosts title:string user_id:integer content:text
  2. rails generate paperclip post document


I want full CRUD actions for my users and posts, so I used Rails resources.

resources :users
resources :posts


I haven’t included my entire posts controller, but as an example, here’s the create controller action with strong params. Check out my github repository to see all of my controller actions.

class PostsController < ApplicationController

def create
@post = Post.new(post_params)
@post.user = current_user
# current_user is a method defined in the Application Controller
if @post.save
flash[:notice] = "Post published!"
redirect_to :users
flash[:notice] = "posts must have a title and content"
render 'new'


def post_params
params.require(:post).permit(:title, :content, :document)



To add a Trix text editor in my post new and post edit view, I simply used Trix’s built-in method, which can be used with Rails form_for.

The Paperclip attachment is equally easy to implement with form_for using the file_field method.

New Post Form

<%= form_for @post do |f| %>
<%= f.label :title %>
<%= f.text_field :title %>

<%= f.label :content %>
<%= f.trix_editor :content %>

<%= f.label :document %>
<%= f.file_field :document %>

<%= f.submit 'submit', :class => "waves-effect waves-light amber lighten-1 white-text btn" %>
<% end %>

Post Show Page

When rendering the post content, I used the Rails sanitize method in order to safely render user input. Sanitize removes any non-whitelisted content from the html.

<%= @post.title %>
<%= link_to @post.upload_attachment_file_name, @post.upload_attachment.url %>
<%= sanitize @post.content %>


While I’ve removed some unnecessary code for simplicity and readability, these steps include everything needed to create a functioning blog feature. Check out my github repository to see the full project.


Rails Nested Forms: Collection Checkboxes

I recently figured out a couple tricks for using collection check boxes in a Rails 5 project with Materialize styling.

My goal: Have users check or uncheck programs associated with a classroom. A classroom can have many programs, so I used the Rails collection checkboxes form helper to allow multiple selections.

Implementation: The collection checkboxes form helper generates a labelled checkbox for each item in a collection.

Above, the first argument of collection checkboxes is :program_ids. This represents the method, program_ids, available on each classroom instance. It also will be the name of the key I can access in my params which has the value of all selected program ids.

I passed in @programs as the second argument, which is the collection of programs pulled from my database in my Classrooms controller.

The third argument, :id, refers to the data that will be passed into my params. In this case, I’m going to send the program ids, so that in my Classrooms controller, I can find programs by id in my database.

The final argument, :title, refers to the program’s title, which will be used to label each checkbox so the user will know which program they’re checking or unchecking.

When I added this code to my form, my checkboxes and labels were properly generated, but there was no spacing or formatting. I wanted each program to render on a new line, so I iterated through each program and added divs wrapping the checkbox and label.

When I first implemented the iteration, I had reversed the order of the checkbox and label, and my checkboxes were not appearing. I read a handy Stack Overflow post, which explained that the checkbox must appear before the label when using MaterializeCSS.

Next, I used strong params to access my array of checked programs, and update the classroom’s programs in my Classrooms controller’s update method. While I ultimately ended up refactoring my controller, this was my initial approach:

I used the delete_if method on line five, because the array of ids in my params included empty strings for unchecked boxes.

Refactor: I suspected that there was a more efficient way to update the classroom’s programs from my array of program ids in the Classrooms controller, since my original version involved two iterations and several database calls.

It turns out that I had made the job of updating my associations much more difficult for myself than necessary. In fact, I can simply pass the classroom’s update method my array of program ids, and it’ll take care of the rest:


JS Questions: What is Webpack?

This is the tenth in a series of posts I’m writing that aims to provide concise, understandable answers to JavaScript-related questions, helping me better understand both foundational concepts and the changing landscape of language updates, frameworks, testing tools, etc.

What is Webpack?

JavaScript-based applications have increasingly complex systems and interactions. They send and receive data; they create a user interface; they have non-JavaScript assets such as styling and images; and they incorporate outside packages of reusable code. The purpose of Webpack is to bring together all the disparate parts and turn them into one file, made readable to the browser rendering the application. This job is called module bundling. 

There are two types of ways that code is transformed in Webpack and these processes are handled by separate entities: loaders and plugins.

Loaders take in the application’s files, turn them into modules that can be read by a JavaScript engine, and add the modules to a dependency graph. A dependency graph is like a map (written in JS) showing how each module is related to other modules.

Different loaders can handle different tasks in the transformation process. The babel-loader, for example, takes in ES2015 (or later) code and transpiles the code to an earlier version of JS syntax.

While loaders create modules, plugins alter the modules to optimize them for computer processing, dependency injection, debugging, and other tasks. The UglifyJS plugin, for example, minifies code in order to make it run faster. 

When all dependencies have been added to the graph and all processes have been run, the static file is handed off to the browser to load.

Webpack can be configured with whichever loaders and plugins a project needs, though there’s also an ‘out-of-the-box’ option for React developers. React, a popular library for building JS front end, has community support for Webpack. The package, Create React App, can be used to generate files for a new React application preconfigured with Webpack. The Webpack-enabled functionality, including hot reloading (which adds, removes, or updates modules, without a page needing to fully reload) make it especially handy.

Other module bundlers exist (Browserify is considered the first of its kind), but Webpack has become an industry favorite.



JS Questions: What is Node.js?

This is the ninth in a series of posts I’m writing that aims to provide concise, understandable answers to JavaScript-related questions, helping me better understand both foundational concepts and the changing landscape of language updates, frameworks, testing tools, etc.

What is Node.js?

Unlike Ruby (and many other programming languages), JavaScript wasn’t built to be executed outside of the browser. A Ruby program can be run by simply typing the path to the file to be run prepended by ‘ruby’ in terminal:

ruby filename.rb

Node.js (also called simply Node), which is built on the Chrome V8 JavaScript Engine, can be used to run JavaScript code outside of the browser. To try it, download Node and run the Javascript file from terminal:

node filename.js

Nodejs.org refers to Node as a runtime. Runtime environments dictate how a program is executed. All runtime environments have an event loop, or set of instructions how a programming language handles incoming events and dispatches them.

A ‘non-blocking I/O model’ differentiates Node from other runtime environments. Input and output (I/O) refers to the interaction between the processing system and user or other input making a request. A user clicks their mouse, for example, and the server returns requested data rendered in the browser.

In contrast to a non-blocking model, a blocking I/O is one in which JS code cannot run until the previous operation is complete. In other words, the event loop pauses until the process finishes. Node allows asynchronous, non-blocking events to occur, meaning that a process doesn’t need to finish in order for another to start. This allows an application to handle frequent incoming requests with minimal downtime.

Node is widely used to make server-side applications. The server side of an app takes in requests and responds with data to the front end of the application. This allows requests to create, update, or delete data to be persisted in a database, as well as for information to be accessed from the database and rendered in the front end.

Scalability, low latency, and high bandwith are often noted as key benefits of using Node over other server-side options, due to its non-blocking I/O. More information about how Node works as compared to Ruby’s Event Machine, for example, is available on nodejs.org.  There’s also a ‘hello world’ example for creating a server with Node and hosting it on a port.

Node also has a popular JavaScript package manager, npm, which allows developers to install JavaScript packages, pieces of software made available to developers to download and use with their own projects. Some commonly downloaded JS packages include express, react, and babel-core.

“Node’s package manager, npm, has transformed from hosting utility modules for server-side apps to the canonical place to store distributable JavaScript code.” –The future of Javascript in 2017 and Beyond

Finally, node is also open source and has a community of contributors.




JS Questions: What’s a JavaScript Engine?

This is the eighth in a series of posts I’m writing that aims to provide concise, understandable answers to JavaScript-related questions, helping me better understand both foundational concepts and the changing landscape of language updates, frameworks, testing tools, etc.

What’s a JavaScript Engine?

JS engines interpret and execute JavaScript code, usually for a web browser (since JS is commonly used for web development). They are written in lower-level languages such as C++ and C.

An engine must receive the specific version of JavaScript that it has been built to interpret. (There are several versions of JavaScript, as the language becomes updated and optimized for development. The most recent version is ES2017, which can be transpiled to an earlier version of JS in order to be run by a JS engine.)

Browsers have an increasing need to efficiently interpret JS code, because web applications more heavily rely on Javascript, not just to run a few scripts, but as their framework language. While popular modern browsers all have JS engines, there’s still a lot of competition among them to have the fastest engine that can generate the most optimized code.

Examples of JS Engines

  • V8 (Chrome)
  • Spidermonkey (Mozilla)
  • JavaScript Core (Safari)
  • Chakra (IE)