Random insights on Ruby Magic, learnt using express.

Here’s some random thoughts strung together in no particular order.

Tinus Wagner

Throughout the last two years I’ve been a full-stack developer in the world of Ruby on Rails. I’ve dabbled in many front-end JS frameworks and tools. And sincerely grown to love JS in all it’s shapes and flavours. But even with the huge popularity of Node.js, I’ve never really given it a shot.

There’s a couple of reasons I dug in:

  1. To see what options are available to me outside of the Rails world, and how they compare.
  2. It’s an opportunity to take a look at the noSQL world that seems to play so nicely with Node.js.
  3. See what JS can really do in the backend world and how it stacks up to the wonderful experience that is Ruby on Rails development.

Getting started

I already had MongoDB & NodeJS (via NVM) installed so it was just a matter of updating them.

I did spend a bit of time looking around for a decent GUI for mongoDB but in the end I settled for the first option that I came across. MongoDB Compass seems to come highly recommended by the community, and while I have zero experience with it, as a frequent pgAdmin user I personally like the UI so far.

Make sure you grab the community edition :)

Now simply open a terminal window and run mongod . Once mongo’s up and running simply connect Compass to localhost and port specified by mongo.

Express — My first impressions

Now I’ve set up simple little servers before with express, but I’ve never really dealt with HOW the request/response cycle is laid out on a large scale, and I’m truly shocked by how simple it is to operate, especially once middleware like body-parser starts playing a part.

Take the following for instance:

const express = require('express');
const router = express.Router();
router.get('/', (req, res) => {

Sending a request tolocalhost:port allows you to immediately send a response using send but it’s capable of so much more. If you were to string params onto the string localhost:port/?name='dude'&age='100' is easily accessible using req.query . Something that in the rails world I’d only really be able to grab onto from within the controller.

Similarly I can deal with variables in the url string quite simply by accessing the params of the request. The cool and flexible thing here is that since it’s just a regular JS function, you can grab these params and use them to manipulate your routing response. Completely independent of your controller.

router.get('/reverse/:name', (req, res) => {
const reverse = [...req.params.name].reverse().join('')

Similarly I can with immediately respond with JSON using res.json {pew: 'pew', meow: 'mew'} , and none of this is reliant on a controller to work!

Now all this is quite cool to me, in a rails application I’d have to define the route first, then a controller, and then define an action for that url before I’d be able to do these small menial things. Only then would I be able to inspect a query, manipulate params or serve up a JSON response.

router.get('/', (req, res) => {
res.render('hello', { myRelevantHashOfStuff });

It’s not mind blowing or beyond comprehension, but I like the initial options express provides here for some very flexible routing logic.

Diving into express really starts to show you how much *rails magic* is occurring when a route is defined. So generally in a rails application you’d do the following to pass params via a url:

config/routes.rbRails.application.routes.draw do
resources :my_resource

Which will magically give you access to every verb possible.

Then you’d create a controller

app/controllers/my_resources_controllerclass MyResourcesController < ActionController::Base  def my_verb
...do something

Now since this controller inherits from ActionController::Base, simply hitting that url with some random parameters and inspecting the request will show that you have a bunch of parameters that are available in a sensical way. All this just happens.

Now once you set up an express route for that url and hit it with random params, not much useful will happen until you add some middleware such as a bodyParser. Similarly setting header content or perhaps adding a cookie to the response requires other middleware.

In the world of rails someone has made these decisions for you based on what you’d probably need. And 90% of the time they are right. The benefit of these sensible defaults is a very quick rate of initial development, but once things get more complicated it does limit your flexibility, or worse you start having to override default behaviour in ways you don’t fully comprehend, that have potential repercussions you may not have imagined.

A lot of these sensible defaults hide a substantial amount of complexity. And it’s a major gripe for some people since it makes rails development noob friendly. It’s a form of conceptual compression and there is nothing wrong with that!

Interest will lead to exploration and eventually newcomers will start picking apart the pieces that peak their interest, but at least they won’t be alienated from joining the industry.

Thanks for reading!

Tinus Wagner

Written by

Developer, Producer, Drummer, Synth lover.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade