Hoodie – Fast web app development(hood.ie)
hood.ie
Hoodie – Fast web app development
http://hood.ie/
32 コメント
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.
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.
"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."
You do realize that by putting it in your documentation, you're encouraging people to use it.
You do realize that by putting it in your documentation, you're encouraging people to use it.
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 :)
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
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).
Yeah, we are working on a website redesign that addresses this. So much to do, so little time :)
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.
But thanks for your feedback, much appreciated!
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!
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].
[0]: https://github.com/hoodiehq/hoodie.js/issues/8
[1]: http://pouchdb.com/
[0]: https://github.com/hoodiehq/hoodie.js/issues/8
[1]: http://pouchdb.com/
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.
Since that's the heart of the problem being solved, it's weird when the docs leave it out.
Excellent point. We will make this more clear.
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.
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
The documentation and tutorials will be a big focus going forward
That is correct :)
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!
If you don't have a backend ninja in your dev team, you should take a serious look into Hoodie!
Would you happen to know if there are any videos of his talks online?
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].
1. http://re-publica.de/user/2037/event/1
2. https://voicerepublic.com/venues/196#archived-talks
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].
1. http://re-publica.de/user/2037/event/1
2. https://voicerepublic.com/venues/196#archived-talks
See http://blog.hood.ie/2014/05/talks-about-hoodie-offlinefirst-... for a few pointers :)
Broken back button, bleh.
And you thought you were just scrolling... turns out you were navigating.
That is obnoxious as hell.
I kind of like having the page state in the URL like that - makes sending someone a link easier. See also: Discourse.
They should fix it by not pushing those minor state changes to history, though. Probably an easy fix.
They should fix it by not pushing those minor state changes to history, though. Probably an easy fix.
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.
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.
Team Hoodie here. Happy to answer any questions you might have :)
Hoodie is supported by a bootstrapped company run by the core devs, who put the profits back into Hoodie: http://blog.hood.ie/2014/05/welcome-to-the-neighbourhoodie/
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-...
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-...
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.
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.
> Meteor is about exposing backend and frontend APIs to the browser
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.
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.
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.
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.
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.
Some more infos here: https://news.ycombinator.com/item?id=7768434
Apologies for asking such a horrible question, but is there a rough timeline for it being production ready? It looks very interesting.
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.
(Disclaimer: Team Hoodie again :) )
(Disclaimer: Team Hoodie again :) )
Thanks.
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 :)
How exactly did you convince the IEDR to let you have hood.ie?
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.
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.
Well given that one of the hood.ie developers is called Caolan McMahon, I'm guessing there's an Irish granny involved somewhere ;-)
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... :-)
What are the ways that we can support the project as individuals?
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.
Also Gittip: https://www.gittip.com/hoodiehq/ <3 :)
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 ?
will there be ways to manage some complex ACL scenarios ?
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.
If you have a specific scenario in mind, I'm happy to elaborate.
Is it just me or are there some dependency management issues?
Missing boom, shot, now lru-cache...down the rabbit hole.
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
Can we finally save public data?
Are you ready for a production level app?
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.
That's great! 10k user base is a good number and I am sure it covers many 'real life' problems.
So let's just deliver all our business logic as JavaScript to an entirely untrustworthy client! Whats the worst that could happen?
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.
[1] https://www.owasp.org/index.php/Main_Page
[1] https://www.owasp.org/index.php/Main_Page
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?
An e-commerce platform on Hoodie would also do final validations 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).
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).
Hoodie works no different than Gmail. What’s the worst that can happen there?
On a related note, how does MailChimp have "confirm subscription" link IN MY GMAIL LIST?
http://cl.ly/image/1o1K2f202T3c
http://cl.ly/image/1o1K2f202T3c
It's a Gmail feature called "Actions" and was launched back in 2013:
https://developers.google.com/gmail/actions/actions/actions-...
I'm actually surprised so few companies have implemented it thus far.
https://developers.google.com/gmail/actions/actions/actions-...
I'm actually surprised so few companies have implemented it thus far.
Gmail's "Actions" API.
https://developers.google.com/gmail/actions/reference/one-cl...
https://developers.google.com/gmail/actions/reference/one-cl...
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.
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.
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.
They have frontend code that will talk to /singup or whatever the route for creating an account is. Hoodie does nothing different.
Thanks for the pointer to Jeremiah, though :)
Thanks for the pointer to Jeremiah, though :)
the signup seems to be handled by couchdb.
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."
"This document describes functionality and features that don't exist yet."
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 :)
There, I fixed it :)
https://github.com/espy/hoodie-plugin-tutorial/pull/13
https://github.com/espy/hoodie-plugin-tutorial/pull/13
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.
I'm well aware that it isn't a perfect solution but it just works.
Hoodie has plugins, so you're not limited to client-side only logic.
http://hood.ie/#plugins
http://hood.ie/#plugins
Sharing the business logic is less of an issue than the business metrics that get leaked when you include user ID's in your source code.
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)?
anyway, it seems like some of each.
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)?
anyway, it seems like some of each.
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 :)
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.
I find that extremely hard to believe.
I find that extremely hard to believe.
>brav-fucking-o
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.
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.
Yeah, same here, but it’s a testimonial we received :)
Given that Hoodie’s whole focus is on hiding backend complexities, it is not too far fetched, though.
Given that Hoodie’s whole focus is on hiding backend complexities, it is not too far fetched, though.
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
You should try to head to http://github.com/EGreg/Q and try it out :)
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 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?
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.
Check it out: http://hoistapps.com
Would love to hear what anyone thinks if you give it a go. I can be emailed on [email protected]
Check it out: http://hoistapps.com
Would love to hear what anyone thinks if you give it a go. I can be emailed on [email protected]
Cool! Glad to see more of this on the table :)
Hood.ie is open source, and your code is not. Any chance you can open source your code?
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.
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.
Interestingly enough this is a very similar business model to GetAngular, where AngularJS originated, a few years ago.
http://web.archive.org/web/20100413141437/http://getangular....
More details: http://www.niden.net/2009/12/world-with-part-1-reviewhow-to....
http://web.archive.org/web/20100413141437/http://getangular....
More details: http://www.niden.net/2009/12/world-with-part-1-reviewhow-to....
So this appears to essentially be a Parse-like service that's self-hostable? Interesting.
Exactly. Plus it's self-extandable, too. And expect many hoodie hosting providers popping up in the future, if you don't want that hassle.
So I'm looking at their "Account" api, and I wonder if something similar like that exists for node just for the backend.
Not really the same, but Passport offers easy account authentication.
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! :)
Event-driven architecture
client-server architecture?
How does this compare/contrast to Meteor?
Hoodie provides a backend for you, you manage the browser.
Meteor (and Derby etc) is a full stack JS setup, where you manage both the browser and node.
Both do data sync.
Meteor (and Derby etc) is a full stack JS setup, where you manage both the browser and node.
Both do data sync.
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.
[deleted]
I suppose it's better than "Bro"...
I guess this means that the sample web app no longer breaks if it's kept running for 15 minutes? Or is that problem still around?
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
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.)
(I suspect there is an attack vector there, though I've not looked into it at all.)
The default is keeping the data, but app devs can implement a pruning method as well, to make things suitable for shared browsers and such.
I'm not sure if it's just me, but I think this site hijacks my 'back' button. I'm trying to get a recreate but I'm having some trouble.
Will report back shortly.
Will report back shortly.
Just realized .ie is an excellent TLD for cute website names
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.
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.
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.
Getting .ie domains is a pain in the ass. Tons of great domain hacks there but requires a physical presence in Ireland. Good work.
Nice.but the website i see only source code. so kinda confuse how large system can build fast by noob.
Seems like I should've seen this on the latest episode of Silicon Valley.
Didn't appjet (yc 20xx) try this same idea a few years ago?
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 ;)
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 ;)
Couldn't find the example link? Is there one?
There are API samples further down the main page on http://hood.ie
https://github.com/zoePage/hoodie-drawing is an example app.
https://github.com/zoePage/hoodie-drawing is an example app.
You guys should take a look at http://github.com/EGreg/Q
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.
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.
In case you were unaware, there's a very popular and lovely promises library for javascript named q.
https://github.com/kriskowal/q
https://github.com/kriskowal/q
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?
Another example: http://en.wikipedia.org/wiki/X_Window_authorization
https://dev.twitter.com/docs/oauth/xauth
https://www.google.com/support/enterprise/static/postini/doc...
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?
Another example: http://en.wikipedia.org/wiki/X_Window_authorization
https://dev.twitter.com/docs/oauth/xauth
https://www.google.com/support/enterprise/static/postini/doc...
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.