Intro to Sails.js
Upcoming SlideShare
Loading in...5
×
 

Intro to Sails.js

on

  • 550 views

Presented at DevOpsDays Austin 2014 by Mike McNeil (http://www.slideshare.net/michaelrmcneil).

Presented at DevOpsDays Austin 2014 by Mike McNeil (http://www.slideshare.net/michaelrmcneil).

Statistics

Views

Total Views
550
Views on SlideShare
531
Embed Views
19

Actions

Likes
3
Downloads
6
Comments
0

2 Embeds 19

http://www.slideee.com 14
http://startups.oktopic.com 5

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Intro to Sails.js Intro to Sails.js Presentation Transcript

  • sails.js realtime MVC framework for Node.js
  • who am i? @mikermcneil
  • We design and develop javascript apps for enterprise and startup customers. i have a startup called balderdash
  • love at first sight circa 2011 Node.js...
  • node.js translates server concepts into javascript-- the lingua franca for the every- man our event loop is faster than your thing native bindings means Node can do pretty much anything core is purposefully feature-sparse npm publish, nuff said (lower barrier to entry) • • • • •
  • route& first* philosophy opt&in* framework* structure “smalltalk* ethics” UML “javascript* ethics” servlets mvc spring,* et.*al. rails enterprise* java ruby module system (npm) noSQL (mongo/ redis) async* flow* control from*the* front&end: generators (yeoman) node.js convention* over* configuration event*loop ORM
  • Can we use Node.js for, like, everything? i wondered...
  • Can we use Node.js for, like, everything? i wondered... maybe.
  • Realtime used to be kind of hard XMPP Comet Reverse AJAX Long polling Flash sockets WebSockets Server-sent events
  • A lot easier now
  • Programming realtime apps was still not trivial. WebSocket and HTTP messages/ requests have to be handled independently, which leads to separate code bases for realtime and traditional server code.
  • Programming realtime apps was still not trivial. WebSocket and HTTP messages/ requests have to be handled independently, which leads to separate code bases for realtime and traditional server code. Socket programming is a new paradigm for many modern web developers
  • WebSocket and HTTP messages/ requests have to be handled independently, which leads to separate code bases for realtime and traditional server code. Socket programming is a new paradigm for many modern web developers Questions about scalability Programming realtime apps was still not trivial.
  • Express wasn’t “structured enough” Authentication has to be rolled from scratch
  • Express wasn’t “structured enough” Authentication has to be rolled from scratch No standard, implementation-agnostic method of working with datastores
  • Express wasn’t “structured enough” Authentication has to be rolled from scratch No standard, implementation-agnostic method of working with datastores Low level and free-form -- not a lot of guidelines for teams used to convention-over-configuration frameworks
  • Lots of different kinds of projects There weren’t really any simple and reproducible patterns for structuring complicated Node.js aplications top to bottom
  • Lots of different kinds of projects There weren’t really any simple and reproducible patterns for structuring complicated Node.js aplications top to bottom Could be working with an existing client, or writing a new client for a mobile web browser, an automobile, a toaster, or god knows what
  • Lots of different kinds of projects There weren’t really any simple and reproducible patterns for structuring complicated Node.js aplications top to bottom Could be working with an existing client, or writing a new client for a mobile web browser, an automobile, a toaster, or god knows what Lots of different 3rd party proprietary services to deal with on the back-end -- there was no standard way to integrate new systems
  • too bad. we went with Node anyway.
  • so Sails.js was born
  • MVC structure Sails.js is modeled after the same convention-over-configuration philosophy you’re used to from frameworks like Rails, Grails, Symfony, and Zend. Controller actions are just Express middleware Views are ejs by default, but you can use jade, etc. We rarely use them since we’re normally making single page apps with client-side templates.
  • Lightweight ORM Kept querying semantics dead-simple and adapter-agnostic whenever possible Pulled the best of Active Record, Hibernate, and Mongoose Made it easy to add purpose-built adapters at the app level
  • Policies Policies are just more Express middleware They can be chained together to “protect” or preprocess requests for controllers E.g. access control, storage quotas, or anything else you’d want to use middleware for
  • Socket.io Request interpreter Translated incoming socket.io messages into Express requests Translated res.send(), res.json(), and res.view() to respond via the socket, as well as allowing for streams Added res.broadcast() and req.join() methods for pubsub Normalized configuration
  • Blueprints Instead of something like Rails HTML scaffolds, by default, when you generate a model and controller, Sails serves an API Built-in search, sort, pagination, and complex queries Authentication/access control can be built on top using policies
  • Other cool stuff CLI tool REPL Custom adapters Optional server-side coffee support Automatic asset bundling (LESS and coffeescript files are compiled, merged with css and js, and injected into the DOM, minified in production mode) Uses grunt by default, but can be replaced by ant, gulp, maven, etc.
  • associations • should upgrade not only Waterline (ORM), but also RESTful blueprints and model-focused publish/ subscribe (pubsub) methods. • cross-adapter • cross-connection • efficient as possible, allowing more efficient solutions to be implemented at the adapter layer Sturday, Jauary 25, 4
  • why mess with this? • NoSQL • simplicity • performance • traditional SQL databases • built-in ACID • reporting queries
  • cross-adapter • MySQL tables • MongoDB collections • PostgreSQL tables • Twitter API REST resources • etc.
  • cross-connection • different hosts (servers) • different database users • nasty/annoying integrations w/ legacy data e.g. join two different MySQL databases with incompatible schemas •
  • how it works • when possible, use native optimizations (i.e. joins) at the database layer • in-memory joins for the rest, just like you would have to do in code • maintains multiple connection pools
  • impact on adapters • Existing Sails adapters (and any new ones you write) now support associations out of the box, without writing any additional code. • You can add a `join()` method that will be used instead of `find()` for running intra- database associations queries.
  • let’s code things now OK
  • CURRENT STATUS (V0.9.13) Community is flourishing (over 6000 stars / 600 forks on github, active IRC channel and Google group)
  • Community is flourishing (over 6000 stars / 600 forks on github, active IRC channel and Google group) My company and most of our customers are using Sails in production CURRENT STATUS (V0.9.13)
  • My company and most of our customers are using Sails in production Oldest running production Sails apps havs been up for over 2 years CURRENT STATUS (V0.9.13) Community is flourishing (over 6000 stars / 600 forks on github, active IRC channel and Google group)
  • extending sails • adapter interface: standards for how our servers talk to databases and web services • blueprint interface: standards for how our servers offer up their own API-- start with conventional setup, then jump into writing custom code later. generators: plugins that allow sails new and sails generate output to be completely overridden and/or extended • hooks: plugins that allow components of the Sails runtime to be overridden or extended •
  • adapters • sails-mysql (npm$install$sails*mysql) • sails-redis (npm$install$sails*redis) • sails-mongo (npm$install$sails*mongo) • sails-postgresql (npm$install$sails*postgresql) • sails-rest (npm$install$sails*rest) • sails-couch (npm$install$sails*couch) • etc.
  • blueprints • generic impl. for HTTP/ socket APIs • prioritizes usability / practicality over elegance • declarative configuration (e.g. ember expects a certain format, or angular prefers a certain JSONP parameter) • overridable (can replace logic completely with imperative code at a moment’s notice)
  • generators • sails-generate-new npm$install$sails*generate*new npm$install$sails*generate*new*coffee npm$install$sails*generate*new*but*like*express npm$install$sails*generate*new*blog • sails-generate-backend npm$install$sails*generate*backend*coffee npm$install$sails*generate*new*jade • sails-generate-frontend • sails-generate-gruntfile • sails-generate-controller npm$install$sails*generate*controller*coffee • sails-generate-auth • etc.
  • hooks • http • sockets • orm • cors • csrf • spdy • etc.
  • Want to get involved? Contribute to an adapter
  • Want to get involved? Contribute to an adapter improve the documentation
  • Want to get involved? Contribute to an adapter improve the documentation Write tutorials
  • Want to get involved? Contribute to an adapter Improve the documentation Write tutorials Blog about Sails
  • Contribute to an adapter improve the documentation Write tutorials Blog about Sails Build an integration with your product or API (it's pretty easy) Want to get involved?
  • Questions?
  • Thanks! @mikermcneil mike@balderdash.co