Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Hoodie: very fast web app development

hood.ie

Post reply on HN
Print view View original

131–140 of 155 posts

Re: Hoodie: very fast web app development

#131

Post by lkrubner »

gr2m wrote: post #130
gbog wrote: post #124

Earlier quoted context omitted.

> [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 b…

Let's say today 1 of 1000 people is able to create an app to solve a problem, let's say time time tracking. Now imagine we change that drastically, to 100 of 1000 or even more. People will start to build their own little apps to solve their own little problems. And if these break, nobody cares, but them. For example, friends of mine like to go climbing. They've build an app in an afternoon, just for their group, to k…

"Now imagine we change that drastically, to 100 of 1000 or even more. People will start to build their own little apps to solve their own little problems. And if these break, nobody cares, but them."

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.

Re: Hoodie: very fast web app development

#132

Post by goofygrin »

gbog wrote: post #124
wodow wrote: post #118

Earlier quoted context omitted.

> ... 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.

> [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 b…

Although I agree with sentiment of your post, actually the publication date of a novel and the release date of new furniture lines are very important [the same with music, movies and just about anything where we have enough data to do trend analysis].

http://www.greenleafbookgroup.com/blog/2011/10/12/whats-the-...

(etc. etc. [seriously google it if you're interested])

Re: Hoodie: very fast web app development

#133

Post by Lazare »

tarabukka wrote: post #122
janl wrote: post #58

Earlier quoted context omitted.

this is many-client-server. p2p sync enables you opening your Hoodie app on your browser, smartphone and tablet at the same time and make it all work, even when some or all of the devices are offline for short or long periods of time :) > 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 crea…

> p2p sync enables you... 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.

The trick is twofold:

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.

Re: Hoodie: very fast web app development

#134

Post by espylaub »

Mahn wrote: post #117
akrymski wrote: post #115

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…

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.

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

Re: Hoodie: very fast web app development

#135

Post by OGC »

janl wrote: post #71
old-gregg wrote: post #69

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 bein…

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.

To rephrase the other question: So what "magic" does Erlang do then? How does it work?

Re: Hoodie: very fast web app development

#136

Post by lifeisstillgood »

Lazare wrote: post #111
lifeisstillgood wrote: post #103

Earlier quoted context omitted.

Wow, thank you. 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 dynam…

CouchDB's replication is nifty because, in a sense, there is no replication. Or rather, not in the sense that MySQL or MongoDB might talk about replication as a separate process or separate protocol. 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.…

Thank you.

Re: Hoodie: very fast web app development

#137

Post by [deleted] »

lkrubner wrote: post #131
gr2m wrote: post #130

Earlier quoted context omitted.

Let's say today 1 of 1000 people is able to create an app to solve a problem, let's say time time tracking. Now imagine we change that drastically, to 100 of 1000 or even more. People will start to build their own little apps to solve their own little problems. And if these break, nobody cares, but them. For example, friends of mine like to go climbing. They've build an app in an afternoon, just for their group, to k…

"Now imagine we change that drastically, to 100 of 1000 or even more. People will start to build their own little apps to solve their own little problems. And if these break, nobody cares, but them." 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 ever…

[deleted]

Re: Hoodie: very fast web app development

#138

Post by janl »

Lazare wrote: post #133
tarabukka wrote: post #122

Earlier quoted context omitted.

> p2p sync enables you... 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.

The trick is twofold: 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 validat…

Yet again, spot on, thanks @Lazare!

Re: Hoodie: very fast web app development

#139

Post by taylonr »

gr2m wrote: post #130
gbog wrote: post #124

Earlier quoted context omitted.

> [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 b…

Let's say today 1 of 1000 people is able to create an app to solve a problem, let's say time time tracking. Now imagine we change that drastically, to 100 of 1000 or even more. People will start to build their own little apps to solve their own little problems. And if these break, nobody cares, but them. For example, friends of mine like to go climbing. They've build an app in an afternoon, just for their group, to k…

>I wonder what would happen if students would learn to build simple apps like that in school, instead of Excel?

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.

Re: Hoodie: very fast web app development

#140

Post by janl »

OGC wrote: post #135
janl wrote: post #71

Earlier quoted context omitted.

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.

To rephrase the other question: So what "magic" does Erlang do then? How does it work?

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-doe... ff.

Post reply on HN