Node.js and MongoDB from scratch, fully explained and tested

John Culviner
GitHub: github.com/johnculviner
Blog: johnculviner.com
Twitter: @johnculviner
Email: john@johnculviner.com
+

About Me
 Independent Consultant @ BestBuy
 Backend
 DevOps (Docker, Ansible, Linux etc)
 Node.js
 NoSql (ElasticSearch, MongoDB)
 C# .NET
 Groovy/Spring/Java
 MS-SQL/MySQL
 Front End
 Manual, jQuery, Knockout.js, Durandal.js, Ember.js, Angular.js, Aurelia, React.js
 SPA development
 Open Source “Street Cred”
 AngularAgility
 jQuery File Download
 FluentKnockoutHelpers

Overview
 What is Node.js & what's it good for?
 vs .NET, Java etc.
 What is MongoDB & what's it good for?
 vs YOUR_FAV_SQL_DB_HERE
 Building a CMS from scratch
 Environment setup
 Simple API Endpoint
 Objective: What you should and shouldn't use this
stack for. To help you on your feet nice and easy!

What is ?
 Node.js is a JavaScript runtime built on Chrome's V8
JavaScript engine.
 It's like Chrome but it has framework modules that make
it useful on a server
Assertion
Testing
Buffer C/C++ Addons Child
Processes
Cluster Console
Crypto Debugger DNS Domain Errors Events
File System
Globals HTTP HTTPS Modules Net
OS Path Process Punycode Query Strings Readline
REPL Stream String Decoder Timers TLS/SSL TTY
UDP/Datagra
m
URL Utilities V8 VM ZLIB

 Node.js' package ecosystem, npm (node package
manager), is the largest ecosystem of open source
libraries in the world. modulecounts.com

What is ?
 Node.js uses an event-driven, non-blocking I/O model
that makes it lightweight and efficient.
 Single threaded event loop just like the browser
JavaScript you know and ¿love?

Event loop?
 EVERYTHING that is I/O bound blocking in Node.js is
async
 Node FORCES you to deal with I/O bound nature of
most of the apps we build* up front rather than
adding parallelization later on….
*by we I mean me and likely 90% of you

CPU bound?
 Don't block the single thread or else your app
will grind to a halt
 Think of times a website has locked up your
browser’s UI Classic while true
CPU intensive operations
Stack overflow

SUPER efficient with pipes
Actual entire node application

Why do I care ¯_(ツ)_/¯
 Allegedly (when
they aren’t using
Go)
--------------------------Big places in town you could work for ------------------------------
 Places with my
crappy Node code
in production 

Node.js - Good, Bad
 GOOD
 Web(like) applications that are limited
by I/O blocking (DB, backend service, file system, etc.
calls).
 Micro-services
 Moving data around/transforming data
 Rapid application development
 BAD
 Large, monolithic ‘enterprisey’
applications (strong typing *can* be nice)
 CPU intensive apps (you'll block the event loop and JS is
slow(er) than .NET, JVM, C++, etc.)
 You don’t think JavaScript is a “real” language

What is
 A “NoSQL” BSON (binary JSON) document DB
 Indexable, deep queryable, map-reduce aggregations
 Sharding – for data distribution “Scale out” on a shard key
(usually the document ID)
 Replication– for instance failure ‘safety’

Example
Shard Cluster (not required!)
Server A Server B
{ _id: ‘UUID’,
customerName: ‘Foo’
customerDomain ‘foo.com’
….}, {/*cust.*/},{/*cust.*/}
Collections
Pages
Cutomers
{ _id: ‘UUID’,
customerId: ‘UUID’
url: ‘/someurl’,
widgets: [
{name: ‘WidgetA’ /*settings*/},
{name: ‘WidgetB’, /*settings*/}
]
…..}, {/*page*/}, {/*page*/}…..
- Similar BSON documents
that end up here due to a
differing shard key from left
- BSON documents WITHIN
A COLLECTION can have
a varying schema! (but in
practice that might be a
bad idea)

Actual* email from MongoDB….
*minus the bro
part

Cutting through the BS…
 NoSQL works well for apps with few
“Aggregate Roots”
 “A group/cluster of objects that work together, are treated as
a unit that must remain consistent together”
Martin Fowler
likes aggregate
roots
Good use case
Pages
have Sections
have Widgets
have Settings
- settings might contain
nested object graphs etc.
• Only operate on a page
(read/write) as an atomic unit
• Duplication of data is small if
not non existent
Bad use case
Customers
Orders
LineItems
Products
Customer
Categories
Merchant
Categories
Vendors
• “Spiderweb” of relationships that
duplicate in a JOIN
• Care about operating on various “entities”
individually or within the bounds of an
atomic transaction

Random DB observations
 Why not BOTH relational and Document?
 Stores JSON natively and is querable/indexable!

 queries get slow in the millions of objects in a collection (w/o
index)
 Server side joins just added in version 3.2 (latest)
 ElasticSearch
 Built on Apache Lucene (just like Solr)
 Insanely fast search, data retrieval and full text queries
 Insanely fast n-levels deep aggregations and custom Groovy
scripts
 Very easy clustering/sharding/replication. Scale out!

Before we code…
 Tooling we are using:
 JetBrains IntelliJ/Webstorm
 NodeJS 6.3
 MongoDB 3.x
 iTerm + oh-my-zsh (z-shell)
 RoboMongo (the Mongo GUI)
 Install on *NIX
 [brew|apt-get|yum|etc..] install [mongodb|nodejs]
 Install on Windows
 Download MSIs/EXEs from respective websites

Node REPL
V8 JavaScript engine in
Node.js 4+ and Chrome
45+ supports string
templating and
LAMBDAS (w00t)

Questions/Comments?
John Culviner
GitHub: github.com/johnculviner
Blog: johnculviner.com
Twitter: @johnculviner
Email: john@johnculviner.com

Node.js and MongoDB from scratch, fully explained and tested

More Related Content

What's hot (20)

Similar to Node.js and MongoDB from scratch, fully explained and tested (20)

Recently uploaded (20)

Node.js and MongoDB from scratch, fully explained and tested