Why is CouchDB almost never mentioned in this forum? The fact that Phoenix and CouchDB are both Erlang/BEAM based, would their features not be “native” to each other? Would they not go together like hands and gloves?
3 Likes
The last time I checked, there isn’t a way to communicate with CouchDB from other Erlang applications… at least there exists little to no documentation about how to do this. You’d end up with a haphazard API that sometimes uses Erlang, but sometimes has to communicate to CouchDB over HTTP.
Personally I’m not a fan of having to do web app --> erlang terms to json --> http req --> couchdb --> json to erlang terms --> process --> erlang terms to json --> http resp --> json to erlang terms --> web app
2 Likes
Yes, CouchDB wasn’t designed to be an Erlang database but a general database hence the generic interface. Which, unfortunately, makes it a bit cumbersome to use from Erlang.
1 Like
So a couple of things. I think about doing this almost every day. The only thing stopping me from doing it is available time/money. In the back of my mind is a meld between Phoenix with Presence and CouchDB for persistence, running on a single set of nodes, where a node can either be a cache+Phoenix node, or a Couch+Phoenix combined node (data storage and app).
In couchdb 1.6, there is an erlang “API” of sorts but it’s not really very clean - definitely usable though, and undocumented. It wasn’t really intended to be externally usable but it is doable. hovercraft is so old I’d be wary, but I did use it for dirty stuff.
CouchDB 2.x has a far cleaner separation layer, as the chttpd (clustered httpd) layer needs to use an efficient erlang API to talk to the cluster nodes instead of http. Layering elixir goop at this layer would be what I’d aim for, as you’d be able to deal with native BEAM terms all along the way.
There are a few gotchas, the main remaining one being that internally couch is still using proplists, not maps. Originally the reason for this was that JSON allows repeated keys, and also that maps weren’t around. Initially a conversion shim would be sufficient, the performance difference between any other DB going via JSON vs a quick proplist<->map switch would likely be an order of magnitude.
Finally, CouchDB is not (yet) a dynamically expandable cluster, so you’d want to give some thought to how you handle that. Hence my earlier comment around having cache phoenix nodes vs datastore nodes.
3 Likes
