11–20 of 25 posts
In fact, the bad old days are still with us, as most applications still rely on fragile custom code, running in an application server like Ruby on Rails, Python's Django, or some kinda Java thing. I'm pretty sure the fragility of the code is as much down to the person writing it as it is to the platform. I don't think it's fair to say that application servers are inherently fragile; run Python or Java apps on App Eng…
In fact, the bad old days are still with us, as most applications still rely on fragile custom code, running in an application server like Ruby on Rails, Python's Django, or some kinda Java thing. I'm pretty sure the fragility of the code is as much down to the person writing it as it is to the platform. I don't think it's fair to say that application servers are inherently fragile; run Python or Java apps on App Eng…
Part of an app server like Django et al being flexible is giving you the ability to shoot yourself in the foot. It is much harder to screw something up royally when you are working within the CouchApp constraints. That's what I meant by fragile.
Google App Engine gets this mostly right by enforcing draconian timeout limits and other constraints, so it is much harder to write an app that is gonna fall over under a big wave of traffic, as the sandbox will complain right away.
CouchApp is even more picky. The programming model doesn't have operations that could block on remote IO, so you can't even go down the bad path. Of course, when you do need to send an email, you've got to rethink how to do it. (Actually in a real app you'd do email from an asynchronous task as well.)
Compare the the closest NoSQL alternative, MongoDB. I say close because they are both document stores (fancy key/value) with indexing and map/reduce.
MongoDB is very lean and blazing fast. But there isn't anything close to an HTTP layer in Mongo. It speaks in a binary JSON protocol. The format, commands, and driver, while well done, are a whole new set of rules to learn. Plus a Ruby middleware to talk HTTP.
My conclusions are from writing a simple app with both backends. Punchline: After all this experimentation I realize I need a relational DB for my project.
The article says that writes can be validated so only authorised users may write. Does anybody know if its possible to limit read access to certain users? If so, I may revive an abandoned project and try it as a CouchApp.
This is really cool, especially with companies now providing CouchDB hosting. The article says that writes can be validated so only authorised users may write. Does anybody know if its possible to limit read access to certain users? If so, I may revive an abandoned project and try it as a CouchApp.
This is really cool, especially with companies now providing CouchDB hosting. The article says that writes can be validated so only authorised users may write. Does anybody know if its possible to limit read access to certain users? If so, I may revive an abandoned project and try it as a CouchApp.
However, you can put the database behind a proxy and use lists and shows (that get passed the user info) to restrict the read access.
What about user input validation? If I understand it correctly, all the application code resides in the browser. This means that there is no server side code to make sure that the data stored in the database is properly sanitized. For example, how would you go about making sure an input doesn't contain HTML code? If the verification is made on the client side, it is easy to circumvent it.
This is really cool, especially with companies now providing CouchDB hosting. The article says that writes can be validated so only authorised users may write. Does anybody know if its possible to limit read access to certain users? If so, I may revive an abandoned project and try it as a CouchApp.
A jchrisa pointed out, you can't get more granular than per-database read restriction using just CouchDB. However, you can put the database behind a proxy and use lists and shows (that get passed the user info) to restrict the read access.
Let's suppose I want to build a centralized messaging application where users send each other private messages (and let's say per-user couches aren't available). Users may only see messages directed to them. Messages are contained in documents, one document per message (sounds like a reasonable granularity).
For the JavaScript front-end, I'd like to ask the server for a list of messages for the current user, and later on, for the contents of one particular message.
The list of messages for one user sounds like a simple map-reduce view. In order to only show messages targeted to the current user, my guess is that I should add a list function to the same design document to remove other users' items from the view result. To fetch a message by ID, I'd install a show function which either returns the original message as JSON text or an invalid access message, depending on the current user. Is that how you'd use shows and lists?
Earlier quoted context omitted.
A jchrisa pointed out, you can't get more granular than per-database read restriction using just CouchDB. However, you can put the database behind a proxy and use lists and shows (that get passed the user info) to restrict the read access.
Great to see that feature... I only played with CouchDB in 0.7-days before shows and lists, and found it too everything-is-public for my needs. Let's suppose I want to build a centralized messaging application where users send each other private messages (and let's say per-user couches aren't available). Users may only see messages directed to them. Messages are contained in documents, one document per message (sound…
Set your view to emit keys this way:
[user,message_id]
msgview?startkey=[user]&endkey=[user,{}]
msgview?startkey=[user,message_id]&limit=1
Then your list doesn't have to go through all the messages for all the users -- just the ones that the view returned -- and only check that their user info is correct (i.e. nobody's calling the list using an inapropriate view).
With this scheme you could have the same list + view return a specific message as well.
Oh, and definitely go check CouchDB 1.0 -- it's changed quite a bit since 0.7. You can get a hosted version to play with at http://www.couch.io/get.