One of the most exciting parts about blogging for CouchDB is the opportunity to learn about all the various use cases. We were excited to speak with Adam Butler, the Technical Team Lead at eHealth Africa about their use and experience with CouchDB.

eHealth Africa’s team works to bring new approaches to the development of people centric and data driven technology solutions that connect and deliver better public health services for vulnerable communities.

Adam talked to us about how he first discovered CouchDB and what his experience has been with employing it for their specific needs.

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

I first heard about CouchDB around 2010 in the context of this big new thing called NoSQL, to which my main response was “huh?” It took me a while to understand how a non-relational database could be useful (I can be slow like that sometimes). A couple of years later, Jan Lehnardt showed up at a hybrid mobile app meetup I was organising at the time. He did a presentation about the work he’d been doing with an NGO called eHealth Africa. This was at the height of the Ebola epidemic in West Africa, and Jan talked about an app that he was helping to develop that was being used in the struggle to contain the outbreak.

One of the strategies that is used in epidemics of this type is to track down anyone who came into contact with an infected person in the period before they contracted the disease, and then visit them regularly until the incubation period has ended, keeping track of any possible symptoms they might be exhibiting. Keeping a record of these follow-up visits is difficult at the best of times, but in the chaos of a major outbreak, it can be almost impossible.

The solution to this problem, as Jan explained, was CouchDB and its younger sibling PouchDB. Based on Jan’s talk, I dropped what I was doing at the time and joined eHA.

Did you have a specific problem that CouchDB solved?

That follow-up app was one of several data collection apps that we have built, and we run up against the same problem every time: how to store collected data on a mobile device while it’s offline, and then get the data off the device and onto a server when it comes online again. Connectivity in rural Africa is, needless to say, extremely unreliable, so we need to be able to store data on mobile devices in a dependable manner, and then submit that data to a server whenever the opportunity arises.

It turns out that CouchDB, in partnership with PouchDB, is incredibly good at this kind of data synchronisation.

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?

Synchronization! Anyone who wants to build offline-first mobile applications that submit data when they go online should definitely consider a Couch/Pouch-based solution.

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

Synchronization is definitely the top benefit for us, but some other super-useful CouchDB things are the http-first ethos (where everything is a URL) and the built-in user management. The user management can take a while to get your head around – the first time I was confronted with the “one database per user idea” I thought it was wild – but it’s actually very powerful.

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

PouchDB, of course! And then sometimes we only use CouchDB for synchronisation, and import the data into PostgreSQL. The CouchDB changes feed is really handy for this; you can just watch the feed and use it to send data wherever you want.

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

We’re constantly working on new tools. Just recently we finished a mobile app to manage a microcensus in the Democratic Republic of Congo. There’s no population data for DRC, and it became important to get an idea of population numbers for a coordinated campaign against sleeping sickness. That app uses PouchDB > CouchDB > PostgreSQL, and data (checks the changes feed) is coming in from the field this very moment.

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

Have a suggestion on what you’d like to hear about next on the CouchDB blog? Email us!

David Squier is a developer for Toyota, and the creator of Couchit, who is currently using CouchDB (and PouchDB) as the foundation for a rewrite of an existing application that will take it from a single-user/.NET model to a multi-user/Node.js/Cloud model. It’s not quite in production, but already has a fully functioning system with most the data tier complete.

He 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?

I heard of CouchDB several years ago when I was working at Blizzard Entertainment. We looked at Couchbase, which was based on CouchDB. The company ended up going with Couchbase due to clustering support at the time (this was pre CouchDB 2.0).

Did you have a specific problem that CouchDB solved?

Yes. The CouchDB replication protocol and the related ecosystem (i.e., PouchDB) were the primary reason we chose CouchDB. Having written offline replication/synchronization systems in the past, I understood how complex and time-consuming such an effort is. Having an open-source replication protocol lets us build a reliable system on top of it and focus on serving our specific business needs.

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?

The application we’re building is called “Chassis Tuner” and it was built to work both on and offline. We run CouchDB in AWS as the canonical data source for the application.

If a user is online, they are connected to CouchDB in AWS.

If a user if offline, they run the same application, via an Electron wrapper, that embeds our React application with the Node.js server and PouchDB. A single configuration switch toggles between modes, with the offline mode replicating data from CouchDB to PouchDB.

By using pouchdb-node, we have a single API for both online and offline database operations, eliminating the need for different interfaces to handle each mode.

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

The replication protocol. Without it, we would not be able to build our application (or would require many more months to develop a bespoke solution).

Second is the speed at which I can have other developers install, replicate, and develop with a local copy of the database is a big benefit.

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

Besides Fauxton, there are many requirements to modify existing documents, especially while in the development phase. These can be as simple as adding a new property to a document to performing dependent lookups based on keys referenced in a parent document to determine if the referenced document exists in the database.

We initially found a tool that fit the bill called Couchtato. Unfortunately, it is no longer actively maintained and lacked a number of features we needed. As a result, it was forked and has evolved into a new tool called Couchit, which we will use going forward.

Finally, we’ve created a schema registry that defines a number of high-level document “types” with standard properties. We use this to perform automated document validation using JSON Schema via AWS Lambda functions, as well as provide filtered replication.

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

Our current efforts are focused on our initial launch and the related operational data requirements. Once users start using the application and generating parts, vehicle setups, and running simulations we will start getting a rich set of data that can be used to build systems for analysis, reporting, and as inputs for machine learning.

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

Have a suggestion on what you’d like to hear about next on the CouchDB blog? Email us!