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.
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.
You do realize that by putting it in your documentation, you're encouraging people to use it.
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 :)
EDIT: Thanks for your answer, I am going to stop crossposting now :D
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.
But thanks for your feedback, much appreciated!
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.
The documentation and tutorials will be a big focus going forward
If you don't have a backend ninja in your dev team, you should take a serious look into Hoodie!
But he was one of the speakers at re:publica two weeks ago in Berlin as well as one of the moderators of the Global Innovation Lounge that was streamed by voicerepublic.
They should fix it by not pushing those minor state changes to history, though. Probably an easy fix.
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.
Hoodie also relies on sponsorships, donations, gittip and other sources of revenue: http://blog.hood.ie/2014/01/how-is-hoodie-funded/
And here are a ton of more talks, slide decks, podcast links to Hoodie and closely related topics Offline First and noBackend: http://blog.hood.ie/2014/05/talks-about-hoodie-offlinefirst-...
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.
It is the weirdest description of Meteor I have seen so far.
Meteor is all about helping developers to build excellent web apps with ease and spending less time, not providing APIs.
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.
(Disclaimer: Team Hoodie again :) )
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.
will there be ways to manage some complex ACL scenarios ?
If you have a specific scenario in mind, I'm happy to elaborate.
Missing boom, shot, now lru-cache...down the rabbit hole.
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).
I'm actually surprised so few companies have implemented it thus far.
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.
Thanks for the pointer to Jeremiah, though :)
"This document describes functionality and features that don't exist yet."
I'm well aware that it isn't a perfect solution but it just works.
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)?
anyway, it seems like some of each.
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 :)
I find that extremely hard to believe.
I would have left that part out. Partly because it doesn't really roll off the tongue well, and partly because it comes across as hubris.
Given that Hoodie’s whole focus is on hiding backend complexities, it is not too far fetched, though.
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.
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?
Check it out: http://hoistapps.com
Would love to hear what anyone thinks if you give it a go. I can be emailed on firstname.lastname@example.org
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.
More details: http://www.niden.net/2009/12/world-with-part-1-reviewhow-to....
Meteor (and Derby etc) is a full stack JS setup, where you manage both the browser and node.
Both do data sync.
(I suspect there is an attack vector there, though I've not looked into it at all.)
Will report back shortly.
I write this as somebody who works for one of the biggest .ie registrars.
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.
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 ;)
https://github.com/zoePage/hoodie-drawing is an example app.
Not released yet -- but if someone has PHP / JS / PhoneGap skillz and wants to work with us, you can be an early member of the community.