A small library providing an easy to use API endpoint for storing persistent data in JSON files in express apps. This is configured out of the box to work with angular's $resource module, making it easy to get test data to and from your client code.
npm install node-objectionObjection
=========
npm install node-objection --save
objection("users") will create /db/users.json file.
var objection = require("node-objection")();
app.use("/employees", objection.collection("employees"));
objection("[object]") format. For example... If i wanted to create an todo collection i would simply do the following.
var objection = require("node-objection");
app.use("/todos", objection.collection("todos"));
GET /users/?lastName=Smith
[
{fisrtName:"Bob", lastName:"Smith"},
{fisrtName:"Nancy", lastName:"Smith"},
{fisrtName:"Jason", lastName:"Smith"}
]
`
To sort a collection use the orderBy query parameter with the key you want to orderBy. Right now you can only order by asc.
> GET /users/?orderBy=firstName
This will return the following.
`
[
{fisrtName:"Bob", lastName:"Smith"},
{fisrtName:"Jason", lastName:"Smith"},
{fisrtName:"Nancy", lastName:"Smith"}
]
`
-----------------------------------------------
Predefined Schemas
Objection includes some predefined schema for common use cases. This allows you get up and running with your client side application without having wrestle with backend logic.
$3
The User Schema provides built in password hashing and authentication. To implement a user schema do the following:
> var objection = require("node-objection");
>
> app.use("/users", objection.user());
This provides an endpoint at /users with all of the RESTful methods mentioned above, a predefined schema, and some bonus features.
`
{
email:[email], // User Email, must be unique
password:[hash of password], // Password hashed
username:[username], // Username, must be unique.
role:[role], // The role of a user, defaults to "user".
created:[date created], // The date this user was created.
updated:[date updated], // The date this user was last updated.
_id:[GUID] // The unique identifier of this user.
}
`
* If you send a password in the request body @ POST /users request, it will be hashed and stored, but not returned.
* Anytime you update a user @ PUT /users/:_id the new password will be hashed and stored, and not returned.
* For authentication purposes, the email & username key is set to unique. You will get a 400 status bad request if you try to store duplicate emails or usernames.
* An additional route is made for authentication @ /users/login. This is route to post your email and password.
* A token validation route is made @ /users/validate. This is route to validate your tokens.
* A role key with a default value of "user" is added to each user so you can test roles and permissions in you app.
In addition to the db/user.json, the user schema also creates back end goodies for logging, and testing purposes.
* /db/jwt.json If JSON Web Tokens are enable, this logs all json web token issued with the following schema.
`
{
user:[_id], // _id of the user the token was issued to.
token:[access_token], // The actual token that was issued to the user.
date:current_date, // The date the token was issued
expires:expires / The date the token expires
};
`
* /db/attempts.json This simply logs login attempts and
`
{
date:[moment date], // The date a login attempt was made.
user:[user], // The user attempting to login. This is the username || email and pass
allowed:[boolean], // Did the login attempt succeed.
};
`
----------------------------
Model API
Behind the scenes, there is is a model API that wraps the diskdb mongodb-like methods. These methods are mapped to the RESTful request as follows.
* GET /[collection] - model.select(); - db.find();
* GET /[collection]/[_id] - model.findOne({_id:_id}); - db.findOne({_id:_id});
* POST /[collection]/[_id] - model.insert({data}); - db.save({data})
* PUT /[collection]/[_id] - model.update([_id], {data}); - db.update([_id], {data});
* DELETE /[collection]/[_id] - model.remove({_id:_id}); - db.remove({_id:_id});`