If you’re interacting with CouchDB, you have to speak HTTP+JSON.
Even if you send an
Accept header that said you only read
text/plain values—which, I should point out, the Couch documentation says is a valid option—it will send you back JSON…that is just marked as
The HTTP requirement is even more inescapable—the only port open speaks HTTP, Full Stop.
With regard to the JSON requirement, I don’t think there’s any real competition: the
aeson library is far and away the most popular JSON library, to the extent that one might be forgiven for not realizing that there were any others. Although I know the
json package exists, I’ve never had occasion to so much as read its documentation.
What to use for HTTP is a little less clear, but not, to my eyes, much.
If we got back to my prior statement of requirements, I included:
- choice in streaming library
While I am most familiar with the
Conduit ecosystem (largely because I was using couchdb-conduit, so this might change!), others might prefer to work with
Pipes, or, I suppose,
Now that doesn’t necessarily mean anything—if I’m doing a request in some function being called as part of someone’s stream processing, I don’t necessarily need to be integrated with them—usually I just need to write a wrapper that waits for requests, makes them, then yields them.
And for the most part if I’m producing a streaming view, for instance, it’s the same thing—I just need to yield each result as I get it; I don’t need to be somehow intrinsically tied to the framework.
But still, the
http-client package has streaming wrappers for all three of the mentioned libraries—which suggests that it’s easily compatible—it’s got baked-in support for connection pooling, and good support for incremental input (which is a lot of what we need at this low level).
So that is the basis upon which I’m going to build what I”m currently thinking I will call couchdb-simple.