Bill Stephenson from ezInvoice talked to us about how he first discovered CouchDB and what his experience has been like employing it in applications.

How did you hear about CouchDB, and why did you choose to use it?

We released our first web app, “ezInvoice.com”, back in 2002. It was written in Perl and was getting long in the tooth, but it’s been a solid app and very easy to use, so we wanted to improve on those strong points while adding features that were impossible back then. A friend on the Raspberry Pi forums told me about CouchDB.

Did you have a specific problem that CouchDB solved?

We’d realized early on in creating our app what the makers of CouchDB already knew, that “Self-Contained Data” was a critical concept for documents like Invoices, Quotes, Receipts, etc. When I went to the CouchDB site and started reading the docs I was pretty much stunned. I couldn’t help but feel that CouchDB was built just for us and as I got further into the docs it just kept getting better with features like “replication” and user management and “database per user”.

For the folks who are unsure of how they could use CouchDB–because there are a lot of databases out there—could you explain the use case?

We’re working on a suite of apps for small and medium size businesses. We give the end user software for free and offer “Data Services” as a revenue source for us.  Our data services store their data online “in the cloud”, and make weekly backups and holds them for a month. It lets users access their apps and their data on any internet connected device with a web browser. If they forget to pay, or just cannot pay, for their data services when they expire they still have all their data and their software still works. When they remember or are able to renew their data services everything will be there waiting for them and all their data will sync up and everything will be good again. That’s really another important layer of “data security” for the business owner to consider that’s been overlooked in most “SaaS” and “DaaS” subscription approaches.

I honestly believe that the way we’ve built these apps demonstrates a much better way of doing things, with considerable advantages for the end user.

What would you say is the top benefit of using CouchDB?

Because we use “Service Workers” to store the app code in the web browser’s cache the loads on our server are greatly reduced, and CouchDB mostly only transfers and stores the document data and it’s not a lot of data. So creating a client side web app ends up being much more efficient for both us and the end user and the apps are fast running on the client side. There’s almost no waiting on the server to respond and in fact, we now have a much finer grain control over that interaction.

I found creating an app that runs almost entirely on the client side offers some advantages for the developer I hadn’t really thought about much. For example, it may be considered “bad practice” to dump yet another JS library in the user’s cache but I didn’t really worry much about that. I’m developing and testing on a “Late `09 Mac Mini” and a “Raspberry Pi” and our apps runs fine on both of those. That’s a pretty low bar and I ended up not needing much more than PouchDB/jQuery/Bootstrap to do what we wanted to do. Those tools really offer an incredibly rich feature set and they work together like a seamless API. Coming from Perl I was pretty amazed at how much I could do with that toolset and how easy it is to use.

What tools are you using in addition for your infrastructure? Have you discovered anything that pairs well with CouchDB?

At first I looked at how I could update our old “save” and “get” routines to use CouchDB. I did some web searching for perl modules for CouchDB and in the process I found PouchDB. Going through the PouchDB docs brought on more “Wow!” moments for me. I hadn’t messed with Javascript much but I could see right off the huge advantages PouchDB makes incredibly easy to leverage and that, really, we could and should rewrite the entire app in Javascript so it could run online or offline.

I spent some time looking into Javascript frameworks with an eye towards what would be best for us to use. There’s truly some great ones out there right now, but after going through example apps at TodoMVC.com I just really couldn’t decide which would be best. After stressing over that for a bit I decided to look for what was easiest. We really wanted our apps to be easy for others to modify and to do that we had to keep the bar of entry as low as possible. We ended up using PouchDB/jQuery/Bootstrap for the client side toolset and both the Apache web server and CouchDB on the server side. And with those decisions made I really could “relax”.

What are your future plans with your project? Any cool plans or developments you want to promote?

I’m now looking forward to releasing the 1.0 version of our apps so I can dig deeper into using design documents, views, and even playing with clusters and load balancers. Our goal is to build products and services that make CouchDB incredibly easy to use for anyone at a cost any business can afford. We believe our CherryPC apps demonstrate that potential right now and have a lot of headroom for improvements to come at a very fast rate.

Use cases are a great avenue for sharing useful technical information. Please consider joining the fun! Additionally, if there’s something you’d like to see covered on the CouchDB blog, we would love to accommodate. Email us!

For more about CouchDB visit couchdb.org or follow us on Twitter at @couchdb.