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 people whose only job is to ensure security and fix vulnerabilities in your login system. It's also open-source, so you can vet it for yourself.
The JS library needs more work though - I could think of several basic use cases that it can't handle. It would also be great to see some full examples. Overall this is very cool stuff.
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.
We also encourage people not to use Hoodie in production, yet :)
What @gr2m means: there is no reason Hoodie’s mail feature would work any different from a traditional web app. At some point a server side will validate a client request, and if valid, translate that into sending an email (Gmail comes to mind). Hoodie’s email plugin can do exactly that, except that today’s implementation is a mere sketch of that, like other parts of Hoodie, that show what can be done, but aren’t hardened against production use, yet. None of that means though that Hoodie behaves any differently from a security/abuse/DOS perspective than any other web app :)
Thanks for confirming my crosspost :) However, as I was just saying, wouldn't it be nice to clearly see that we're talking 0.x directly on the website and not only when we install the npm package?
EDIT: Thanks for your answer, I am going to stop crossposting now :D
To be fair they are still working on 0.x, they probably don't recommend the whole thing to be used in production (although I personally wouldn't mind for some specific projects...). At this stage, I understand they just want to showcase some cool stuff. This being said, we should always be really careful about security when using dependencies, especially when it's in beta, and especially when mostly everything is done client side. It would be also nice if something more explicit was mentioned on the hoodie website. Like the last release version for example (0.x).
Our goal is to lower the barrier of entry to build fully capable applications. While using the simple email plugin is not a good idea in a production app, there is no problem to use it with an app that runs on your computer only, or in your companie's intranet.
I know this is nightmare to system architects / backend developers at first sight, but trust us, we know exactly what we are doing. We have excellent architects on our team, you just might not be our primary target group here.
If you wonder how the synchronization works, it's currently using a custom solution which is built on top of local storage. However it seems[0] that they are planing to switch to the awesome Pouchdb[1].
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.
Conflicts are detected for you, like in version control systems. You need to resolve them yourself, or you can implement a server-wins/client-wins/last-write-wins scenario, if you want to.
Operational Transformation does not work offline at all, and offline seems to be at the heart of Hoodie. OT requires a central point of coordination. That's why the current Google Docs freezes editing if your connection goes. For offline syncing, you need to use CRDTs.
The PouchDB documentation is quite light right now and does assume users are familiar with CouchDB, it has the same semantics as CouchDB (conflicts are stored and resolved by the app)
The documentation and tutorials will be a big focus going forward
I know @gr2m, one of the guys behind Hoodie - he's one of the most awesome and holistic engineers I have met in my professional career! Also he's a regular speaker at conferences and devoting his time for charitable work.
If you don't have a backend ninja in your dev team, you should take a serious look into Hoodie!
There are probably videos. However, I do not have links.
But he was one of the speakers at re:publica[1] two weeks ago in Berlin as well as one of the moderators of the Global Innovation Lounge that was streamed by voicerepublic[2].
I wish we could stop calling things "broken" just because they work in a way that's well thought out but unconventional. How are we ever going to make progress on UI design if everyone immediately gets chastised for deviating from more orthodox web behavior by even the slightest amount?
EDIT: lbarrow is correct that the hash tag navigation is borked. I thought people were just complaining about navigation to a previous site on the same tab. I stand corrected, I fully agree it's broken.
would like to know a bit more about comparisons with other realtime & offline-syncable BAAS like: Meteor, Firebase, AngularFire etc -
As a non-dev, this looks very appealing, but before I start learning I wanted to know more about the strengths/weaknesses compared to others.
Hoodie is Open Source and more like BYOBAAS (Bring Your Own Backend As A Service), you can host it yourself, or pay someone to host it for you. You are not beholden to single company’s VCs.
Meteor is about exposing backend and frontend APIs to the browser. Hoodie hides backend complexity as much as it can. The target audiences are very different. Hoodie aims for more frobtendy/designery types, in the future Hoodie definitely wants to reach non-coders as well.
Firebase and Meteor have likely seen more development time, because Hoodie is supported by a bootstrapped company that works on Hoodie part-time and puts it’s profits into future Hoodie development. That way Hoodie moves slower, but Hoodie won’t be at a crossroads when VC funding runs out, or expected growth isn’t big enough.
As far as I can tell, Hoodie’s offline/sync/p2p story is more solid than any other solutions, but then, I’m heavily biased :)
Hoodie’s focus on clean and simple APIs also makes it more easy for beginners.
Firebase does provide robust retry behavior. It tracks data changes, allows explicit online/offline mode, and you can easily write event handlers for sync errors. It also has what looks to me like a much more complete security model.
yeah, my point here is that Meteor gives full-stack (yuck) developers all they need to build quick apps. Hoodie targets UX/Designers/Code-copy-and-pasters.
Full-tack devs will be incredibly quick with Hoodie, like they would with Meteor (or vice versa), it’s just a fundamental difference in design and implementation.
no worries, and thanks! Actually, there is already at least one app in production running on it for a few months now plus a few MVPs, so if you want to go for it: do it. We're currently working towards the release of 1.0.
Any particular (eg: technical) reason it doesn't support Android but does support iOS? If Android will get there one day I'd certainly be interested, but if it's never coming for some reason I'd probably look elsewhere.
No technical reason, we are just lacking the person-power to tackle Android now. It should be straightforward to port from the iOS and web versions and we’d be super happy if someone would take that on :)
I thought much the same thing. Back in the day getting anything .ie registered was a massive pain, and you could pretty much forget it if you weren't an Irish business or highly motivated individual. They'd even try to impose content restrictions (ie. no adult content)
IIRC it got to the point once that a satirical radio show ran promos for what it claimed was the first porn site on .ie, but the link was actually to a gallery of a disheveled blonde helping to push a car out of a ditch. Which I suppose would count for some people, Rule 34 after all.
Which has nothing to do with hood.ie - overall I'd say it looks interesting, and a great way for a FE dev to build a prototype or v1.0 of a web app. I'd be very nervous about scalability though.
I was thinking that initially, but it looks to be a proxy registration with somebody else acting as the domain holder. The domain holder is 'Paul Campbell', who registered under the category "Discretionary Name" as a Sole Trader. I'm guessing there were some little fibs used to get the registration past the hostmasters... :-)
Well, I work for a registrar. I know practically all the tricks around their silly rules at this point and was more wondering which particular set of tricks you used. :-)
Happy to hear! There are various ways - no matter if you're a developer or not, we're happy if you want to contribute (if you want to contact us for details, see http://hood.ie/#about ). There's also the opportunity of sponsoring (http://hood.ie/sponsoring.html) which is also possible for individuals. And you can of course always help us by spreading the word about Hoodie if you like it, perhaps giving a talk about it, writing a plugin if you want to extend Hoodie's core features (https://github.com/espy/hoodie-plugin-tutorial) or giving us feedback.
Yup :) — We are aiming for the Google Docs sharing model eventually. It is specced out and we are slowly implementing it bottom up based on current use-cases.
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.
Yes comma but :) — We have a production app, but we are very comfortable running Hoodie in production ourselves, of course. The app has 10k registered users and some decent, but no overwhelming traffic. For similar scenarios, Hoodie is definitely ready, for others, we’d caution and recommend to get in touch with us for a more thorough evaluation.
Desktop clients have been delivering business logic to clients for a very long time with few problems. Web powered apps are similar. The issues involve protecting data stored in the cloud, communicating over secure channels and client security. JavaScript powered applications running in a browser have many security considerations, but they're manageable if you have security aware engineers building your application. Knowing about OWASP[1] helps.
Are there any e-commerce platforms that trust the client to do all the business logic for an order/checkout? If so how do they prevent client side tampering with the business logic without redoing it on the server side?
It seems a naive proposal at best to suggest the client would get business logic in lieu of the server. Typically clients need to assist users and they do that by use of business logic based validations and constraints.
Oh I agree but the GP seemed to indicate that trusting client side logic is a solved problem for web apps. I was curious if he had any sort of examples since it doesn't seem to be something related to the issues he listed.
we don't deliver all our business logic as JavaScript to the client, we just provide a nicer API. All security / scaling / business logic still lives server side.
Take hoodie.email.send(properties) as an example. It just the same as `POST /email` with email properties JSON, with the only difference that it's simpler to understand and to handle for frontend people, and it works offline (syncs when connection is back).
Can you give an example for why that signup code is bad? In the case that I'm using Hoodie with CouchDB, wouldn't Hoodie just AJAX post a user document to the CouchDB _users database (which is a good implementation)? All of the access control would be in the hands of the server with minimal (if any at all) security logic in the front end.
Yeah, but you're going to see a <form> 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.
I’m a Hoodie developer, I know what Hoodie does and doesn’t. That disclaimer is just there because some of the things don’t yet work as documented. The particular feature is definitely in existence :)
How is one of the first apps to popularize AJAX, developed on top of a proprietary cross-compiling framework by a top-3 web giant "no different" from Hoodie? Obviously you're getting at some specific point that is completely obscured by the ridiculousness of the comparison. Hopefully it's more than "client-side logic can be useful" because that much is obvious on its face. It's also obvious that the idealized promise of no-backend falls apart pretty quickly for a majority of real world apps. So what is your point exactly?
Sorry, from “delivering business logic to the client” perspective, Hoodie is no different in concept on that angle. Lots of things are very different, of course :)
I've been delivering apps just like that for 15 years without problems. As far I can remember there hasn't been an single case where this would have been a real problem.
I'm well aware that it isn't a perfect solution but it just works.
looks cool on several levels: empowering people to build the things they want w/o being "1337", volunteer driven, a "noBackend"/"One Backend Per User" (http://www.infoq.com/presentations/private-backend) default for a freer internet, and named after one of the most versatile articles of clothing ever invented.
the hoodie-server repo clocks in at just under 3k lines of javascript, though. i mean, there are a bunch of plugins, and wc is far from the best metric, but it's the only one that i've time for while this is still near the top of the list, so i'll just ask:
is this whole project to be viewed more as kick-ass-but-still-in-progress codebase or more like a socio-political statement about what happens when you make creating a single user's experience the priority (vs. trying to roll out an app that could scale your user base while still managing to own all their data)?
You basically nailed it :) — Hoodie is probably further along that it might seem. The team has been working on earlier iterations of this for nearly a decade now, and we have learned a lot along the way, allowing us to be very concise this time around. In addition, we have chosen a few powerful abstractions to make the actual implementation rather tiny.
That said, there is lots of work to be done, to make it, say, Rails, or Django-grade production ready, but the rough sketches are there and we are comfortable running a production app since December 2013, and we are working with a bunch of clients on their products, that we are comfortable with putting our reputation on the line for.
After 1.0 (we are pre), we want to be very explicit with the different levels of stability and maturity we ascribe to all parts of the system and the whole release overall. Our current production app handles 10k registered users on a small VPS without much sweat, so anywhere in that order of magnitude, with similar usage patterns, we thing Hoodie rocks the real-world, but if you are significantly diverging from this, we want to be careful and only recommend other’s to rely on Hoodie, when we have reasonable first or second hand experience of similar scale and use.
As for the socio-political statement: that’s definitely a big part of our motivation. We want to write and spread a story that isn’t the usual idea-vc-flip-sunset / abuse-overworking-cheating horror stories. And freeing data and empowering users is a future we want to see, so we are building it :)
>It took less than 15 minutes for a person with no experience in any part of the stack to take an existing single user app and make it a multi-user application with robust security and data storage. […] Bravo, hood.ie, brav-fucking-o.
You might like to see two of the Hoodie-ers talking at LXJS, and taking a skeleton app to supporting multiple users with data storage, the whole talk is 20 minutes, but the coding part is much, much less. https://www.youtube.com/watch?v=iyjwlvwOoA4&hd=1
I think you'll find that you can make a multiuser app from a single user app rather straightforwardly in a day. Although 15 mins would be only for a Q expert.
i building code generator with less then a second to create application. But more focus on business logic environment.All be cater such as header and master detail form.But like most generator code,there is overweight of code.Some code need to removed.The code are based on php.Have try to generate java crud form also but not satisfied with java generic issue.If somebody can help port to other language ,could be great.Sorry latest code don't put in the github yet.
I didn't realize there there was a name for it. Nobackend. catchy. I use SharePoint server as a nobackend solution. All the apps I write are client-side JavaScript. User profiles, permissions, and authentication are left to SharePoint to deal with. I create lists, query and update them via web services provided out of the box. Even search is provided by a web service, so I don't have to worry about indexing content. All I have to do is build user-centric clients for dealing with the data. It's brilliant.
Hoodie sounds like a great generalization for that, in a public/non-corporate domain. Plus it has events for displaying data changes immediately. What's not to like?
We're working on a similar no-backend product called Hoist that does most of what Hoodie is but is a hosted solution. We do all the 'server' work so you can just build your app. We provide API's for everything from Data management (just post and get JSON) and user management. We're also working on integrating other cloud company API's so you can quickly get hooked up to them (and do the auth with tokens) on the server side and then use their API's in a fully client-side app.
Our client library is entirely open source, but our platform itself is not as it's a commercial no-backend offering. This allows us to offer production-grade hosting for these types of no-backend apps.
Many companies offer production-grade hosting for open source applications. The fact that you are keeping your source closed tells me that you are afraid a competitor (or your clients themselves) could achieve an equivalent quality of hosting for less than they would pay you. To a customer like me, this is bad news.
We absolutely think that open sourcing code is important, but not just a giant lump of all of it; a mountain of code not always useful.
It's still early days for us but we are considering open sourcing reusable parts of our platform or allowing people to host their own if they wish, but we haven't yet decided on which we will pursue yet.
Moving from a request based business logic to data based business logic (processing incoming data, as opposed to processing incoming http requests) is an interesting shift. Does anyone know what this kind of system is called? I'd love to do more research.
Heya @reconbot, I don’t know if this specific system has a name, but it is something akin to a messaging bus, where clients and servers just exchange messages, if they have a network connection. Messages can carry raw data (a user record), or intents (send this email), and both sides agree on what to do with certain types of messages. Hope this helps! :)
In addition: Meteor data is public by default, and the architecture is always online, whereas Hoodie data is private by default, and the architecture is offline by default.
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.
As discussed before here on hn (https://news.ycombinator.com/item?id=5514284), this seems like a great successor (or at least a well-maintained alternative) to CouchApps and Kanso. I will definitively give it a try once PouchDB becomes a dependency :)
I suspect this is in the documentation, but I'll ask here anyways: what does Hoodie do with the browser-cached data when a user signs out? Is it entirely removed from the local machine, or does it persist so the user can login while the machine is still offline?
(I suspect there is an attack vector there, though I've not looked into it at all.)
Less than you might think. It's not a trivial matter to get an .ie domain. The IEDR's rules make things difficult if you can't either (a) demonstrate a connection with Ireland the reviewer will accept or (b) demonstrate that you trade in the Irish market. There are ways around some of their rules, such as getting a registered business name from the CRO, but it really is a pain in the backside.
I write this as somebody who works for one of the biggest .ie registrars.
Isn't creating an Irish company relatively easy (if you are in EU)? I guess its a fair amount of work and cost to get a nice name if you dont want a company...
Comparatively speaking, yes, but they're registered in Germany, so that wouldn't fly. It looks like they used a proxy registrant and some well placed fibs to acquire the domain name, which is one of the more dicey ways to go about it as the IEDR aren't afraid to pull registrations.
Much safer and saner is to get a Registered Business Name number from the CRO. It doesn't cost much, you have it practically forever, and it's possible for private citizens and foreign corps to get them.
It's also notoriously painful to register a .ie domain. You need some connection to Ireland, but even if you do there are restrictions on what you can register (needing to have a company name or registered business name matching the domain, for example). They have loosened up considerably on the discretionary domains, but it still seems to take at least a week to get your registration approved and completed.
End users only ever see JavaScript in the frontend. Some backend heavy lifting is done in Node and developers can extend that writing plugins in Node as well.
Yeah, it looks like the target audiences squarely overlap.
https://en.wikipedia.org/wiki/AppJet doesn’t look like it had a focus on offline-first. And Hoodie is not a hosted platform but an Open Source project more akin to Rails.
In addition, Hoodie is not interested in VC and flipping to Google later ;)
Yes I am aware of it. I also like it a lot. The Q Platform is able to interoperate with that Q library as well as with Angular, etc.
There are also several languages named Q. I don't think "Q Platform" is the same thing as a promises framework. It's not even for Javascript only. So why downvote the platform because there is something named similar to it?
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 people whose only job is to ensure security and fix vulnerabilities in your login system. It's also open-source, so you can vet it for yourself.
The JS library needs more work though - I could think of several basic use cases that it can't handle. It would also be great to see some full examples. Overall this is very cool stuff.