public
Last active

Imagine saving and finding user data would work right in the browser, persistent and synchronised. How would the code look like? This is what I came up with. Forks & comments much appreciated! #nobackend #dreamcode

  • Download Gist
store.dreamcode.js
JavaScript
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71
// add a new object
var type = 'note';
var attributes = {color: 'red'};
store.add(type, attributes)
.done(function (newObject) {});
.fail(function (error) {});
 
// update an existing object
var type = 'note';
var id = 'abc4567';
var update = {size: 2};
store.update(type, id, update)
.done(function (updatedObject) {});
 
// find one object
var type = 'note';
var id = 'abc4567';
store.find(type, id)
.done(function (object) {});
 
// Load all objects
store.findAll()
.done(function (objects) {});
 
// Load all objects from one type
var type = 'note';
store.findAll(type)
.done(function (objects) {});
 
// remove an existing object
var type = 'note';
var id = 'abc4567';
store.remove(type, id)
.done(function (removedObject) {});
// EVENTS
 
// listen to store events
store.on('add', function (newObject) {});
 
// new doc created
store.on('add', function (newObject) {});
 
// existing doc updated
store.on('update', function (updatedObject) {});
 
// doc removed
store.on('remove', function (removedObject) {});
 
// any of the events above
store.on('change', function (event, changedObject) {});
 
// all listeners can be filtered by type
store.on('add:note', function (newObject) {});
store.on('update:note', function (updatedObject) {});
store.on('remove:note', function (removedObject) {});
store.on('change:note', function (event, changedObject) {});
 
// ... and by type and id
store.on('update:note:uuid123', function (updatedObject) {});
store.on('remove:note:uuid123', function (removedObject) {});
store.on('change:note:uuid123', function (event, changedObject) {});
 
// ... react on changes coming from remote
store.on('add:note', function (newObject, options) {
if (options.remote) {
// do something wit
}
});

Deffinitly we would need some error handling. What if there is no object of note type with id = abc4567. I think find could be like this

// find one object
var type = 'note';
var id = 'abc4567';
hoodie.store.find(type, id)
  .done(function (object) {})
  .error(function (errorObject) {});

you're absolutely right, I just left them out because they've been so repetitive. I've added an error handler to the first example, as you suggested. Cheers!

Hey Gregor, noBackend is a cool idea. Making clean APIs is definitely the direction I go when writing my backends. I'm working on something right now and I'm still deciding on the client side API's so this looks like a good source of creativity. My biggest issue for my noBackend solution is security, it needs to be bullet-proof and also provide powerful APIs for the front-end.

A suggestion for this datastore API would to add some kind of access control. In most real world situations, each user has restricted access to a subset of the total data. My backend has a basic concept of User Roles, where each user has an array of roles and I can restrict particular HTTP methods on particular URL endpoints to particular roles. It quickly gets complicated and a nice API is what I'm after. Here's a few slides on User Roles which seem to cover a few of the issues, though they are just one way to do access control, another solution may provide a cleaner API.

Thanks @jpillora, glad you like it!

I understand your security concerns: I get that feedback quite often, like here.

In general, the whole idea of noBackend is a simple, clean API, which abstracts away the backend and its complexity, including security constraints.

For example, instead of

if (currentUser.hasAccess('article:edit'))
{
  store.add('article', properties)
} else {
  showError("You are not allowed to add new articles")
}

it should be

store.add('article', properties).fail( showError )

makes sense?

Yup, that does and a MONAD/chainable/fluent/promise-like API (however you want to refer to it) is a nice direction to go in. I guess I'm talking about something alittle different, I'm attempting to build a backend which has 2 responsibilities: database schema and database access. So the server is essentially a JSON object describing all database object schemas and also the rules that dictate what types of users can access these database objects, then server will hand these objects out over a RESTful API - and that's ALL it will do. This then passes the responsibility over to the frontend for the rest - which will hopefully result in an easy to use backend for front-end developers.

Say my new forum app has administrators, moderators and users. At least, we require administrators to have full access, moderators can delete/edit all posts and users can only edit/delete their own posts. This logic here needs to be on the server (this is the database access part) though when creating new users, the client must say which of 3 types above they will be (you can assume the access part prevents silly things like moderators creating admins).

This could be instead defined on the server so that when you say user.create the user type is contextually predefined depending on the current user. For me however, this is more logic that needs to be on the server, which I'm trying to move away from. So I guess our goals might diverge a bit here as I'm looking for a clean yet powerful API and you're looking for a small and simple API. The problem I see with small and simple as that if you want to abstract all of the backend away then some other developer will need to come and do the missing bits it for you. My goal is a 10% backend 90% frontend app, so one could write a complete app entirely(ish) in the front-end, whereas I think you're looking for the usual 50%, 50% approach, with backend guys just providing you with simpler APIs, which isn't really *no*Backend, thoughts ?

Anyway, that's kind of focused on the bigger picture, these APIs are good and I'll most likely write a companion front-end client to my server to achieve what you're after. I've already got a REST client which is close to what you've described: https://github.com/jpillora/jquery.rest

Currently my server is very beta, however I've got a few snippets in the README and you can get the gist of it: https://github.com/banchee/tranquil. At the moment I'm doing addResource and other adds though alternatively, it could be a command line tool which you point at a json file which is basically options and [resource, resource, ...].

I absolutely agree and very much encourage to suggest alternative APIs that diverge from my suggestions, for example in your case to server more complicated requirements, that's exactly the direction I'd love the discussion about Dreamcode to go. I just didn't find the right tool that really encourages this kind of discussion, gist is just a temporary solution at the moment.

I guess we'll have to create something on our own, unless someone can suggest a better way. But that's an off topic discussion, I've made an issue over here: https://github.com/noBackend/nobackend.org/issues/10

Please sign in to comment on this gist.

Something went wrong with that request. Please try again.