Live data from Hacker News

Hoodie – Fast web app development

hood.ie

61–70 of 147 posts

Re: Hoodie – Fast web app development

#61
post #52
post #8

Team Hoodie here. Happy to answer any questions you might have :)

Hi , from the docs " Hoodie will only sync data to the database if it belongs to a user!" will there be ways to manage some complex ACL scenarios ?

I'm more the frontend guy at Hoodie, but what you'll be able to do is to allocate roles to users and based on the roles you can give read/write access down to document level.

If you have a specific scenario in mind, I'm happy to elaborate.

Re: Hoodie – Fast web app development

#62
post #39
post #8

Team Hoodie here. Happy to answer any questions you might have :)

Is it just me or are there some dependency management issues? Missing boom, shot, now lru-cache...down the rabbit hole.

Not that we are aware of. Could you please open an issue at https://github.com/hoodiehq/hoodie-server/issues/new, and post your error messages? We're happy to help

Re: Hoodie – Fast web app development

#63

How does this compare/contrast to Meteor?

Besides the points already mentioned, Meteor is VC backed. Hoodie is an open source project first, that we founded & bootstrapped a company for to sustain its future, and that we will eventually turn into a non-profit. We are and will be not accountable to any investor with questionable interests in an open source project.

Re: Hoodie – Fast web app development

#65
post #58

Earlier quoted context omitted.

The difference is server-side validation of untrusted client requests.

Hoodie does server-side validation of untrusted data.

Not yet. https://github.com/espy/hoodie-plugin-tutorial

"This document describes functionality and features that don't exist yet."

Re: Hoodie – Fast web app development

#66

Giving full email privileges to the client is a terrible idea. Even if you do rate limiting, you're essentially allowing anyone to get your mail server(s) blacklisted and all future mail from anyone marked as spam. In general, most people would be naturally apprehensive about federating their entire user authentication system through a third party. However, I suppose that by using hoodie you are supporting a group of…

Hoodie doesn't provide any email privileges in it's core. There is an email plugin that does that, but it's just a showcase and we would not recommend to use that in a production app. The plugin is maybe 10 lines of code, you can easily use that as base and put all the security in it that you would do in a REST API as well.

I'd be also very interested in your basic use cases that you think Hoodie couldn't handle. It would certainly be great input for the project.

Re: Hoodie – Fast web app development

#69
post #22

Earlier quoted context omitted.

I looked at pouchdb's website and there's a lot about browser support but I didn't see any docs about the data model. It seems you're expected to know how CouchDB works?

Yeah, it’s a document database, uses UUIDs and revisions for identification and does HTTP-based P2P replication. In Hoodie we abstract that away in a simple to use `hoodie.store` object with the usual `add()`, `update(), `find()`, `findAll()` methods for operations. No need to know about the CouchDB/PouchDB specifics, just store your objects :)

Okay, but the key design decision in any data syncing library is how it resolves update conflicts. Is it last-one-wins, report an error and try again, diff merging, or maybe some kind of operational transform?

Since that's the heart of the problem being solved, it's weird when the docs leave it out.

Re: Hoodie – Fast web app development

#70
post #27

Earlier quoted context omitted.

Hoodie works no different than Gmail. What’s the worst that can happen there?

Well you sure as shit aren't going to see "hoodie.account.signUp(username, password);" in Gmail's client-side code. Gmail's code base is not a "offline first, mobile first" platform. The API that is exposed to the client-side is fairly light (watch the traffic). I highly suggest use research "business logic flaws" in web apps. Anything Jeremiah Grossman has said on this topic is good stuff.

Yeah, but you're going to see a that POSTs to some target URL, with username and password as fields. The only thing protecting the plaintext password from leaking is SSL. POSTing a XmlHttpRequest is equivalent.
Post reply on HN