In thinking of projects that could help me learn Node, I was reminded of Avi’s maxim that you’re generally better off building your own project (and thus, solving your own problems) than building someone else’s. And given that there are countless tutorials on how to build a blog using X, Y or Z framework, I don’t think I could be engaged in learning Node just by building a blog that I don’t really care about.
Those who know me know that I’m a big football fan. I played two years in high school as a strong safety, and I’ve played intramural football in NYC since I moved here in 2010 (with a recent hiatus to spend time focused on my career shift from finance to technology). Hailing from Chicago, I grew up watching the Bears - names like David Terrell, Anthony Thomas and Shane Matthews still bring a cringed look to my face as I recall the painful memories of so many wasted seasons (except for the 2006-2007 Super Bowl season - that was a fun ride). Thankfully, it looks like the addition of Marc Trestman, the Cutler-Marshall connection and the emergence of Alshon Jeffrey as a viable second receiver seems to be moving the Bears in the right direction offensively, even if the defense continues its rebuilding phase in the post-Urlacher era.
But I digress. Like many football fans, I’m involved in a few fantasy football leagues that require me to set lineups, add/drop players and attempt trades if I have any hope of getting to the playoffs. My general process is to check some player and matchup research on a weekly basis and make lineup changes accordingly, but that process can be a bit laborious, since I find myself performing this weekly ritual where I check player rankings, then cross-reference those against the available free agents and waiver wire players in my respective leagues.
Conceptually, this should be done programmatically. The data provided by the player rankings should feed an API search query against my fantasy football league database, so that I can get a report that shows who is available for me to pick-up in my league among the players that are ranked higher than those I currently have on my team (thus indicating a potential up-market action for me to take). At a more advanced level, I could expand this program to take in multiple ranking sources or look beyond the free agent market to suggest trade possibilities, but that’s all beyond the scope of the MVP, so to speak. I want to build an application that can take in data from my fantasy football leagues, mix that with research and analysis from an external site and build me an set of suggested actions that I can take to improve my team.
Mongoose (and MongoDB)
In this web stack, Mongoose serves as the application’s interface to Mongo - it provides structure and access to the database. Mongoose is similar to ActiveRecord in that you can make database reads and writes, but its specifically designed to work with a document-store database like MongoDB.
Jade is a HAML-like templating language that allows for logic structures like each loops and if statements to determine HTML structure. Jade syntax is incredibly terse and does not have closing tags and, much like HAML, indentation matters.
Stylus is SASS-like CSS preprocessor that is backwards-compatible with normal CSS. Mixins, variables and interpolation are all components of Stylus, which also emphasizes minimalist syntax (e.g., no curly braces).
There’s a number of solid Express/Node/Mongoose tutorials online, so I won’t reproduce what those blog posts have already done well. Here are a few of the best ones that I’ve come across:
Setting up the application was surprisingly simple, and the above tutorials do a great job of walking through the necessary steps (e.g., install node, install npm, set up Mongo, initiate an Express app). Taking my app beyond the basic tutorial, however, required me to set up a directory structure that could handle multiple models, controllers and routes. Given my familiarity with Rails, I tried to set up my application in a Rails-ian fashion, with an app folder that consists of sub-folders for my models, controllers and views. Here’s a few links that I found useful when setting up my Express file structure:
And so I set up my application like this:
The folders are pretty self-explanatory, and the package.json file acts as a Gemfile of sorts in that when you run the ‘npm install’, npm will install the relevant libraries so that you can use them in your application.
To actually run the application, I can run the command ‘node app.js’, which executes the app.js file:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68
The file starts by loading the module dependencies for use in the application. Then, it instantiates the application, sets up the database connection via Mongoose, configures the app to use an array of Express middleware modules and libraries and points the application to port 3000. Finally, app.js requires the files in the app folder to the application so that the router, models and controllers can be linked together.
Express seems to be a pretty flexible framework in terms of how the file structure is set up. Like Sinatra and unlike Rails, Express doesn’t have opinions as to how to organize your application and while there are countless ways to organize your application using Express, the framework comes ready to use out of the box if you just want to quickly set up some routes and get something on your screen. For me, I decided to establish an app structure that’s both familiar to me and able to handle multiple resources in a RESTful manner before I got too deep in the business logic while relying on a harder-to-scale structure. Now that I have the app set up, The next step is to write out my models, routes and controllers, which I’ll save for another blog post.