31–40 of 155 posts
Earlier quoted context omitted.
We have our own little lightweight version of PouchDB that isn’t really a version of PouchDB. It works well for now, but we might migrate to Pouch later.
Yeh we should definitely work on this when you are in town :) the storage part of pouch is nearing being complete and stable, the server infrastructure was next on the list (after docs etc)
Neat, I really like the idea of being able to sync local storage with a Couch backend. > Hoodie currently only runs on OS X Oh, a hipster framework.
> Oh, a hipster framework. Never attribute to hipsterism what could adequately be explained with picking priorities :) The hoodie backend works anywhere node and Couch work (anywhere, really), it’s just that the local dev setup with the fancy domains and everything is tailored to Mac OS X. We have Linux support in the works.
Neat, I really like the idea of being able to sync local storage with a Couch backend. > Hoodie currently only runs on OS X Oh, a hipster framework.
are you on Windows or Linux? Would be great if you could help us to migrate it. hoodie is basically CouchDB + node.js, nothing fancy. We just do local DNS magic, creating *.dev domains like http://pow.cx/ , that is only compatible with Mac atm
This looks pretty optimal for a little app I'm building. I've been bolting bits to Sinatra and using it as a half-API-half-template engine for a frontend I built, this looks far cleaner. I'm curious about security though, what's stopping a user from plugging in random data via the console?
Nothing, all they can do is fuck up their own data.
1. Even if the users are idiots you shouldn't let them ruin their own application experience. 2. I would never put anything remotely connected to security and user privileges in the same storage accessible by users, so I would have to set up a separate service.
Neat, I really like the idea of being able to sync local storage with a Couch backend. > Hoodie currently only runs on OS X Oh, a hipster framework.
How does this compare to, say, Meteor?
I haven't had time to look at try out the walkthrough, so here's a kind of dumb question that wasn't answered explicitly in the docs: how does it work with existing front-end frameworks, such as Backbone, Angular, Ember, etc? I ask this because of the description found on the Github page: https://github.com/hoodiehq/hoodie.js hoodie is a JavaScript library that runs in your browser. It gives you user authentication d…
at first, Hoodie is just a Store for data. So instead of Backbone, Angular etc storing their data via AJAX on a server, or in LocalStorage, we can very simply build adapters for all of the MV* frameworks to use Hoodie as their store. This way, you get accounts and data synchronization for free. And offline ;-) Emails and other future modules like payments are just extensions of the available JavaScript API in the bro…
Behind the scenes, Hoodie takes care of account creation,
email validation and all the boring backend tasks you have
to think of.
Am I being dense, or is this like a nice client framework that still needs to talk AJAX to the backend, so still needs to allow oAuth, so still needs to change code if the API changes, and so on.
"We just want to make apps, and add billing by Monday" is a bit worrying as a goal to me...
edit: oh, so this stubs out the server side at the client ? It seems like the same amount of work to keep backbone models in synch with the server as it does to keep hoodie? What do I gain?
It's odd that no one's mentioned it yet, but this reminds me most of Meteor. How does this compare to, say, Meteor?
The JavaScript API is what we care about most. We do currently have the hood.ie backend implemented in Node/CouchDB, but it could be everything, really. The frontend developer doesn't care.
It's odd that no one's mentioned it yet, but this reminds me most of Meteor. How does this compare to, say, Meteor?
hood.ie has a different approach. Meteor brings backend logic to the frontend. hood.ie tries to hide the backend entirely and provide an API that feels natural for the frontend environment. The JavaScript API is what we care about most. We do currently have the hood.ie backend implemented in Node/CouchDB, but it could be everything, really. The frontend developer doesn't care.