Sails.js Blog

This is the short and sweet version. If you find it helpful, you might want to check out the entire gist.

In your implementation, if you always do one of the following, you'll be good to go, and you'll provide a better experience for the people using your thing:

1. Invoke callback with only err => new Error()

Some kind of fatal error occurred-- something where I'd normally throw. Except that I'm an asynchronous function. So instead, I do this:

return cb(new Error('Something bad happened!'));

This is like doing throw new Error('Something bad happened!'); in a synchronous function.

2. Invoke callback with no arguments

Everything is AOK, and there's no other data to send back:

return cb();

This is like doing return; in a synchronous function.

3. Invoke callback with err => undefined and yourResult

Everything is AOK, and there's this result I want to send back:

return cb(undefined, yourResult);

Just reached the next milestone on the road towards Sails v1: As of today, you can add a line of code to your HTML to directly expose data from your server-side view locals to client-side JavaScript, with built-in XSS attack prevention. This eliminates the need to hand-roll your own decoding/encoding (or worse, forget). And it means you don’t need to send a bunch of extra AJAX requests to safely get the data you need onto the web page. (For more background on the use case, check out this 2012 post from Dan Webb, Twitter’s former engineering manager: https://blog.twitter.com/2012/improving-performance-on-twittercom)

Sails 0.12.2 will be published later today. At the moment, the pre-release is available when you run npm install sails@beta.

If anyone wants to try it out and let us know how it goes, the core team would greatly appreciate it!

The documentation has been updated for the newest release as well, and will be available on sailsjs.org as soon as cloudflare allows it. (Until then, you can find the un-cached version here.)

0.12.2

[ENHANCEMENT] Allow use of fn in expanded route targets e1790b7

[BUGFIX] Add blacklist to "update" blueprint action so that it can be used with primary keys that are not "id" 3625

[ENHANCEMENT] Allow hooks to be turned off by setting their environment var to the string "false" 3618

[BUGFIX] Allow view target syntax for routes to specify deeply-nested views 3604

[BUGFIX] Allow custom bodyParser middleware config 3592

[BUGFIX] When lifting with unknown validation rule, exit gracefully instead of throwing.

[BUGFIX] Update validation rules from anchor 3649

[BUGFIX] Respond with an error if attempting to use req.file() from a virtual request (i.e. when Skipper is not available). And don't pass in res when building the mock request, since it is not available yet. 3656

[BUGFIX] Fix incorrect handling of errors in responses hook. Thanks @tapuzzo-fsi! 3645

[BUGFIX] Fix error from routeCorsConfig sometimes being undefined 3662

[INTERNAL] Replace ready event with an async handleLift lifecycle callback in order to simplify the behavior of sails lift and ensure the timing of the "done" callback is correct when using it programmatically.

[INTERNAL] Massive overhaul of tests. See b033f2d thru e85810a.

[INTERNAL] Extrapolate ORM hook into sails-hook-orm.

[INTERNAL] Force asynchronicity in the optional third argument of res.view()/res.render() to pave the way for better, request-agnostic view rendering methods. This prevents double-calling of the callback if userland code throws an error. Thanks @lennym! cd413e15435947aa855e27aab16d9cd9e65ad493

[ENHANCEMENT] Update version of i18n to 0.8.1 3631.

[ENHANCEMENT] Improve auto-migrate prompt, and skip the prompt and log an info message instead if sails.config.models.migrate is being automatically set to production anyways. sails-hook-orm/commit/3161c34edbe0aa07055f8665493734dda1688c2a

[ENHANCEMENT] Add production check in case sails-disk is being used, and experimental sails.config.orm.skipProductionWarnings flag for preventing the warning. sails-hook-orm/commit/9a0d46e135dadf00bc4576341624a31e50b12838

[INTERNAL] Don't clone target function in expanded route syntax 6cfb2de

[BUGFIX] Replace naughty code in implicit default res.forbidden() response; relevant when api/responses/ is deleted. See #3667 for more info. Thanks @Biktop! 4767585994c45e7a7040402a057f0e41660d341919

[INCONSISTENCY] Fix embarassing old link that was being shown when you console.log the sails app instance. Thanks @wulfsolter 52d45688fcfb6c4437348115f3e9c91595a8d379!

[INTERNAL] Get rid of a whimsical little --require in mocha.opts that must have gotten lost. Don't ask us how it ended up there. Thanks @markelog! 06837a53b48352de7c46a1be84e87e28a084ffe2

see CHANGELOG.md for more information

Thanks so much to everyone who helped with this release! Even though it was just a patch, it fixed some important usability/consistency bugs, and hit some important milestones in the journey towards Sails v1.0. Stay tuned for more on that this month.

Here’s what’s new in [email protected]

Just published [email protected] which includes a couple of new things:

1. Recursive invocation (and maximum call stack protection)

just added support for maxRecursion in the machine runner. It’s a top-level property that lets you configure the built-in maximum call stack protection now included in the machine runner (defaults to 250.)

Only works for recursion invoked via env.thisMachine(). For example:

var result = env.thisMachine({ stuff: inputs.i+1 }).execSync(); // ...

or

env.thisMachine({ stuff: inputs.i+1 }).exec({ error: exits.error, success: function (result) { // ... } });

If maxRecursion is exceeded, instead of returning the real machine instance, env.thisMachine() returns a decoy machine that always triggers its error exit with an Error instance (whose code property is “E_MAX_RECURSION”)

2. Auto-timeout

Currently Sails.js does not have the ability to create custom commands on the sails command line tool. Here’s how we can do it.

Contents

Custom commands in Sails

sails deploy

Custom commands in Sails

example .sailsrc file

json { "commands": { "deploy": "sails-deploy" }, "deploy": { "module": "sails-deploy-azure" } }

In Sails core…

(in bin/sails.js)

When the CLI is run as sails deploy, since this is an unrecognized command, Sails should load base config using the rc module (see bin/sails-generate.js for an example). This will load any relevant config from the .sailsrc file(s) which apply to the current app.

Assuming we have a .sailsrc like the one above, there will be new commands and deploy namespaces in the app’s configuration object. So we’d be able to access:

js configObjectReturnedByRC.deploy.module // => 'sails-deploy-azure' configObjectReturnedByRC.commands.deploy // => 'sails-deploy'

Sails core should then check to see if commands exist, and if so, loop through each one and see if there is a command matching what the user is trying to do (e.g. “deploy”). If no match is found, cli does exactly what it does today (show usage instructions). But if a match is found, then the CLI requires the configured module (“sails-deploy”) from the context of the current sails project’s “appPath” (configObjectReturnedByRC.appPath). For example, something like this (warning: I did not run or double-check this code):

“`js var configObjectReturnedByRC = require(‘rc’)('sails’); var matchingCommand = _.find(configObjectReturnedByRC.commands || [], function (val, key){}); if (!matchingCommand) { /*… handle this case exactly as happens currently, then return early */ return; } var pathToRequire = require('path’).resolve(configObjectReturnedByRC.appPath||process.cwd(), 'node_modules’, matchingCommand); var customCmd; try { customCmd = require(pathToRequire); } catch (e){ // check if this is a MODULE_NOT_FOUND error (look at e.type or e.code, can’t remember) // if not, log an error message explaining that the custom command module referenced in one of the user’s sailsrc files has an issue (then dump the original error stack and bail out/return early) // if so, log a nice error message explaining the command the user typed was recognized as a custom command defined in one of their sailsrc files, but it could not be required from the specified path. Then bail out (return early) }

// Finally, if that all worked, run the custom command. customCmd({ config: configObjectReturnedByRC }, function (err){ if (err) { // log msg explaining deployment failed, then log the original error stack for details. return; } // log msg explaining deployment was successful. }); ”`

Note that this approach means users will need to npm install sails-noop --save in their project in order to run sails noop on the command line.

Custom command packages

Custom sails commands are npm packages that export a function w/ two arguments- options and cb (following standard node conventions).

For example, here’s a very simple no-op command as an example (sails-noop). Aside from its package.json , it has only one file: index.js.

“`js /** * Module dependences */ // …

/** * Usage: * $ sails noop */ module.exports = function noopCmd (options, cb) { // options.config is provided with the raw config that Sails core gathered by running rc. return cb(); }; ”`

====================================================

sails deploy

sails deploy can be implemented as a custom command as specced out above.

the sails-deploy package

The job of the sails-deploy package is to require() the configured strategy, then run it. Eventually it can end up taking responsibility for generic shared logic between deployment strategies (e.g. talking to github, pulling/pushing/tagging, etc.)- but we won’t know the right things to generalize until later when we have a few different strategies to look at. For now, we’ll just run the strategy.

This will be pretty similar to what we just did (which is also more or less how generators, adapters, and hooks work). In the deploy object in the sailsrc file, the module property can be specified as any of the following: 1. an absolute path (if it starts with /) 2. a relative path from the sailsrc file (if it starts with ./ or ../), or otherwise 3. an NPM package name (in which sails will attempt to require() the deployment strategy module from the node_modules folder within the sails project’s appPath).

Note that this approach means a user will need to npm install sails-deploy-noop --save in her project and configure "deploy": {"module": "sails-deploy-noop"} in her sailsrc file. Then she can run sails deploy on the command line and sails-deploy-noop will be used automatically.

sails-deploy-* strategies

The simplest no-op deploy strategy (e.g. sails-deploy-noop) is simply an npm package with a package.json and an index.js file:

“`js /** * Module dependences */ // …

module.exports = function sailsDeployNoop(options, cb) { // options.config is provided with the raw config that Sails core gathered by running rc. return cb(); }; ”`

Again, we can get fancier here eventually as far as what happens in sails-deploy itself, but for now, a simple function is the right approach.

If anyone else is interested in getting involved on this effort, please let me know here (or on twitter @mikermcneil.) Thanks!

So I straight-up failed my first logic class in undergrad. This really surprised me- not because I was a good student (I wasn’t) but because for some reason, despite being relatively interested in logic and discrete math- the whole “reason about things and write proofs using English words” never “clicked” for me. And basically what that meant is that I never went to class.

After scoring a spectacular 13% score on my second test, I decided to skip my final exam and spend the rest of the semester focusing on what really mattered: my dreamcore band. But unfortunately, they don’t give you credits for that sort of thing.

When I re-enrolled the next semester, I was fortunate enough to study under J. Strother Moore, the co-creator of one of the world’s fastest string search algorithms. I actually never realized that he was the dude who wrote the Boyer-Moore algorithm (because I skipped the first few days of class– seeing a pattern here?)

Anwyay, I ended up doing really well in the class… like… really well. In fact, it was the only “A” I made in college. The reasons were twofold:

Watching J. Strother Moore use emacs is nothing short of breathtaking.

The course introduced me to Lisp– specifically ACL2, which we used to write proofs and represent predicate calculi.

Which meant I went to class.

The most important thing I took away from listening to Moore was just how simple it is to write programs that manipulate programs. Brett Victor has a bunch of great material on the subject, so I won’t dig too deep here on why this is important.

I’m more interested in how. As in, what’s actionable today? I’ve spent the last seven years dreaming about ways to apply the flexiblity of Lisp to the repetitive development I was doing every day (first homework, then small contract jobs, then bigger and bigger client projects at Balderdash, then building Sails.js). And I’ve finally got some ideas I feel pretty good about.

We are getting close to a day where backend development will be commoditized and replaced with declarative tooling– software that writes software that never breaks.

The gist I linked to below explores how asynchronous programming instructs that future, and lays down the conceptual framework that makes this possible. It takes some basic jQuery form-handling code, chops it up into symbols, and strives to make it better by understanding all of the error cases that are implicitly unhandled.

Let me know what you think.

Read “Outcome Oriented Programming”

tldr; Writing code leads to a series of unhandled exceptions, which creates a “snowball” effect, which in turn leads to hard-to-detect bugs. One simple cure would be each line of code understanding its possible outcomes/error conditions. But unfortunately, this is impractical today due to a bottleneck in reusability. The proposed solution:

I’m teaching a live, interactive Sails.js course on Platzi tomorrow.

Over the course of a couple of hours, I’ll live-code an Angular+Sails+Node.js application that integrates realtime features, basic login, social auth (via Twitter), and Angular. I’ll also demonstrate when to use SPAs and when to use server-rendered views, plus some different approaches for handling SEO. Best part is it’s completely free, thanks to Christian and Freddy letting me use their friggin sweet studio with all these awesome mics and stuff.

If you’re wondering what to expect, picture this: it’ll sort of be like we’re on the same basketball team, except instead of dribbling down the court with athletic celebrities, you’ll be writing code with some scrawny nerd from Tejas.

But at the very least you’ll leave the course with a solid grasp of the best practices for Node.js and Angular that the rest of the core team and I have relied on for the last three years to build full-stack JavaScript apps for everyone from startup companies to Fortune 500 juggernauts.

The course is completely in English, I just like that picture because it makes me look cool and bilingual (I’m neither)

Not sure you’re the intended audience? Don’t worry- it’s easy to find out. You need to be there if you answer yes to any of the following questions:

Tired of not understanding EXACTLY how servers work? (hint: they’re really freaking easy)

Want to learn how to work with Sails.js?

Would you like to take your Node.js skills further?

Want to build complete, full-stack applications without relying on other teams?

Have a question for me or someone else on the core team?

Want to ask me terrifying personal questions? Anything goes!

Here are the official deets:

Sails.js and Node.js basics live and online via Platzi

Where: https://courses.platzi.com/courses/develop-apps-sails-js/

When: February 28, 1PM Pacific Time (3pm Central, 4pm Eastern)

How: The class is free. All you have to do is sign up.

We will cover:

Intro to Node.js app development

Web Apps with Sails.js (focus on frontend, forget the backend)

Integration with Angular.js

Asset pipeline with Grunt

Real-time Javascript with sockets

Authentication and login in JavaScript (SPA vs server-rendered views)

Twitter OAuth with Sails.js

Data models with MongoDB

Deployment to Heroku and/or Azure

Sneak peek at the next generation of tooling we’re working on

About:

Sails is, of course, a web framework. But take a step back. What does that mean? Sometimes, when we refer to the “web”, we mean the “front-end web.” We think of concepts like web standards, or HTML 5, or CSS 3; and frameworks like Backbone, or Angular, or jQuery.

Sails is not “that kind” of a web framework. Sails works great with Angular and Backbone, but you would never use Sails instead of those libraries.

I hope you save some space in your calendar for tomorrow!

See you there.

~Mike

When building a Sails app, the sending or receiving of any asynchronous communication with another piece of hardware with a CRUD-oriented API can be normalized into an adapter. If the thing you’re dealing with (e.g. facebook) is not a true CRUD API, then write a machinepack instead.

So basically, if you’re writing a callback for something, why not wrap that logic up into an adapter/machinepack and take advantage of Sails’ conventions/community? It’s just as easy to write, and you get the advantage of a standardized API for accessing and mutating data. Best of all, you (and your team) can reuse the adapter/machines in other projects.

The more high-quality machinepacks and adapters you release as open-source, the less repetitive work we all have to do when we integrate with various databases and services. My vision is to make building server-side apps more fun and less repetitive for everyone, and that happens one community project at a time.

How it works

Waterline exposes a minimal adapter interface with a few required methods: find, create, update, destroy (FUCD)

If a database supports a feature in the optional spec natively, it should be implemented in the adapter (e.g. createEach)

If an adapter doesn’t implement optional methods in the spec, they will be polyfilled by waterline core (e.g. calling create over and over) In this way, we allow flexibility to squeeze power out of underlying databases, but also make it easy to start writing adapters.

An adapter can also implement extra methods which are not part of the official Waterline adapter spec (the spec will always move slower than individual adapters since it has to look after the needs of every supported database). These extra methods are exposed on models which use the adapter (e.g. User.foobar({}, function (err, result){}))

Philosophy

A contributor should be able to implement only those methods she needs / has time for.

A suite of standardized tests should be provided that test against the interface (waterline-adapter-tests)

How do file uploads actually work? What the hell is a body parser?

This is a work-in-progress based on the discussion in this GitHub issue on the Skipper repo

How File Uploads Work

This is my first attempt at explaining the efficient handling of TB multipart file uploads using ASCII infographics, so please be patient :p

Traditional body parsers

ie. the legacy Express/Connect body parser

No body parser

Skipper

Legend

Symbol Meaning =~=~=~=~> incoming file stream, arriving a few kB at a time (don’t wait for entire file) ===/ /==> entire file duplicated on disk (wait for entire file before proceeding)

Is there any way I can know the names of the the temporary files from req (in an api service) before I upload ?

Instead of using the .upload() convenience method, you can tap in directly to the upstream of incoming files:

In the next release of Skipper, I’m interested in exposing a built-in configurable function you can use to accept or reject any given incoming file from an upstream before it is passed to the receiver (this is effectively how the maxBytes option works) If you’re reading this, please let me know if you also have this use case and have time to contribute. We need your help.

If there’s no way: how do I access req.files. Doesn’t seem to work?

So the req.files you’re used to was a property of the traditional Express/Connect body parser from Express <= v3.0.0. The way it works is to upload incoming files to a temporary directory on disk – before running your app-level code. That means if a user agent is uploading three 100MB files, they must be entirely streamed to the server’s hard disk before your code can run. While it was possible to limit this somewhat in previous versions of Express, it was still a challenge- and more importantly, an easy-to-miss DoS vulnerability. So Express 4 removed file upload support from core. Meanwhile, @sgress454 and I were working on Skipper because I didn’t want to just leave people using Sails (including myself) hanging.

So… what’s a filesystem?

According to wikipedia:

In computing, a file system (or filesystem) is used to control how data is stored and retrieved. Without a file system, information placed in a storage area would be one large body of data with no way to tell where one piece of information stops and the next begins. By separating the data into individual pieces, and giving each piece a name, the information is easily separated and identified. Taking its name from the way paper-based information systems are named, each piece of data is called a “file”. The structure and logic rules used to manage the groups of information and their names is called a “file system”.

While all that is true, it’s not quite what I’m looking for, nor particularly useful as a lemma in the grand unified theory of computer science we’re reluctantly building in the Node.js community.