20 ms·

Hoodie: very fast web app development

474 points by bpierre 14y ago

taybin 14y ago
I think promising "we want to enable you to build complete web apps in days" might be promising too much. Programming is difficult, there is no silver bullet, and a different data store certainly won't change that. Interesting choice of couchdb. Any reasons for that compared to the alternatives?
- ConstantineXVI 14y ago
  If I had to guess, the fact that HTTP and JSON are CouchDB's native tongue (removing the need for a middleman in front of the DB) was likely a factor.
  - janl 14y ago
    That, and that CouchDB has Sync already figured out. Hoodie didn’t have to invent this. Sync is hard, leave it to the experts.
- gr2m 14y ago
  tay, I'm one of the developers behind hoodie. I agree that there is no silver bullet for apps, and Hoodie does not try to be one. Our main goal is to enable as many people as possible to build real, data driven apps. Think of it this way: if you're able today to build the frontend of an app in days, then you've all it takes. Our maxim is: if you get jQuery, you should be able to build apps with user accounts, data synchronization, emails ... the basic, boring stuff.
- nilkn 14y ago
  hoodie strikes me as more of a local optimum rather than a global one. In other words, it's not a universal silver bullet and wouldn't be suitable for all tasks. But for the tasks for which it is suited, perhaps it can eliminate a lot of boilerplate. [Disclaimer: I've spent a total of 5-10 minutes reading about hoodie.]
  - janl 14y ago
    Anyone trying for a global maximum will fail :) We designed Hoodie with very few, but very specific use cases, to get the core right. The more use cases we’ll add, the broader it will get, but we have no intention of pleasing everyone.
- Lazare 14y ago
  If you want to have a local DB in the browser, and a remote DB in the cloud, your choices are basically CouchDB or a ton of pain reinventing the wheel. Replication and syncing are hard. In other words, for the very specific problem they're trying to solve, I don't think there ARE a lot of alternatives except "abandon local storage, and work directly against a DB in the cloud".
danso 14y ago
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 https://github.com/hoodiehq/hoodie.js hoodie is a JavaScript library that runs in your browser. It gives you user authentication data storage and sync sharing emails and so much more None of these things are really handled by the client-side frameworks mentioned above, so I'm wondering if Hoodie is basically drop-in easy for existing projects.
- gr2m 14y ago
  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 browser.
  - RaphiePS 14y ago
    A lot of my Angular code is glue for the backend, so this would be an absolute godsend.
    - gr2m 14y ago
      I've made a backbone adapter a while a go: https://github.com/hoodiehq/hoodie.js/blob/master/stuff/backbone-hoodie.coffee https://github.com/hoodiehq/hoodie.js/blob/master/stuff/back... shouldn't be hard to make one for Angular. Happy to help
      - jjsz 14y ago
        I'm looking for someone to translate this into an angular adapter and combine it with Yeoman's 1.0b4's AngularJS generator, among other things to test out hoodie. If you were already going to do it, might as well do it sooner than later and get payed for it! :-) I posted the job on Elance, Freelancer, and Odesk if anyone is interested. Elance: https://www.elance.com/job/40077787/proposals https://www.elance.com/job/40077787/proposals Freelancer: http://www.freelancer.com/projects/Javascript-Software-Architecture/Create-Hoodie-AngularJS-adapter-with.html http://www.freelancer.com/projects/Javascript-Software-Archi... ODesk: https://www.odesk.com/jobs/Create-Hoodie-AngularJS-adapter-with-Yeoman-0b4-Angular-Generator_~~deb45ba3ee122d03 https://www.odesk.com/jobs/Create-Hoodie-AngularJS-adapter-w...
janl 14y ago
Hey there, other @hoodiehq dev here. Here is a bit longer intro to Hoodie: http://hood.ie/intro.html http://hood.ie/intro.html And a presentation from earlier at @berlinjs including a live demo: https://www.youtube.com/watch?v=X3Ttb0BD8pg https://www.youtube.com/watch?v=X3Ttb0BD8pg
- jufo 14y ago
  Nice presentation. In the description of back end modules, you mention payments as a future capability. What kind of payment service would you be able to work with? (I don't see how you could handle card details in the Hoodie architecture). Thanks.
  - gr2m 14y ago
    we definitely won't send any credit card information to a hoodie server. Instead we use a service like stripe, but then receive the payment notifications or errors, which lets us notify the user if payment worked or not.
eranation 14y ago
Self hosted Firebase, nice! How do you handle permissions by the way? is it the same concept as Firebase's? how do you handle data validation? (e.g. preventing users gaming the data, e.g. saving all their stolen ebooks in your system by using a console, or just cheating in a game by doing illegal moves?)
- gr2m 14y ago
  permissions is handled directly by CouchDB. Every user has an own database that only he/she has access to. Synchronization between accounts can be done via shares. We don't have validation at the moment. You can store whatever you like, it's just JSON. We could add validation at some point, but it's currently not on our agenda. We try to keep it really simple at the moment, getting the core right, then empowering others to build modules on top of it.
- janl 14y ago
  CouchDB has validations, we just don’t use them yet, you are welcome to, though :)
tempaccount9473 14y ago
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.
- gr2m 14y ago
  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/ http://pow.cx/, that is only compatible with Mac atm
  - greendestiny 14y ago
    Have you guys seen syncpoint? Although having said that, syncpoint seems to have been removed from github.
    - jchrisa 14y ago
      It was an old experiment of mine. See upthread for the Couchbase Lite stuff that has replaced it.
      - greendestiny 14y ago
        Thanks, I'll check that out.
  - wambotron 14y ago
    I'm on windows 8 primarily, but I also run osx and mint. I'm going to check this out on osx first, if all is good, I can help ensure windows compatibility.
    - gr2m 14y ago
      that's great, thanks!
- janl 14y ago
deleted 14y ago
[deleted]
mikhuang 14y ago
Hoodie devs: Just out of curiosity, what frontend framework (if any) is used on minutes.io?
- gr2m 14y ago
  backbone
scrambam 14y ago
It's hard to get excited by yet-another-client-framework. So what?
bsaul 14y ago
@hoodiehq : are you using something similar to PouchDB ?
- janl 14y ago
  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.
  - daleharvey 14y ago
    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)
    - gr2m 14y ago
      <3
- gr2m 14y ago
  we currently use localStorage. But we <3 PouchDB, just didn't get to it yet. Shouldn't be hard to change that, or to build your own store wrapper providing the same API
fnayr 14y ago
definitely going to check this out in depth soon, and build some "dreamcode" with it to test it out!
- janl 14y ago
  That’s the Hoodie Spirit <3 :D
ZenJosh 14y ago
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?
- janl 14y ago
  Nothing, all they can do is fuck up their own data.
  - alexaasp 14y ago
    Which sounds kind of bad, if that is the case. 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.
    - janl 14y ago
      1. what if that idiot messes with gmail’s web console? 2. Security handling is purely server-side. You can’t fake your way without using a proper auth-channel.
      - alexaasp 14y ago
        The distinction here is that Hoodie is supposed to free you from dealing with servers, but that is currently limited to scenarios where you have users with uniform access privileges and no concerns about users messing around with their database information. So until they add modules most projects will have to get down and dirty in the end if they want to attach any kind of privileges to users. In both points 1 and 2 you need to have some server side logic beyond Hoodie.
        janl 14y ago
        Hoodie can only promise to free you from worrying about the backend by providing one that you can just use. The sharing module e.g. makes heavy use of server side logic and database security and access control features. The Hoodie frontend just makes it accessible to frontend devs.
hayksaakian 14y ago
It's odd that no one's mentioned it yet, but this reminds me most of Meteor. How does this compare to, say, Meteor?
- gr2m 14y ago
  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.
  - janl 14y ago
    We love Meteor though :)
beefsack 14y ago
I'm a Unix developer and would love to have a play, a little bit disheartening to see that the installation instructions are OS X exclusive.
- gr2m 14y ago
  so sorry that we didn't get to it yet. Hoodie is certainly not OS X exclusive, we just have some DNS magic that helps developing locally, that's Mac only at the moment. Hoodie is just Node.js & CouchDB, you should be able to run it without too much trouble. Try to follow the instructions here: https://github.com/hoodiehq/hoodie-app/issues/35 https://github.com/hoodiehq/hoodie-app/issues/35 Were happy to help
- janl 14y ago
  I’m a Unix dev too, check out my beard in the linked video :D Like mentioned elsewhere in this thread, other *nixen support is in the works. Hoodie core is platform agnostic, we just chose Mac as the dev environment because we figured that was what most people use. We are definitely not exclusive and would love to see any help towards getting it run on other systems :)
Lazare 14y ago
Unlike a lot of comments here, I don't need to be sold on the concept. As luck would have it, I am actively building an app that runs mostly in the browser using CouchDB, Kanso, and PouchDB. It's a pretty amazing tech stack; I get a local DB in the browser, which I can sync with the main DB in the cloud the client is connected. Plus I get some nice APIs for stuff like sessions, registering users, security, validation, etc. I see you've already mentioned switching to PouchDB on your backend, and you're already using CouchDB for the cloud, so it seems like you're basically competing straight up against Kanso. So.... How is what you're doing different from what Kanso does? Why should I use Hoodie over Kanso? I see this code in your docs: hoodie.account.signUp('joe@example.com', 'secret') hoodie.account.signIn('joe@example.com', 'secret') Very nice. But Kanso has: users.create('testuser', 'testing', {roles: ['example']}, function (err){}); session.login('testuser', 'testing', function (err, response){}}); Seems like six of one, half a dozen of the other. What's your killer feature? Kanso has shaky documentation and is currently more aimed at couchapps (they strongly assume that you'll serve your frontend code from CouchDB), but I'm not sure how that really differs from Hoodie. :) If we take the overall architecture as a given (browser based app, PouchDB or equivalent for local storage, syncing with CouchDB in the cloud, and node workers handling the backend work), what's the focus of Hoodie that sets it apart from Kanso? (In any case, nice stuff. I think the concept is great, and there's definitely room for several competing frameworks in this space.)
- janl 14y ago
  Spot on! We stole a lot of ideas from the whole CouchDB application space. @caolan, the Kan.so dev is currently looking into Hoodie as well. As far as originality, we choose a different design approach. We want to cater to people who barely get jQuery and give them a tool to build larger apps. We are building the technology downwards from that idea towards the bits and pieces we have. One of the fun things about Hoodie is that there is nothing technically new in it. Existing ideas and tools are just put together a different way.
- lifeisstillgood 14y ago
  hi I am trying very hard not to be dumb, but this is beating me seemingly Kanso? and Hoodie both have JS stubs at the client and server end, these synch with each other, then synch with whatever you are using at client (say backbone) and server (node? CouchDB? My Postgres server behind my python app?) If thats roughly right, why do I do this? I control my server apps no? Why wrap them in another layer? Json->backbone is hardly a difficult synch operation - I mean its called synch(). I really am interested in understanding the philosophy and driving ideas here - everyone has a moment of clarity where they can see how to build an app or a framework, and how it will come together - I am not attacking you (yet !) - please describe your moment of clarity.
janl 14y ago
Alright, Team Hoodie is calling it a day. Thanks for the lively discussion and nice feedback, you’ve been great! :) See you again tomorrow CEST. <3
dylanz 14y ago
It's awesome when you read posts on HN about interesting things and realize your friends were involved. Congrats gr2m! (P.S... +1 for an Angular adapter =))
- gr2m 14y ago
  10 cary-minutes is all it takes ;-) Thanks Dylan
old-gregg 14y ago
I have a question for experts in Hoodie and/or other similar projects (like Meteor): How are database connections managed? If every client (browser) basically talks nearly directly to the database, don't you end up with of thousands of database connections? Large number of connections is not a problem by itself, and servers like nginx handle them well, but I am not aware of a database which will feel comfortable being exposed this way. MongoDB, for example, really starts struggling with 2K+ connections. PostgreSQL can barely handle a hundred. Is this why CouchDB is used? Is connection pooling used on the server? Or maybe the connections are short-lived and never persistent? Basically, how does this work with large number (say, 10K) of concurrent visitors? Thanks!
- janl 14y ago
  As long as the underlying OS can provide file descriptors, CouchDB can handle the concurrent connections through the magic of Erlang, both persistent and shorter lived. There are obvious limits to this, but the Hoodie architecture allows easy scale out (more DB servers and manual sharding, or a dynamo-like BigCouch, more workers etc.) that we’ll get to making use of once Hoodie apps become that big.
  - tarabukka 14y ago
    Magic of Erlang? I hate to be cynical, but have you got benchmarks to back that up?
    - janl 14y ago
      Yeah.
  - OGC 14y ago
    To rephrase the other question: So what "magic" does Erlang do then? How does it work?
    - janl 14y ago
      tl;dr: keeping sockets open only uses very little memory and no CPU when idle. dr: http://jlouisramblings.blogspot.co.uk/2013/01/how-erlang-does-scheduling.html http://jlouisramblings.blogspot.co.uk/2013/01/how-erlang-doe... ff.
vosper 14y ago
Apologies for an off-topic question - how did you go about registering a .ie domain name? I've been wanting to register one for a while, but the last time I looked there was a requirement to show proof of residency (or a business address) in Ireland. Edit: The reason I ask is that it seems like the developers are living in Zurich and Berlin, not Ireland. I live in SF, so can't fulfil the residency requirement.
- jodonovan 14y ago
  I was thinking the same. I had to provide copy of my Irish passport to get my .ie domain
- espylaub 14y ago
  No problem :) There are actually more than three of us working on Hoodie, one (actually two by now) of them an Irish national. The about section just lists the core team, if you will.
  - vosper 14y ago
    That makes sense. I guess I will just have to go without until they (eventually?) open up registration to foreigners! Thanks for taking the time to reply.
m_mueller 14y ago
Berlin and Zurich seem to be doing great lately. I'm also planning on building a startup in Zurich in the coming months. How about a Hacker News Zurich meetup?
- gr2m 14y ago
  Come to https://twitter.com/jszurich https://twitter.com/jszurich, or ping me at https://twitter.com/gr2m https://twitter.com/gr2m, happy to chat
- thomas11 14y ago
  Would be cool. We had one over a year ago, and the attendance was good, but no one organized a follow-up. See http://techup.ch http://techup.ch and meetup.com for what's going on in the tech meetup space in Zurich. I'm often at zhgeeks, jszurich, web tuesday.
- preek 14y ago
  Hi there, ZH citizen and heavy HN user here. We've got lots of talks in our company and a co-working space to go along. Would be awesome to host a HN meetup here. Ping me if you're interested in doing something together. http://www.meetup.com/Pantalks-tech-non-tech-talks-Panter-AG-Zurich/ http://www.meetup.com/Pantalks-tech-non-tech-talks-Panter-AG...
donjaime_hn 14y ago
Very cool :). A few questions. What is the strategy is for concurrent modification of data? What are the consistency guarantees for the sync operation?
- gr2m 14y ago
  In the current implementation, CouchDB takes care of it. In case of a conflict, both versions are kept, with one winner. The other version can be recovered and the conflict resolved, both automatically with a worker process or by the user.
d0m 14y ago
I know everyone hates that question.. (I hate it too), but what about non-js users or, maybe more importantly, SEO or crawlers? Honestly, this is what is holding me back to go pure client-side for most of my projects.. I know there's the phantomJS server-side hack but how does that work in practice? Also, something else that really trouble me with javascript client-side is that, often, when something bugs, everything just stop working. I.e. links don't work anymore, button obviously don't.. Is there a better solution than a hard-refresh? Would a first-level try/catch solve this problem? Thanks!
- verbalist 14y ago
  > non-js users the web is no longer just text. if you need to consume text then you need a text-api client, which is what web browsers used to be.
  - d0m 14y ago
    I know as tech people we're strong about using latest technologies and we like to think users are like us, but sadly, this is not the case. Actually, it really depends of your market. "the web is no longer just text" Although I can't deny that statement,I find it hard to convince myself that browsers can't read your page because no JS engines are running. I see it a little bit like emails.. yes, more recent clients give you a better interface or better features, but if I'm emailing someone who has a very old phone with very basic email support, I'm hoping that this person would still be able to read my message. I'd love to see what would happen if HN turned JS-enabled only for a day.
  - eevee 14y ago
    I run noscript. If I encounter a site that's broken or useless for seemingly no reason (e.g. not an interactive thing like Google Maps), I often don't even whitelist; I just leave. Relatedly, I've stopped clicking on Photobucket or Blogspot links. I kinda resent being expected to run your pile of arbitrary code just to render static text and images on my screen—something that worked just fine without JS twenty years ago.
    - 14y ago
dannyp32 14y ago
As a new web developer I'm very interested in this. Looks like a not so complex next step after building basic static websites.
- gr2m 14y ago
  Welcome to Hoodie world :-)
gdonelli 14y ago
All art requires courage. ~Anne Tucker
laurentoget 14y ago
How does this compare with Firebase, besides offering a way to host everything locally?
treblig 14y ago
Test comment for http://hackerfollow.com http://hackerfollow.com
onemorepassword 14y ago
Looks lovely, but I wish people would focus less on fast development and more on something that better maintainability 2 years down the road. When it comes to the lifecycle of most applications, the speed of developing something new has a marginal impact on the overall costs, and most tools and frameworks than enable rapid initial development tend to suck once you have a big app on top of them. This is why we fawn over a tool when it's shiny and new, and bitch about how much it sucks 3 to 5 years later.
- mydoghasworms 14y ago
  You are very right in saying this, but I would have to contend that there is a large scope for quick-to-market apps and small, simple-purpose apps. In addition to that, it seems that many apps created today themselves have a limited lifespan, after which they are replaced by something else (though you can never tell upfront). The other side of the coin is building something with the intent of maintaining it for many years, only to find it is obsolete within 2. (Meaning that the "right tool for the job" cannot always be determined correctly in software development).
- wodow 14y ago
  > ... the speed of developing something new has a marginal impact on the overall costs But it has a large impact on the overall probability of getting off the ground at all - and this is what most projects (and people) never do.
  - gbog 14y ago
    > [dev speed has] a large impact on the overall probability of getting off the ground I don't know. This seems common sense but it could be a cliché too. If we look at other domains, it is not always true. For instance, if you write novels that are not tied to some evanescent trend like a pop star's private life, then the chance of getting off the ground if not directly linked to the timing of publication. It would be the same if you are creating a newly designed chair. Even on the web, let's take two success stories: when Wikipedia or Twitter were created and made public, I don't remember seeing five other contenders running behind them, and being only two-features-months behind. Same with, say, Minecraft. I am all for quick development, because it is more fun, but not because it would magically increase to probability of success, which is too low to compute and unpredictable anyway. I am also all for choosing carefully which path you take, especially when you cross virgin territories. You don't want to find yourself spending a night half naked with a toothpick for your sole defense in Borneo's jungle.
bencollier49 14y ago
Does "hoodie" mean "juvenile delinquent" in the US as well as the UK?
- bct 14y ago
  No.
akrymski 14y ago
so bots can sign up easily: while (true) { hoodie.account.signUp(_.uniqueId() + '@gmail.com', _.uniqueId()) } great effort though, but I still don't think you've got client/server separation right. we've built something very similar over a year ago: an offline client db backed by memory/websql/indexed-db that replicates with dynamo-db so the app works offline. Looked at Couch/Pouch solution but decided against Couch for performance reasons. Might open source it later once we figure out the user management/security bit. I still find the existing solutions (including Firebase) not ideal.
- Mahn 14y ago
  I was thinking there might be some sort of throttling/banning mechanism within the signUp function itself, but then being client based that could be easily circumvented unless there's some server side logic aswell. I wonder whether there's a sane way to handle this client side short of minify and/or obfuscate the code and hope for the best.
  - espylaub 14y ago
    Let me refer to a great answer Lazare gave further up (more generally about sync, but very useful nonetheless): https://news.ycombinator.com/item?id=5517632 https://news.ycombinator.com/item?id=5517632
- espylaub 14y ago
  You have the option of requiring user confirmation via email (right now users are auto-confirmed by default). Non-confirmed users only write to their localStorage (so they can still use the app pre signup), but nothing (apart from their tiny user object) is synced to the remote DB, nothing is parsed by workers, etc. Then write a worker to cull unconfirmed user objects after a while, and you should be fine. I don't know about additional throttling though, but it seems very doable. Disclaimer: this isn't my area of expertise, but the rest of the Hoodie team are quite confident about this issue, and I trust them. The other two are currently travelling, but if you have more questions, I'm sure one of them will get back to you with more in-depth info.
je42 14y ago
How is hoodie solving / handling conflicts when its syncing local storage to the remote database ?
cupofjoakim 14y ago
I'm very interested in using this together with emberjs, but honestly I'm having trouble understanding what Hoodie actually does. Why do I need Hoodie to go with my CouchDB? Is it only for the local storage?

474 points by bpierre 14y ago

I think promising "we want to enable you to build complete web apps in days" might be promising too much. Programming is difficult, there is no silver bullet, and a different data store certainly won't change that. Interesting choice of couchdb. Any reasons for that compared to the alternatives?

ConstantineXVI 14y ago
If I had to guess, the fact that HTTP and JSON are CouchDB's native tongue (removing the need for a middleman in front of the DB) was likely a factor.
- janl 14y ago
  That, and that CouchDB has Sync already figured out. Hoodie didn’t have to invent this. Sync is hard, leave it to the experts.
gr2m 14y ago
tay, I'm one of the developers behind hoodie. I agree that there is no silver bullet for apps, and Hoodie does not try to be one. Our main goal is to enable as many people as possible to build real, data driven apps. Think of it this way: if you're able today to build the frontend of an app in days, then you've all it takes. Our maxim is: if you get jQuery, you should be able to build apps with user accounts, data synchronization, emails ... the basic, boring stuff.
nilkn 14y ago
hoodie strikes me as more of a local optimum rather than a global one. In other words, it's not a universal silver bullet and wouldn't be suitable for all tasks. But for the tasks for which it is suited, perhaps it can eliminate a lot of boilerplate. [Disclaimer: I've spent a total of 5-10 minutes reading about hoodie.]
- janl 14y ago
  Anyone trying for a global maximum will fail :) We designed Hoodie with very few, but very specific use cases, to get the core right. The more use cases we’ll add, the broader it will get, but we have no intention of pleasing everyone.
Lazare 14y ago
If you want to have a local DB in the browser, and a remote DB in the cloud, your choices are basically CouchDB or a ton of pain reinventing the wheel. Replication and syncing are hard. In other words, for the very specific problem they're trying to solve, I don't think there ARE a lot of alternatives except "abandon local storage, and work directly against a DB in the cloud".

danso 14y ago

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 https://github.com/hoodiehq/hoodie.js hoodie is a JavaScript library that runs in your browser. It gives you user authentication data storage and sync sharing emails and so much more None of these things are really handled by the client-side frameworks mentioned above, so I'm wondering if Hoodie is basically drop-in easy for existing projects.

gr2m 14y ago
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 browser.
- RaphiePS 14y ago
  A lot of my Angular code is glue for the backend, so this would be an absolute godsend.
  - gr2m 14y ago
    I've made a backbone adapter a while a go: https://github.com/hoodiehq/hoodie.js/blob/master/stuff/backbone-hoodie.coffee https://github.com/hoodiehq/hoodie.js/blob/master/stuff/back... shouldn't be hard to make one for Angular. Happy to help
    - jjsz 14y ago
      I'm looking for someone to translate this into an angular adapter and combine it with Yeoman's 1.0b4's AngularJS generator, among other things to test out hoodie. If you were already going to do it, might as well do it sooner than later and get payed for it! :-) I posted the job on Elance, Freelancer, and Odesk if anyone is interested. Elance: https://www.elance.com/job/40077787/proposals https://www.elance.com/job/40077787/proposals Freelancer: http://www.freelancer.com/projects/Javascript-Software-Architecture/Create-Hoodie-AngularJS-adapter-with.html http://www.freelancer.com/projects/Javascript-Software-Archi... ODesk: https://www.odesk.com/jobs/Create-Hoodie-AngularJS-adapter-with-Yeoman-0b4-Angular-Generator_~~deb45ba3ee122d03 https://www.odesk.com/jobs/Create-Hoodie-AngularJS-adapter-w...

janl 14y ago

Hey there, other @hoodiehq dev here. Here is a bit longer intro to Hoodie: http://hood.ie/intro.html http://hood.ie/intro.html And a presentation from earlier at @berlinjs including a live demo: https://www.youtube.com/watch?v=X3Ttb0BD8pg https://www.youtube.com/watch?v=X3Ttb0BD8pg

jufo 14y ago
Nice presentation. In the description of back end modules, you mention payments as a future capability. What kind of payment service would you be able to work with? (I don't see how you could handle card details in the Hoodie architecture). Thanks.
- gr2m 14y ago
  we definitely won't send any credit card information to a hoodie server. Instead we use a service like stripe, but then receive the payment notifications or errors, which lets us notify the user if payment worked or not.

eranation 14y ago

Self hosted Firebase, nice! How do you handle permissions by the way? is it the same concept as Firebase's? how do you handle data validation? (e.g. preventing users gaming the data, e.g. saving all their stolen ebooks in your system by using a console, or just cheating in a game by doing illegal moves?)

gr2m 14y ago
permissions is handled directly by CouchDB. Every user has an own database that only he/she has access to. Synchronization between accounts can be done via shares. We don't have validation at the moment. You can store whatever you like, it's just JSON. We could add validation at some point, but it's currently not on our agenda. We try to keep it really simple at the moment, getting the core right, then empowering others to build modules on top of it.
janl 14y ago
CouchDB has validations, we just don’t use them yet, you are welcome to, though :)

tempaccount9473 14y ago

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.

gr2m 14y ago
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/ http://pow.cx/, that is only compatible with Mac atm
- greendestiny 14y ago
  Have you guys seen syncpoint? Although having said that, syncpoint seems to have been removed from github.
  - jchrisa 14y ago
    It was an old experiment of mine. See upthread for the Couchbase Lite stuff that has replaced it.
    - greendestiny 14y ago
      Thanks, I'll check that out.
- wambotron 14y ago
  I'm on windows 8 primarily, but I also run osx and mint. I'm going to check this out on osx first, if all is good, I can help ensure windows compatibility.
  - gr2m 14y ago
    that's great, thanks!
janl 14y ago

deleted 14y ago

[deleted]

mikhuang 14y ago

Hoodie devs: Just out of curiosity, what frontend framework (if any) is used on minutes.io?

gr2m 14y ago
backbone

scrambam 14y ago

It's hard to get excited by yet-another-client-framework. So what?

bsaul 14y ago

@hoodiehq : are you using something similar to PouchDB ?

janl 14y ago
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.
- daleharvey 14y ago
  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)
  - gr2m 14y ago
    <3
gr2m 14y ago
we currently use localStorage. But we <3 PouchDB, just didn't get to it yet. Shouldn't be hard to change that, or to build your own store wrapper providing the same API

fnayr 14y ago

definitely going to check this out in depth soon, and build some "dreamcode" with it to test it out!

janl 14y ago
That’s the Hoodie Spirit <3 :D

ZenJosh 14y ago

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?

janl 14y ago
Nothing, all they can do is fuck up their own data.
- alexaasp 14y ago
  Which sounds kind of bad, if that is the case. 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.
  - janl 14y ago
    1. what if that idiot messes with gmail’s web console? 2. Security handling is purely server-side. You can’t fake your way without using a proper auth-channel.
    - alexaasp 14y ago
      The distinction here is that Hoodie is supposed to free you from dealing with servers, but that is currently limited to scenarios where you have users with uniform access privileges and no concerns about users messing around with their database information. So until they add modules most projects will have to get down and dirty in the end if they want to attach any kind of privileges to users. In both points 1 and 2 you need to have some server side logic beyond Hoodie.
      - janl 14y ago
        Hoodie can only promise to free you from worrying about the backend by providing one that you can just use. The sharing module e.g. makes heavy use of server side logic and database security and access control features. The Hoodie frontend just makes it accessible to frontend devs.

hayksaakian 14y ago

It's odd that no one's mentioned it yet, but this reminds me most of Meteor. How does this compare to, say, Meteor?

gr2m 14y ago
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.
- janl 14y ago
  We love Meteor though :)

beefsack 14y ago

I'm a Unix developer and would love to have a play, a little bit disheartening to see that the installation instructions are OS X exclusive.

gr2m 14y ago
so sorry that we didn't get to it yet. Hoodie is certainly not OS X exclusive, we just have some DNS magic that helps developing locally, that's Mac only at the moment. Hoodie is just Node.js & CouchDB, you should be able to run it without too much trouble. Try to follow the instructions here: https://github.com/hoodiehq/hoodie-app/issues/35 https://github.com/hoodiehq/hoodie-app/issues/35 Were happy to help
janl 14y ago
I’m a Unix dev too, check out my beard in the linked video :D Like mentioned elsewhere in this thread, other *nixen support is in the works. Hoodie core is platform agnostic, we just chose Mac as the dev environment because we figured that was what most people use. We are definitely not exclusive and would love to see any help towards getting it run on other systems :)

Lazare 14y ago

Unlike a lot of comments here, I don't need to be sold on the concept. As luck would have it, I am actively building an app that runs mostly in the browser using CouchDB, Kanso, and PouchDB. It's a pretty amazing tech stack; I get a local DB in the browser, which I can sync with the main DB in the cloud the client is connected. Plus I get some nice APIs for stuff like sessions, registering users, security, validation, etc. I see you've already mentioned switching to PouchDB on your backend, and you're already using CouchDB for the cloud, so it seems like you're basically competing straight up against Kanso. So.... How is what you're doing different from what Kanso does? Why should I use Hoodie over Kanso? I see this code in your docs: hoodie.account.signUp('joe@example.com', 'secret') hoodie.account.signIn('joe@example.com', 'secret') Very nice. But Kanso has: users.create('testuser', 'testing', {roles: ['example']}, function (err){}); session.login('testuser', 'testing', function (err, response){}}); Seems like six of one, half a dozen of the other. What's your killer feature? Kanso has shaky documentation and is currently more aimed at couchapps (they strongly assume that you'll serve your frontend code from CouchDB), but I'm not sure how that really differs from Hoodie. :) If we take the overall architecture as a given (browser based app, PouchDB or equivalent for local storage, syncing with CouchDB in the cloud, and node workers handling the backend work), what's the focus of Hoodie that sets it apart from Kanso? (In any case, nice stuff. I think the concept is great, and there's definitely room for several competing frameworks in this space.)

janl 14y ago
Spot on! We stole a lot of ideas from the whole CouchDB application space. @caolan, the Kan.so dev is currently looking into Hoodie as well. As far as originality, we choose a different design approach. We want to cater to people who barely get jQuery and give them a tool to build larger apps. We are building the technology downwards from that idea towards the bits and pieces we have. One of the fun things about Hoodie is that there is nothing technically new in it. Existing ideas and tools are just put together a different way.
lifeisstillgood 14y ago
hi I am trying very hard not to be dumb, but this is beating me seemingly Kanso? and Hoodie both have JS stubs at the client and server end, these synch with each other, then synch with whatever you are using at client (say backbone) and server (node? CouchDB? My Postgres server behind my python app?) If thats roughly right, why do I do this? I control my server apps no? Why wrap them in another layer? Json->backbone is hardly a difficult synch operation - I mean its called synch(). I really am interested in understanding the philosophy and driving ideas here - everyone has a moment of clarity where they can see how to build an app or a framework, and how it will come together - I am not attacking you (yet !) - please describe your moment of clarity.

janl 14y ago

Alright, Team Hoodie is calling it a day. Thanks for the lively discussion and nice feedback, you’ve been great! :) See you again tomorrow CEST. <3

dylanz 14y ago

It's awesome when you read posts on HN about interesting things and realize your friends were involved. Congrats gr2m! (P.S... +1 for an Angular adapter =))

gr2m 14y ago
10 cary-minutes is all it takes ;-) Thanks Dylan

old-gregg 14y ago

I have a question for experts in Hoodie and/or other similar projects (like Meteor): How are database connections managed? If every client (browser) basically talks nearly directly to the database, don't you end up with of thousands of database connections? Large number of connections is not a problem by itself, and servers like nginx handle them well, but I am not aware of a database which will feel comfortable being exposed this way. MongoDB, for example, really starts struggling with 2K+ connections. PostgreSQL can barely handle a hundred. Is this why CouchDB is used? Is connection pooling used on the server? Or maybe the connections are short-lived and never persistent? Basically, how does this work with large number (say, 10K) of concurrent visitors? Thanks!

janl 14y ago
As long as the underlying OS can provide file descriptors, CouchDB can handle the concurrent connections through the magic of Erlang, both persistent and shorter lived. There are obvious limits to this, but the Hoodie architecture allows easy scale out (more DB servers and manual sharding, or a dynamo-like BigCouch, more workers etc.) that we’ll get to making use of once Hoodie apps become that big.
- tarabukka 14y ago
  Magic of Erlang? I hate to be cynical, but have you got benchmarks to back that up?
  - janl 14y ago
    Yeah.
- OGC 14y ago
  To rephrase the other question: So what "magic" does Erlang do then? How does it work?
  - janl 14y ago
    tl;dr: keeping sockets open only uses very little memory and no CPU when idle. dr: http://jlouisramblings.blogspot.co.uk/2013/01/how-erlang-does-scheduling.html http://jlouisramblings.blogspot.co.uk/2013/01/how-erlang-doe... ff.

vosper 14y ago

Apologies for an off-topic question - how did you go about registering a .ie domain name? I've been wanting to register one for a while, but the last time I looked there was a requirement to show proof of residency (or a business address) in Ireland. Edit: The reason I ask is that it seems like the developers are living in Zurich and Berlin, not Ireland. I live in SF, so can't fulfil the residency requirement.

jodonovan 14y ago
I was thinking the same. I had to provide copy of my Irish passport to get my .ie domain
espylaub 14y ago
No problem :) There are actually more than three of us working on Hoodie, one (actually two by now) of them an Irish national. The about section just lists the core team, if you will.
- vosper 14y ago
  That makes sense. I guess I will just have to go without until they (eventually?) open up registration to foreigners! Thanks for taking the time to reply.

m_mueller 14y ago

Berlin and Zurich seem to be doing great lately. I'm also planning on building a startup in Zurich in the coming months. How about a Hacker News Zurich meetup?

gr2m 14y ago
Come to https://twitter.com/jszurich https://twitter.com/jszurich, or ping me at https://twitter.com/gr2m https://twitter.com/gr2m, happy to chat
thomas11 14y ago
Would be cool. We had one over a year ago, and the attendance was good, but no one organized a follow-up. See http://techup.ch http://techup.ch and meetup.com for what's going on in the tech meetup space in Zurich. I'm often at zhgeeks, jszurich, web tuesday.
preek 14y ago
Hi there, ZH citizen and heavy HN user here. We've got lots of talks in our company and a co-working space to go along. Would be awesome to host a HN meetup here. Ping me if you're interested in doing something together. http://www.meetup.com/Pantalks-tech-non-tech-talks-Panter-AG-Zurich/ http://www.meetup.com/Pantalks-tech-non-tech-talks-Panter-AG...

donjaime_hn 14y ago

Very cool :). A few questions. What is the strategy is for concurrent modification of data? What are the consistency guarantees for the sync operation?

gr2m 14y ago
In the current implementation, CouchDB takes care of it. In case of a conflict, both versions are kept, with one winner. The other version can be recovered and the conflict resolved, both automatically with a worker process or by the user.

d0m 14y ago

I know everyone hates that question.. (I hate it too), but what about non-js users or, maybe more importantly, SEO or crawlers? Honestly, this is what is holding me back to go pure client-side for most of my projects.. I know there's the phantomJS server-side hack but how does that work in practice? Also, something else that really trouble me with javascript client-side is that, often, when something bugs, everything just stop working. I.e. links don't work anymore, button obviously don't.. Is there a better solution than a hard-refresh? Would a first-level try/catch solve this problem? Thanks!

verbalist 14y ago
> non-js users the web is no longer just text. if you need to consume text then you need a text-api client, which is what web browsers used to be.
- d0m 14y ago
  I know as tech people we're strong about using latest technologies and we like to think users are like us, but sadly, this is not the case. Actually, it really depends of your market. "the web is no longer just text" Although I can't deny that statement,I find it hard to convince myself that browsers can't read your page because no JS engines are running. I see it a little bit like emails.. yes, more recent clients give you a better interface or better features, but if I'm emailing someone who has a very old phone with very basic email support, I'm hoping that this person would still be able to read my message. I'd love to see what would happen if HN turned JS-enabled only for a day.
- eevee 14y ago
  I run noscript. If I encounter a site that's broken or useless for seemingly no reason (e.g. not an interactive thing like Google Maps), I often don't even whitelist; I just leave. Relatedly, I've stopped clicking on Photobucket or Blogspot links. I kinda resent being expected to run your pile of arbitrary code just to render static text and images on my screen—something that worked just fine without JS twenty years ago.
  - 14y ago

dannyp32 14y ago

As a new web developer I'm very interested in this. Looks like a not so complex next step after building basic static websites.

gr2m 14y ago
Welcome to Hoodie world :-)

gdonelli 14y ago

All art requires courage. ~Anne Tucker

laurentoget 14y ago

How does this compare with Firebase, besides offering a way to host everything locally?

treblig 14y ago

Test comment for http://hackerfollow.com http://hackerfollow.com

onemorepassword 14y ago

Looks lovely, but I wish people would focus less on fast development and more on something that better maintainability 2 years down the road. When it comes to the lifecycle of most applications, the speed of developing something new has a marginal impact on the overall costs, and most tools and frameworks than enable rapid initial development tend to suck once you have a big app on top of them. This is why we fawn over a tool when it's shiny and new, and bitch about how much it sucks 3 to 5 years later.

mydoghasworms 14y ago
You are very right in saying this, but I would have to contend that there is a large scope for quick-to-market apps and small, simple-purpose apps. In addition to that, it seems that many apps created today themselves have a limited lifespan, after which they are replaced by something else (though you can never tell upfront). The other side of the coin is building something with the intent of maintaining it for many years, only to find it is obsolete within 2. (Meaning that the "right tool for the job" cannot always be determined correctly in software development).
wodow 14y ago
> ... the speed of developing something new has a marginal impact on the overall costs But it has a large impact on the overall probability of getting off the ground at all - and this is what most projects (and people) never do.
- gbog 14y ago
  > [dev speed has] a large impact on the overall probability of getting off the ground I don't know. This seems common sense but it could be a cliché too. If we look at other domains, it is not always true. For instance, if you write novels that are not tied to some evanescent trend like a pop star's private life, then the chance of getting off the ground if not directly linked to the timing of publication. It would be the same if you are creating a newly designed chair. Even on the web, let's take two success stories: when Wikipedia or Twitter were created and made public, I don't remember seeing five other contenders running behind them, and being only two-features-months behind. Same with, say, Minecraft. I am all for quick development, because it is more fun, but not because it would magically increase to probability of success, which is too low to compute and unpredictable anyway. I am also all for choosing carefully which path you take, especially when you cross virgin territories. You don't want to find yourself spending a night half naked with a toothpick for your sole defense in Borneo's jungle.

bencollier49 14y ago

Does "hoodie" mean "juvenile delinquent" in the US as well as the UK?

bct 14y ago
No.

akrymski 14y ago

so bots can sign up easily: while (true) { hoodie.account.signUp(_.uniqueId() + '@gmail.com', _.uniqueId()) } great effort though, but I still don't think you've got client/server separation right. we've built something very similar over a year ago: an offline client db backed by memory/websql/indexed-db that replicates with dynamo-db so the app works offline. Looked at Couch/Pouch solution but decided against Couch for performance reasons. Might open source it later once we figure out the user management/security bit. I still find the existing solutions (including Firebase) not ideal.

Mahn 14y ago
I was thinking there might be some sort of throttling/banning mechanism within the signUp function itself, but then being client based that could be easily circumvented unless there's some server side logic aswell. I wonder whether there's a sane way to handle this client side short of minify and/or obfuscate the code and hope for the best.
- espylaub 14y ago
  Let me refer to a great answer Lazare gave further up (more generally about sync, but very useful nonetheless): https://news.ycombinator.com/item?id=5517632 https://news.ycombinator.com/item?id=5517632
espylaub 14y ago
You have the option of requiring user confirmation via email (right now users are auto-confirmed by default). Non-confirmed users only write to their localStorage (so they can still use the app pre signup), but nothing (apart from their tiny user object) is synced to the remote DB, nothing is parsed by workers, etc. Then write a worker to cull unconfirmed user objects after a while, and you should be fine. I don't know about additional throttling though, but it seems very doable. Disclaimer: this isn't my area of expertise, but the rest of the Hoodie team are quite confident about this issue, and I trust them. The other two are currently travelling, but if you have more questions, I'm sure one of them will get back to you with more in-depth info.

je42 14y ago

How is hoodie solving / handling conflicts when its syncing local storage to the remote database ?

cupofjoakim 14y ago

I'm very interested in using this together with emberjs, but honestly I'm having trouble understanding what Hoodie actually does. Why do I need Hoodie to go with my CouchDB? Is it only for the local storage?