This template exists to make it easier for you to get started writing an adapter for Sails.js.
This adapter boilplate is for the v0.10 release of Sails / Waterline. Check out the section on custom adapters in the Sails docs for up-to-date information on building adapters with the latest version of Sails. (Or for <=Sails 0.9, check out the 0.8 branch of the repo for the original boilerplate from 2012.)
It's usually pretty easy to add your own adapters for integrating with proprietary systems or existing open APIs. For most things, it's as easy as require('some-module')
and mapping the appropriate methods to match waterline semantics. To get started:
- Fork this repository
- Set up your
README.md
andpackage.json
file. Sails.js adapter module names are of the form sails-*, where * is the name of the datastore or service you're integrating with. - Build your adapter.
Configure the interfaces you plan to support (and targeted version of Sails/Waterline) in the adapter's package.json
file:
{
//...
"sailsAdapter": {
"sailsVersion": "~0.10.0",
"implements": [
"semantic",
"queryable",
"associations"
]
}
}
In your adapter's directory, run:
$ npm test
You're welcome to write proprietary adapters and use them any way you wish-- these instructions are for releasing an open-source adapter.
-
Create a new public repo and add it as a remote (`git remote add origin git@github.com:yourusername/sails-youradaptername.git)
-
Make sure you attribute yourself as the author and set the license in the package.json to "MIT".
-
Run the tests one last time.
-
Do a pull request to sails-docs adding your repo to
data/adapters.js
. Please let us know about any special instructions for usage/testing. -
We'll update the documentation with information about your new adapter
-
Then everyone will adore you with lavish praises. Mike might even send you jelly beans.
-
Run
npm version patch
-
Run
git push && git push --tags
-
Run
npm publish
Waterline is a new kind of storage and retrieval engine for Sails.js. It provides a uniform API for accessing stuff from different kinds of databases, protocols, and 3rd party APIs. That means you write the same code to get users, whether they live in mySQL, LDAP, MongoDB, or Facebook.