3 ms·

Thanks for sharing your experience, what was the app? Personally, I don't think I would have gone through the trouble as well. For example, I used to have a ton

by yonz 3y ago

Thanks for sharing your experience, what was the app? Personally, I don't think I would have gone through the trouble as well. For example, I used to have a ton of Evernote entries and don't think I would setup a personal CouchDB just to get access to it. A middle ground could be a file path to an sqlite file that can be copied, opened or backed up in the cloud.

oblib 3y ago
The app is at ezInvoice.com. CouchDB is really a very good fit for that app. In the early versions of the app I used CGI.pm to store and get user data and that was very fast and efficient, and the format for storing data was similar to CouchDB's (JSON), so it felt more familiar for me to work with. I had never worked with SQL before making that app. I had a partner back then create a new version that used an SQL db. I did this mostly because I felt like the app wasn't keeping up with web trends and he had been pestering me to use SQL in the next version for about a year. What he ended up with was buggy to the point of users calling and screaming at me and after a year he still couldn't get it right. Back then news of SQL dbs getting hacked were common and after buying several books on SQL I realized that to be proficient required years of study and experience. CouchDB had just come out around then so I looked into it and for me that's been much easier to work with, and do so securely. It's practically designed for an app like ezInvoice. PouchDB.js has made it easy for me to work with. If you're already proficient with SQL there's probably no compelling advantage to using CouchDB/PouchDB, but it's a really good tool set for building web apps.
- yonz 3y ago
  NoSQL is definitely a breeze for data model use cases like that.