How CouchDB enabled eHealth Africa to collect and sync data in the field

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!

CouchDB Developer Profile: Nick Vatamaniuc

Nick Vatamaniuc is a Virginia-based software engineer at Cloudant and an Apache CouchDB committer. If his name sounds familiar, you might remember the post he wrote for our series “The Road to CouchDB 2.0” last year on the newly updated Replication feature.

Almost a year later, Nick shares some of his insights on CouchDB, Erlang, the latest updates to replication in 2.0, and where CouchDB is headed in the future.

Do you want to talk about your background, or how you got involved in CouchDB?

I discovered CouchDB around 2010 while looking for a replacement for an existing database. CouchDB had won over all the other alternatives because of its durability, master-to-master replication, and a built-in easy to use web interface to query and inspect data.

But technical merits are only half the equation. I was also impressed with the Apache CouchDB community. They were very welcoming, friendly, and knowledgeable. Always willing to listen and help.

For the next 5+ years I was a CouchDB user and designed it at the core of a few products. During that time it ended up on thousands of servers across the planet, some in harsh and isolated environments. There wasn’t a single instance where CouchDB lost a customer’s data.

Another thing that made CouchDB stand out was that it was written in Erlang. For me it was a new language, so I looked it up and liked what I found. It made it easy to build distributed and fault tolerant systems. So I started to learn it in my spare time.

In 2015 I started working at IBM Cloudant, and last year got elected as an Apache CouchDB committer. Currently, I enjoy contributing to the Apache CouchDB project and being part of the CouchDB community.

What areas of the project do you work on?

I work mainly on what CouchDB developers call “DB Core”. It includes things like data storage, clustering, replication and HTTP layer.

Recently I was involved in improving the replicator. We had just merged to master an updated replicator which can handle a much larger number replication jobs and has a simplified replication task monitoring API.

What’s a recent development/event/aspect of the project that you’re excited about?

Refactoring the project to use less source repositories. Previously most of the core applications were in separate source repositories. Now they are in a single repository and so it is easier to contribute, track changes and build the project from source.

What do you think are the top three benefits of using CouchDB as a database solution?

Master-to-master Replication: Few databases support this feature. It allows creating custom clustering topologies (a ring, star, or a tree for example) with various availability and scalability trade-offs.

Durability and Fault Tolerance: CouchDB is resilient in the face of crashes and power failures. Data is always appended to the end of database files and never directly re-written. This is a simple and robust design. Also because it is written in Erlang, with its famous fault tolerance capabilities, if some parts of the database crash they automatically restart while the rest of the database core stays up and serves client requests.

Built-In Web Interface: Being able to open Fauxton and inspect, query and modify data is a very powerful and useful feature. I can speed up product development, for example by letting a front end developer populate the database by hand with some “mock” data with a few mouse clicks so they can refine their design. It can also help in production when something is not working quite right and there is a need to see the state in the database. For newcomers it makes it easy to learn and experiment.

What do you look forward to in the future of CouchDB?

One of the most interesting new developments I think is the Pluggable Storage Engines work done by Paul Davis. It would allow creating custom data storage backends with various trade-offs and characteristics.

What advice do you have for someone who just discovered CouchDB?

Open Fauxton and experiment! Add some data, and then write some code to modify the data. Have some fun.

Find us on Slack or IRC. Ask questions.

Learn about _bulk_docs API endpoint to insert multiple documents at the same time. That is often a good way to improve insert performance.

Learn about change feeds and use them to create more responsive and dynamic applications.

 

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!