Hoodie: very fast web app development
hood.ie
hood.ie
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')
users.create('testuser', 'testing', {roles: ['example']}, function (err){});
session.login('testuser', 'testing', function (err, response){}});
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.)
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.
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.
The value of Hoodie is putting everything together into a way that a jQuery / backbone dev can be productive with.
It sounds like you are way more advanced, as such, you will have a way easier time managing all the pieces.
> Why?
Because we like building apps that way :)
jQuery / backbone dev can be productive with
Why? - that was more what are the benefits to me as a LAMP / backbone dev to using Hoodie, as opposed to are you enjoying yourself, which seems evident :-)
> I am not clear on that - is that "someone who does not / cannot develop on a tradiational server backend (LAMP etc). How does Hoodie help them
$ hoodie new app
$ cd app
$ jitsu create
$ jitsu push
> How do you handle network downtime?
Waiting.
> or two clients changing one backend resource with downtime?
p2p sync with conflict detection as provided by CouchDB.
> that was more what are the benefits to me as a LAMP / backbone dev to using Hoodie, as opposed to are you enjoying yourself, which seems evident :-)
While you are capable of doing all the heavy lifting, why not focus on building great apps? Or if your thing is running backends for people who build the apps, why not give them Hoodie and take the day off? :)
That isn't what "peer to peer" means, though. Peer to peer means that peers (the aforementioned browser, smartphone and tablet) communicate directly with each other.
Also, how does CouchDB keep things secure if clients can sync apparently any data? I'm assuming there's something there, but nobody else has explained this.
First, CouchDB supports security and validation.
Second, for CouchDB replication is just another client connecting to a DB; it's handled the same way anything else is.
As a result, we have the notion of filtered replication. The server-side CouchDB won't tell anyone secrets they don't need to know - be they clients or client-side DBs. At at the other end, the client-side CouchDB has some validation to stop "bad" data going into the database by accident, and then the server-side CouchDB has the same validation again. People can compromise their client DB all they want, but eventually it all ends up on the wire as plain old HTTP requests interacting with a plain old REST API.
In many ways - as far as security goes - the client DB is a red herring. The server ONLY speaks a well-defined REST API, and has validation and security to deal with malformed or malicious API requests. The fact that those requests are generated by a client-side DB based on data entered into it via JS commands is neither here nor there; a Backbone app would generate the exact same requests based on more-or-less the same JS commands. If you can secure any REST API, you can secure CouchDB.
another way to think about this (from the old days) is that disconnected mode data is a given because the rate of growth of data is far greater than the rate of growth of bandwidth. So everyone can't always be accessing all their data in the cloud through an always on infinite bandwidth connection.
So you're going to need to carry a subset of your data with you - the subset that's "hot".
Now having said that keeping hot data in sync with the larger data store is a hard problem - p2p or not.
And what these architectures (CouchDB, PouchDB, ...) do is take the sync problem and make it an infrastructure issue so it only has to be solved once by the infrastructure creator (CouchDB team) rather than again and again and again by each app developer who wakes up in the middle of the night and realizes they have to solve "sync" in their app as an application problem. Then they have a nightmare and when they wake up they are babbling.
The additional anti-pattern-badness with sync-in-the-app is that that kind of sync is usually incompatible with another app's bespoke sync. But when sync is in the infrastructure then a much larger group of people who use that infrastructure can share data across apps if they want to without having necessarily to share a schema. This is the real power of making sync part of the underlying computing fabric.
Finally when this infrastructure is open source the real -danger of lock-in such as when you use Dropbox is mitigated, should you want to have that freedom.
Cheers.
Browser <---> Server <---> DB
It's simple and it justs works. Almost every website you use works this way. But for webapps, it's not always ideal. Let's discuss some of the issues:
First off, this architecture is "always online". If the browser loses connection to the server, then when your user clicks on a button nothing will happen. Not too bad in a desktop environment, but with laptops or - especially - mobile clients this isn't ideal.
Worse, what if you're trying to keep the state in sync with multiple clients (like Trello does)? You're probably using websockets or long polling or similar techniques so that the server can tell clients about the actions of other clients. A network hiccup might cause you to miss one of these updates; detecting and recovering from this sort of sync error is problematic. Generally the solution is to throw away the last few bits of work the user did, and force a full reload and re-fetch the current state. Which is fine, in most cases. Unless the work the user is difficult to replicate, or if the application state is quite large. Trello takes a second or two to grab the current cards; if your app takes 30s to grab its data, you may want to avoid this though. :)
In fact, the more you want to replicate the feel and functionality of a classic desktop app, while allowing multiple users and clients, the more you start to struggle against this architecture.
What other architectures are there? Well, there's one obvious one:
Browser <---> CouchDB <---> Workers
CouchDB also has a _changes feed that makes a lot of sync tasks very easy. It also does master/master replication, and is generally a really nice database to work with from a devops point of view. Still, we're missing a crucial bit of magic to really improve over a classic three tier webapp. And that is...
...local DBs, in the form of PouchDB for browsers or TouchDB (apparently called Couchbase Mobile these days, although confusingly it's unrelated to Couchbase, which in turn is unrelated to CouchDB. Don't ask.) for Android/iOS. CouchDB is really really good at syncing and replicating, so now we have a new architecture:
Browser/Mobile App <--> PouchDB/TouchDB <--> CouchDB <--> Workers
So to directly answer your questions:
First, Kanso (by default) wants to do something like:
Browser <--> CouchDB
Hoodie Client <--> Hoodie Server <--> CouchDB
Backbone <---> Python <---> Postgres
But for the project I'm working on right now, we decided that wasn't quite good enough. :)
If I'm writing an email in the Gmail app on Android, what I want when I hit send is for the app to save the email locally, and then do its best to try and deliver it. Ditto for, basically, every other app on the phone that talks to a remote server. If I try and send a tweet, I want it to go "sure", and then be able to go on about my business while it works in the background. (And, again, that's how the actual twitter app works.)
And if I'm using some app that lets me take notes about a meeting or interview and syncs them with the cloud, I sure as HELL want to be able to take those notes and save them locally, even if the cloud sync had to be delayed. "Sorry Mr. CEO, but I can't seem to get wifi in this meeting room. Can we go out on the balcony and you just run back over those last few points?"
Now, yeah, I need some way of checking to see if it has actually sent the email or whatever. And if it fails, a notification that it has done so is not amiss. Mobile apps, typically, already do this sort of thing. (For gmail for android, you can check the outbox to look for unsent emails, and I believe twitter for android will notify you if it fails to send a tweet.)
To the extent that you're just saying that the app needs to have a UI which doesn't lie or surprise the user, then I agree wholeheartedly. If the user cares whether or not the cloud has been updated, or the message has actually been sent, don't lie and claim it has when it hasn't!
But if you're saying that as a general rule we need to not handle network sync stuff in the background, I think that's nuts. Nobody wants to sit there with an email draft open hitting send every so often to see if the 3G signal is good enough to talk to the mail server yet. Nor do we want to save a bunch of emails as drafts when offline, then have to go open each one when we get net access again and send them. (Come to that, in your model, could we even save an email as a draft in gmail without net access? Remember, the drafts folder is synced. Do we want the app to claim that a draft has been saved when it's not accessible from your desktop gmail client? Isn't that another case of "pretending we've saved a draft when it's not really saved"? If not, why not?)
TL;DR: Good UI that doesn't lie to the user is important. That's not a good reason to cripple your apps functionality so it doesn't do anything you can lie about.
Couchbase for Mobile is what we call the umbrella (including our Sync Gateway which adds multi-user access control with more scale and flexibility than CouchDB, but compatible with the same sync protocol).
Of course it's all open source with a very active community. Join us here: https://groups.google.com/forum/m/#!forum/mobile-couchbase
So from my little perspective, couchdb does replication over network, you are leveraging that to create apps that can queue network events locally and get on with other work, and that one definition of a record can easily be used in JS, local store and remote.
Seems nice. I remember another thread recently with a discussion on replacing the standby icon. At some point someone drew up a series of dynamic I ins showing network state - fully synched, uploading, fetching etc.
Your project is addressing a new and previously unknown need for users to have a mental model of - remote synch.
Always be working in growth areas :-)
My homework (along with everything else !)
1. How does couchdb replicate and what are its failure points (nothing is magic but you seem to like it - I will have to have a look. I assume erlang is not running in IOS - I will read up
Thank you for taking the time to cudgel new knowledge into an old brain
Cheers
I spent a while typing of descriptions of how it works, but honestly I think you're best served by these two answers:
http://stackoverflow.com/a/4766398/17086
https://github.com/couchbaselabs/TouchDB-iOS/wiki/Replicatio...
It's not magic, no. It does, however, work a lot like git (a good thing!). The biggest downside is that it pushes some of the work to the client; you really do have to figure out how to handle conflicts in some cases. For example, if you edit the same field on the same doc in different ways on two different clients and then try to sync, there is no automatic way to resolve that other than throwing one edit away (which you can totally do if that works for your problem space). Luckily, that's not a very common situation. :) And, again, how else are you going to solve something like that? It all comes back to the CAP theorem - you can have at most two of consistency, availability, and partition tolerance. Rich mobile apps can work around a lack of consistency if they must, but a lack of availability and partition tolerance undermines the "mobile" part; for some projects (like mine) that is unacceptable.
As for TouchDB, if memory serves it actually was running an erlang VM at one point, but has long since been rewritten into native Objective C (for the iOS version) and Java (for the Android version). The PouchDB version is written purely in Javascript. Again, all that matters in the end is that it speaks the protocol. As @caolan put it, CouchDB is not a database:
http://caolanmcmahon.com/posts/couchdb_is_not_a_database/
It's a protocol. :)
Hoodie allows me to build things in days that would usually take me weeks and in some cases require additional people. This gives me more time to experiment, refine, user test etc. It also lets me delegate with ease: I don't want or need full control and responsibility over the server and the db and many security aspects, not for what I do. I'll happily pay nodejitsu and iriscouch for that, because they know more about this stuff than I could ever learn in the time it takes me to make the money to pay them.
That was my moment of clarity: Hoodie lets me get on with what I want to do and what I'm good at, and it's really got my back on many of the things I have neither the skill nor the patience nor the money for.
[Citation Needed]
We start with a dream API, and build from there.
Do you plan on supporting other databases? Wouldn't that be a ton of work?
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.
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.
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.
The other proto-pedias and Minecraft-could-have-beens never happened at all - for some people, they stayed on the drawing board and never made it to the web - so there's no evidence of them to point to at all. They left no trace.
For example, friends of mine like to go climbing. They've build an app in an afternoon, just for their group, to keep track of what tracks they finished and how they liked it. I think this is fascinating. I wonder what would happen if students would learn to build simple apps like that in school, instead of Excel?
This was the old dream of Hypercard, and it worked very well for a long time. http://en.wikipedia.org/wiki/HyperCard
Both Danny Goodman and Bill Atkinson have stated publicly that they got programming questions from every kind of person: small business owners, school teachers, ski bums, taxi drivers, etc.
Hypercard let non-programmers build simple apps, and so a lot of apps were created that would never have been created if app-creation was left in the hands of professional programmers. And many of those little apps were tailored to what the creator needed at that moment, in a way that could never happen if a professional programmer drew up some spec.
If there is a school that is teaching people Excel, there is a problem with the school, and I'm not sure having easy frameworks solves that problem.
To be pedantic, Excel would be the perfect tool for writing an app like this. A few columns, a quick and dirty VBA GUI... Bob's your uncle
http://www.greenleafbookgroup.com/blog/2011/10/12/whats-the-...
(etc. etc. [seriously google it if you're interested])
I wish people would focus less on fast development and more
on something that better maintainability 2 years down the road.
An app built with hoodie I could see as being maintainable- even as you gut the entire stack and drag your rails app to flask, or your php app to java, hoodie has defined only the kinds of objects and patterns of accessing them that you'll reuse in whatever your actual app stack is. Hoodie targets the data, which is the thing. Everything else? Who cares. Here's to maintainable data.
I ask this because of the description found on the Github page: 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
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.
shouldn't be hard to make one for Angular. Happy to help
I posted the job on Elance, Freelancer, and Odesk if anyone is interested.
Elance: https://www.elance.com/job/40077787/proposals Freelancer: http://www.freelancer.com/projects/Javascript-Software-Archi... ODesk: https://www.odesk.com/jobs/Create-Hoodie-AngularJS-adapter-w...
Behind the scenes, Hoodie takes care of account creation,
email validation and all the boring backend tasks you have
to think of.
Am I being dense, or is this like a nice client framework that still needs to talk AJAX to the backend, so still needs to allow oAuth, so still needs to change code if the API changes, and so on.
"We just want to make apps, and add billing by Monday" is a bit worrying as a goal to me...
edit: oh, so this stubs out the server side at the client ? It seems like the same amount of work to keep backbone models in synch with the server as it does to keep hoodie? What do I gain?
Hoodie comes with a backend that does all that stuff that can only be sensibly done server-side for you.
> edit: oh, so this stubs out the server side at the client ? It seems like the same amount of work to keep backbone models in synch with the server as it does to keep hoodie? What do I gain?
@gr2m can you take this one?
Hoodie comes with a backend that does all that stuff that
can only be sensibly done server-side for you.
Edit: I take back the MS jab - unnecessary when simply trying to understand something. My apologies
Edit: No harm done :)
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!
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.
dr: http://jlouisramblings.blogspot.co.uk/2013/01/how-erlang-doe... ff.
> Hoodie currently only runs on OS X
Oh, a hipster framework.
hoodie is basically CouchDB + node.js, nothing fancy. We just do local DNS magic, creating *.dev domains like http://pow.cx/, that is only compatible with Mac atm
Never attribute to hipsterism what could adequately be explained with picking priorities :)
The hoodie backend works anywhere node and Couch work (anywhere, really), it’s just that the local dev setup with the fancy domains and everything is tailored to Mac OS X. We have Linux support in the works.
Pull requests > Witty comments
And a presentation from earlier at @berlinjs including a live demo: https://www.youtube.com/watch?v=X3Ttb0BD8pg
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?)
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.
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 Were happy to help
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 :)
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.
2. Security handling is purely server-side. You can’t fake your way without using a proper auth-channel.
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.
How does this compare to, say, Meteor?
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.
See 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.
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...
Interesting choice of couchdb. Any reasons for that compared to the alternatives?
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.
[Disclaimer: I've spent a total of 5-10 minutes reading about hoodie.]
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.
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".
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!
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.
"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.
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.
The SEO issue is a stronger argument but Googlebot now seems to be executing javascript in some cases so even that might cease to be an issue.
Hoodie is more of a tool for applications, with user authentication etc, so SEO is not relevant here. I wouldn't build a public website with Hoodie.
> Also, something else that really trouble me with javascript client-side is that, often, when something bugs, everything just stop working
Yes. That's something we have to handle if we want dynamic web apps build on web technologies. But there are great tools today that help you 1. prevent JavaScript by automated testing in all the browsers / OS 2. track JavaScript errors, e.g. with errorception. And 3. todays browsers are more relaxed about errors, they try to continue running the app, even if one function errored out.
> Is there a better solution than a hard-refresh? Would a first-level try/catch solve this problem
If you can keep the state of an app and store user's data immediately, there is no big problem to reload the page, I do that in several occasions at minutes.io, the user usually doesn't realize, it's very fast.
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.
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.
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.
See you again tomorrow CEST. <3
A few questions. What is the strategy is for concurrent modification of data? What are the consistency guarantees for the sync operation?