Live data from Hacker News

Hoodie: very fast web app development

hood.ie

111–120 of 155 posts

Re: Hoodie: very fast web app development

#111
post #60

Earlier quoted context omitted.

Okay, first off, let's discuss a standard three tier webapp architecture: Browser Server DB You get some HTML/CSS/JS from the server, you display stuff to the user. As the user interacts with your app, HTTP requests hit your server which processes them. As needed, the server will make requests to the DB, which will reply with data, which then gets passed back to the browser. Everyone knows how this stack works, I hop…

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

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

Re: Hoodie: very fast web app development

#112
post #60

Earlier quoted context omitted.

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…

Okay, first off, let's discuss a standard three tier webapp architecture: Browser Server DB You get some HTML/CSS/JS from the server, you display stuff to the user. As the user interacts with your app, HTTP requests hit your server which processes them. As needed, the server will make requests to the DB, which will reply with data, which then gets passed back to the browser. Everyone knows how this stack works, I hop…

For someone just starting to code, and looking specifically to work on web apps, this was such a well articulated response. I really appreciated it.

Re: Hoodie: very fast web app development

#113
post #102

Earlier quoted context omitted.

If my phone has no signal I'd rather see an error message. I don't want the app to pretend everything is fine when that's not the case. If I press "Delete" in the app, don't pretend the thing is deleted if it's not really deleted yet, that's deceptive. What if I take off on my boat and I press "Send" and your app says "Sent!" but it's really not sent because now I've left the coast--your app just lied to me.

With all due respect, I think you're wrong. 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, thanks for another thoughtful response.

Re: Hoodie: very fast web app development

#114
post #96

Earlier quoted context omitted.

"Moment of clarity" is a great cue. To me, Hoodie is enormously empowering (which is why I'm part of the Hoodie team). As a self-taught, non comp-sci frontend dev with a humanities degree I can get all the backend/DB stuff sorted, definitely, but I'd actually rather not. It's difficult and occasionally arcane. I don't enjoy it. And, let's face it, I can make terrible mistakes. With Hoodie, I can quickly build apps by…

> on a solid, proven base [Citation Needed]

Ah, sorry, I was referring to couchDB (which does sync and offline for us), not Hoodie itself. That's still very much under construction, of course.

Re: Hoodie: very fast web app development

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

Re: Hoodie: very fast web app development

#117

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.

Re: Hoodie: very fast web app development

#118

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

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

Re: Hoodie: very fast web app development

#119

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…

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.

Re: Hoodie: very fast web app development

#120

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?

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

Post reply on HN