Fauxton isn’t just a pretty face for CouchDB; it’s the primary way you’ll interact with your database cluster for anything beyond basic curl commands.
Here’s CouchDB with Fauxton running, showing a list of databases:
GET /
{
"db_name": "_replicator",
"doc_count": 1,
"doc_del_count": 0,
"update_seq": "1-abcde...",
"purge_seq": 0,
"compacted": false,
"security": {
"admins": {
"names": [],
"roles": []
},
"members": {
"names": [],
"roles": []
}
},
"cluster": {
"q": 8,
"n": 3,
"w": 2,
"r": 2
},
"instance_start_time": "1678886400000"
}
Fauxton is built into CouchDB itself, so there’s no separate installation. When you start CouchDB, Fauxton is served up on the same port, typically 5984. You access it via your browser at http://localhost:5984/_utils/.
The core problem Fauxton solves is making CouchDB’s RESTful API accessible and manageable through a graphical interface. Instead of crafting JSON payloads for every operation, you can click, type, and browse. This includes:
- Database Management: Creating, deleting, and viewing databases.
- Document Operations: Adding, editing, deleting, and viewing individual documents. You can even see document revisions.
- Replication: Setting up and monitoring replication tasks between databases, locally or remotely.
- User Management: Adding, editing, and revoking users and their permissions.
- Cluster Monitoring: For clustered CouchDB, you can see node status, view cluster-wide settings, and monitor replication queues.
- Configuration: Although less common for day-to-day use, you can view and sometimes edit parts of the
couchdb.iniconfiguration.
Let’s dive into how you’d create a new database using Fauxton. Navigate to the main dashboard (/_utils/). You’ll see a section for "Create Database." You simply type the desired database name (e.g., my_new_app_data) and click "Create."
Now, let’s look at a document. If you click into my_new_app_data, you’ll see a list of documents. Clicking on a document ID opens it in an editor. Here’s what a simple document might look like:
{
"_id": "user-12345",
"_rev": "1-a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6",
"type": "user",
"name": "Alice",
"email": "alice@example.com",
"created_at": "2023-10-27T10:00:00Z"
}
In Fauxton, you’d see these fields laid out, and you could edit them directly. If you wanted to add a new field, you’d just type it in. To save, you’d click "Save." The _rev field is CouchDB’s mechanism for concurrency control; when you save changes, CouchDB generates a new _rev.
Replication is another powerful feature. From the main dashboard, you can go to "Replication." You’ll see options to create a new replication job. You specify the "Source Database" (e.g., http://localhost:5984/my_app_data) and the "Target Database" (e.g., http://localhost:5984/my_app_backup). You can also set it to replicate continuously.
The one thing that trips up a lot of people using Fauxton for the first time is understanding the _local database. This special database is accessible via Fauxton but is intended for client-side storage, typically for offline-first applications. Documents stored here are not replicated by default and are local to the specific CouchDB instance serving the client. If you’re seeing a database named _local and you didn’t create it, it’s likely a remnant or intended for a specific client-side sync scenario.
Beyond basic operations, Fauxton provides a window into CouchDB’s internal workings, making it indispensable for development and administration.
The next step after mastering Fauxton is understanding CouchDB’s query capabilities using Mango queries.