Replication makes CouchDB the single best solution for Hoptree

We are really enjoying all the great use cases we are encountering through the interviews we’ve been doing over the past few weeks (hint, hint). Patrick Wolf and his team at Hoptree were no exception. They even introduced us to this cute video prior to explaining how they’ve leveraged CouchDB for their SaaS application.

Hoptree offers companies the capacity to increase efficiency and customer interaction by sharing the responsibility of customer texting with an entire team.

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

We had researched Cloudant at the time of the IBM acquisition and learned more about CouchDB. Since at that time we were primarily focused on mobile development, Cloudant and CouchDB were interesting to us because they enabled offline mobile applications. Prior to that, we had tried out several other offline sync solutions which never worked well.

After using CouchDB, we liked it not just because of its replication capabilities but because it’s a great NoSQL database. The fact that it enabled offline replication was a bonus. When it came time to pick a database for Hoptree, CouchDB seemed like the best fit.

Did you have a specific problem that CouchDB solved?

Being that Hoptree is a multi-tenant application, and given some of my past experience building multi-tenant applications, it was very important that we keep customer data as segregated as possible. That meant creating a database per customer. While that’s certainly possible with other database management systems (DBMS), we found that their connectors weren’t as well suited for querying many different databases at a time. They typically create pools of persistent connections per database. Because CouchDB uses HTTP, things are greatly simplified. There’s no pooling and no persistent connections. This has also worked well for us as we’ve transitioned to serverless computing because it allows database access with very little overhead.

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 replication in CouchDB is really the killer feature that sets it apart from other databases. There are a lot of use cases for using tools like PouchDB to enable offline support in mobile applications. However, we also found it useful server-side, as well.

For example, we use PouchDB to replicate configuration data onto each of our servers. We avoid making additional requests every time we need to read a configuration value, and we don’t have to think about how to cache that data. There’s always an up-to-date version of the configuration available locally.

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

  • Replication – as mentioned before, this is the feature that sets CouchDB apart.
  • Optimistic Concurrency – I’ll admit that when I first started using CouchDB, dealing with revision IDs seemed like an annoyance. But now every time I see Document Update Conflict error, I realize that CouchDB just prevented someone’s data from unknowingly being clobbered. It allows us to confront a problem that we might not think about otherwise until it’s too late.
  • Web technologies – CouchDB fits easily into just about any environment because of its use of common web technologies like HTTP, JavaScript, and JSON.

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

We’re running a Node.js stack. All our REST APIs are backed by Swagger. Because CouchDB stores pure JSON documents, it’s easy to use the JSON Schema models within the Swagger definition to validate the documents we store in CouchDB.

We also make use of AWS Lambda for some services, which works well with CouchDB because of the low overhead in making HTTP calls from a Lambda function.

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

Our two-way messaging service has been live for a few months, and we’re still busy adding new features. When I do get some downtime I would like to start converting our codebase to Typescript. There should be some interesting ways to integrate it with CouchDB, but perhaps the open source community will beat me to it.

 

Use cases are a great avenue for sharing technical content and information with the rest of the community. 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

 

 

How CouchDB is creating safer workspaces with Lupin Systems

CouchDB is such a versatile project that there’s no limit to the types of industries it can help assist. In this case, we chatted about the world of occupational health and safety with Mike Wolman from Lupin Systems. Lupin Systems offers web based solutions for regulatory compliance management of buildings, chemical products and the environment.

They have two main applications:

HaRMs: used to manage and generate Safety Data Sheets and Labels (as well as other documents) for materials meeting GHS legislation requirements.

HazMat: used to manage and generate Hazardous Substance Reports/Asbestos Registers for buildings and properties and is used by auditing and consulting firms, as well as property owners or managers to help meet their legal requirements to provide this documentation.

In our interview, Mike talked about the excellence of Lupin Systems’ developers and provided some insight as to how he first discovered CouchDB and his experience working with it.

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

I’d had previous experience with a number of SQL databases including using MySQL and Firebird a fair bit, but my primary database of choice was PostgreSQL. I think I have been using Postgres since around 2000.

I don’t really remember where I heard about CouchDB but kept an eye on it when NoSQL first appeared. When discussing the architecture of our application with developers the choice really came down to CouchDB and Mongo, and our dataset suited NoSQL. We knew we wanted to run a multi master setup for redundancy. We could get away with master/replica but for different geographic locations; this would make the setup and app more complicated.

Initially, we thought we would also take advantage of the CouchDB sync engine to mobile directly, but due to application requirements we are now doing this differently. Using CouchDB allowed us to store attachments natively within the database. An added benefit was that CouchDB dealt with keeping them all in sync. This was a great option using a clustered filesystem or other mechanism to achieve this.

Did you have a specific problem that CouchDB solved?

Yes, CouchDB solved the problem of geographic master/master, redundancy, attachment syncing, i.e., no need for cluster filesystem.

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 use CouchDB as our primary data store for all data and files. Our data consists of a lot of loosely structured information. We also store attachments within CouchDB. It’s great because we have not had any issues with this and are able to store files from a few kb up to about 10mb.

We have over 100 CouchDBs being synced between 3 different data centers. These range from a few thousand documents to over 2 million in each database.

Over the course of 7 years, I think we have only had one issue which was caused by a corrupt view. The dependability is fantastic compared to other databases, with MySQL in the past I had to run MySQLcheck more times than I can remember (haven’t used MySQL in about 10 years so take that with a pinch of salt). As for Postgres, I have a vague memory of an issue a long time ago but cannot remember specifics or if it was hardware or Postgres itself.

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

I would say the top benefit of using CouchDB is its simplicity.

It is simple to setup master/master replication, it’s simple to migrate/upgrade to new server(s), simple to backup, and monitor, as well as manage over long periods of time.

Additionally, I like that it sort of provides a clustered filesystem without any setup. I also find it very useful to be able to view previous versions of a document.

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

For our main app we use Ruby on Rails.

For indexing/search:

  • We have initially used SOLR (ES was not released by then).
  • Upgraded to ElasticSearch (but hit issues with memory use).
  • Upgraded to Postgres when json/jsonb datatype was added. It’s much more memory-friendly than ES and provides so much more flexibility query-wise, including joins and anything else SQL-wise you might want. Plus, Postgres ODBC allows excel/access to query NoSQL data and produce reports etc.

We’ve also paired CouchDB used on large projects with:

  • Nginx + Passenger
  • Puma
  • DocX4J
  • Redis (for sidekiq and other short term bits)
  • FreeBSD
  • Nagios

What are your future plans with your project?

We are working on a mobile version of one of the apps. It’s backed by SQLite but syncs to CouchDB. It will be interesting to see it come together.

 

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!