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

61–70 of 155 posts

Re: Hoodie: very fast web app development

#61

Post by Lazare »

gr2m wrote: post #54
Lazare wrote: post #45

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…

Key difference: kan.so is Couch specific. Hoodie is not. We do not try to make another nice library to wrap CouchDB. We try to make a nice JavaScript API for the most common backend tasks. We start with a dream API, and build from there.

But for now, Hoodie only works with Couch, no?

Do you plan on supporting other databases? Wouldn't that be a ton of work?

Re: Hoodie: very fast web app development

#62

Post by gr2m »

Lazare wrote: post #60
lifeisstillgood wrote: post #52

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…

Lazare, this is awesome, thanks so much! Let us know if you'd like to look closer into Hoodie, happy to assist

Re: Hoodie: very fast web app development

#63

Post by gr2m »

Lazare wrote: post #61
gr2m wrote: post #54

Earlier quoted context omitted.

Key difference: kan.so is Couch specific. Hoodie is not. We do not try to make another nice library to wrap CouchDB. We try to make a nice JavaScript API for the most common backend tasks. We start with a dream API, and build from there.

But for now, Hoodie only works with Couch, no? Do you plan on supporting other databases? Wouldn't that be a ton of work?

Yes. And Yes. But hey, totally worth it. I'm happy to support anyone trying to make a hoodie.js for other backends. Let's do this

Re: Hoodie: very fast web app development

#65

Post by janl »

Lazare wrote: post #60
lifeisstillgood wrote: post #52

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…

Nailed it!

Re: Hoodie: very fast web app development

#66

Post by rgbrgb »

Lazare wrote: post #45

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…

The biggest difference from where I'm sitting is that Kanso hasn't been updated in 10 months.

https://github.com/kanso/kanso

Re: Hoodie: very fast web app development

#68

Post by espylaub »

lifeisstillgood wrote: post #52
Lazare wrote: post #45

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…

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…

"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 myself, on a solid, proven base, with super-fast setup, easy deployment, offline capability and syncing. And these last two don't even need to be actively invoked, they're just there and they just work. That's practically magical from where I stand.

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.

Re: Hoodie: very fast web app development

#69

Post by old-gregg »

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!

Re: Hoodie: very fast web app development

#70

Post by espylaub »

Lazare wrote: post #60
lifeisstillgood wrote: post #52

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…

Wow, thanks a lot for that, spot on!
Post reply on HN