search

apache / couchdb

Seamless multi-master syncing database with an intuitive HTTP/JSON API, designed for reliability
https://couchdb.apache.org/
Apache License 2.0
6.2k stars 1.03k forks source link

Embed CouchDB into another BEAM application #5218

Closed lpil closed 3 weeks ago

lpil commented 3 weeks ago

Hello friends. Thank you for this wonderful software, I'm really enjoying learning it and am excited for the production problems it can solve for me.

Summary

I'm a user of BEAM languages such as Gleam and Erlang.

Seeing as my applications and CouchDB run on the same virtual machine I was wondering if it would be possible to run them in the same virtual machine instance and talk over a functional or message based API.

Desired Behaviour

I am able to add CouchDB to my Gleam/Erlang/Elixir etc programs and communicate with it directly from my program within the same VM instance.

Additional context

My goals would be to save on operational overhead, as well as saving on resource usage and removing HTTP overhead as secondary goals.

Thank you for your time and your work.

nickva commented 3 weeks ago

Hi @lpil, thanks for stopping by.

As-is CouchDB is not structured to be used as a dependency in an Erlang project. In rebar3-parlance it would be considered an umbrella project: https://rebar3.org/docs/workflow/

But with a bit of work it could be doable to integrate with it. All the applications in CouchDB are just standard Erlang apps located in the ./src directory. We use rebar for compiling them (still rebar2 though, not rebar3). So at the very least it should be possible to take all the src/* apps and add your apps alongside them, then adjust reltool to build the release including all the CouchDB apps and your apps.

chttpd is sort of the top level API layer listening the requests.fabric is the clustering layer, in charge of dispatching requests to individual workers/shards on other nodes. And couch the app handling opening file handles. Each of those have associated helper apps and libraries. For example, you could integrate at the fabric layer, so you'd skip serializing and/deserializing to/from json. Or, if you don't need clustering and sharding, you can use the couch app directly to open local couch files (similar to how CouchDB 1.x worked).

lpil commented 3 weeks ago

Great to know, thank you. I think for my use this is not quite as practical so I'll continue to use the HTTP API.

Cheers!

rnewson commented 3 weeks ago

Agree with nick that couchdb's interface is the http api, going below that is not supported or documented.